You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Chuck Wolber (JIRA)" <ji...@apache.org> on 2011/06/01 22:48:47 UTC
[jira] [Created] (NET-414) Apache Commons TFTP does not reject
request replies that originate from a control port.
Apache Commons TFTP does not reject request replies that originate from a control port.
---------------------------------------------------------------------------------------
Key: NET-414
URL: https://issues.apache.org/jira/browse/NET-414
Project: Commons Net
Issue Type: Bug
Components: TFTP
Affects Versions: 3.0, 2.2
Environment: Java 1.6 Patch 20
Reporter: Chuck Wolber
Priority: Minor
When a TFTP request response arrives that incorrectly specifies its source port as the control port, the request should be rejected with an error code 5 (TFTPErrorPacket.UNKNOWN_TID) and suggested text "INCORRECT SOURCE PORT".
This can happen when an incorrectly written TFTP server replies to a request from a control socket instead of building a new socket that attaches to an ephemeral port.
Note 1: The expected response from a read request is a DATA packet. The expected response from a write request is an ACK packet.
Note 2: The control port is implementation specific and not always port 69 (as defined by IANA).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (NET-414) Apache Commons TFTP does
not reject request replies that originate from a control port.
Posted by "Chuck Wolber (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183569#comment-13183569 ]
Chuck Wolber edited comment on NET-414 at 1/10/12 9:16 PM:
-----------------------------------------------------------
I have made a vast number of changes to the TFTPClient class we used in our project, thus a proper patch against any Apache Commons released version is no longer possible. However, in rough qualitative form, after the initial try/catch block that surrounds "received = bufferedReceive()" we are using the following code to detect the condition (note that the "port" variable is defined in the method arguments and is not always port 69 as defined in the IANA port reservation).
{code:title=TFTPClient.java}
// The first time we receive we get the port number and
// answering host address (for hosts with multiple IPs)
if (justStarted)
{
justStarted = false;
hostPort = received.getPort();
if (hostPort == port)
{
error = new TFTPErrorPacket(received.getAddress(),
received.getPort(), TFTPErrorPacket.UNKNOWN_TID,
"INCORRECT SOURCE PORT");
bufferedSend(error);
endBufferedOps();
throw new TFTPTransferErrorException(
"Incorrect source port in request reply.");
}
data.setPort(hostPort);
if(!host.equals(received.getAddress()))
{
host = received.getAddress();
data.setAddress(host);
sent.setAddress(host);
}
}
{code}
And then later we attempt to detect if a packet has been sent by someone other than the host that we initiated the conversation with:
{code:title=TFTPClient.java}
// Comply with RFC 783 indication that an error acknowledgement
// should be sent to originator if unexpected TID or host.
if (host.equals(received.getAddress()) &&
received.getPort() == hostPort)
{
[...]
}
else
{
/* Hmmm, someone else is bugging us. Go away please :) */
error = new TFTPErrorPacket(received.getAddress(),
received.getPort(),
TFTPErrorPacket.UNKNOWN_TID,
"Unexpected host or port.");
bufferedSend(error);
continue _sendPacket;
}
{code}
was (Author: chuckwolber):
I have made a vast number of changes to the TFTPClient class we used in our project, thus a proper patch against any Apache Commons released version is no longer possible. However, in rough qualitative form, after the initial try/catch block that surrounds "received = bufferedReceive()" we are using the following code to detect the condition (note that the "port" variable is defined in the method arguments and is not always port 69 as defined in the IANA port reservation).
// The first time we receive we get the port number and
// answering host address (for hosts with multiple IPs)
if (justStarted)
{
justStarted = false;
hostPort = received.getPort();
if (hostPort == port)
{
error = new TFTPErrorPacket(received.getAddress(),
received.getPort(), TFTPErrorPacket.UNKNOWN_TID,
"INCORRECT SOURCE PORT");
bufferedSend(error);
endBufferedOps();
throw new TFTPTransferErrorException(
"Incorrect source port in request reply.");
}
data.setPort(hostPort);
if(!host.equals(received.getAddress()))
{
host = received.getAddress();
data.setAddress(host);
sent.setAddress(host);
}
}
And then later we attempt to detect if a packet has been sent by someone other than the host that we initiated the conversation with:
// Comply with RFC 783 indication that an error acknowledgement
// should be sent to originator if unexpected TID or host.
if (host.equals(received.getAddress()) &&
received.getPort() == hostPort)
{
[...]
}
else
{
/* Hmmm, someone else is bugging us. Go away please :) */
error = new TFTPErrorPacket(received.getAddress(),
received.getPort(),
TFTPErrorPacket.UNKNOWN_TID,
"Unexpected host or port.");
bufferedSend(error);
continue _sendPacket;
}
> Apache Commons TFTP does not reject request replies that originate from a control port.
> ---------------------------------------------------------------------------------------
>
> Key: NET-414
> URL: https://issues.apache.org/jira/browse/NET-414
> Project: Commons Net
> Issue Type: Bug
> Components: TFTP
> Affects Versions: 2.2, 3.0
> Environment: Java 1.6 Patch 20
> Reporter: Chuck Wolber
> Priority: Minor
>
> When a TFTP request response arrives that incorrectly specifies its source port as the control port, the request should be rejected with an error code 5 (TFTPErrorPacket.UNKNOWN_TID) and suggested text "INCORRECT SOURCE PORT".
> This can happen when an incorrectly written TFTP server replies to a request from a control socket instead of building a new socket that attaches to an ephemeral port.
> Note 1: The expected response from a read request is a DATA packet. The expected response from a write request is an ACK packet.
> Note 2: The control port is implementation specific and not always port 69 (as defined by IANA).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-414) Apache Commons TFTP does not reject
request replies that originate from a control port.
Posted by "Sebb (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183503#comment-13183503 ]
Sebb commented on NET-414:
--------------------------
I'm not quite clear what code changes are needed here - have you a suggested patch?
> Apache Commons TFTP does not reject request replies that originate from a control port.
> ---------------------------------------------------------------------------------------
>
> Key: NET-414
> URL: https://issues.apache.org/jira/browse/NET-414
> Project: Commons Net
> Issue Type: Bug
> Components: TFTP
> Affects Versions: 2.2, 3.0
> Environment: Java 1.6 Patch 20
> Reporter: Chuck Wolber
> Priority: Minor
>
> When a TFTP request response arrives that incorrectly specifies its source port as the control port, the request should be rejected with an error code 5 (TFTPErrorPacket.UNKNOWN_TID) and suggested text "INCORRECT SOURCE PORT".
> This can happen when an incorrectly written TFTP server replies to a request from a control socket instead of building a new socket that attaches to an ephemeral port.
> Note 1: The expected response from a read request is a DATA packet. The expected response from a write request is an ACK packet.
> Note 2: The control port is implementation specific and not always port 69 (as defined by IANA).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-414) Apache Commons TFTP does not reject
request replies that originate from a control port.
Posted by "Chuck Wolber (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183569#comment-13183569 ]
Chuck Wolber commented on NET-414:
----------------------------------
I have made a vast number of changes to the TFTPClient class we used in our project, thus a proper patch against any Apache Commons released version is no longer possible. However, in rough qualitative form, after the initial try/catch block that surrounds "received = bufferedReceive()" we are using the following code to detect the condition (note that the "port" variable is defined in the method arguments and is not always port 69 as defined in the IANA port reservation).
// The first time we receive we get the port number and
// answering host address (for hosts with multiple IPs)
if (justStarted)
{
justStarted = false;
hostPort = received.getPort();
if (hostPort == port)
{
error = new TFTPErrorPacket(received.getAddress(),
received.getPort(), TFTPErrorPacket.UNKNOWN_TID,
"INCORRECT SOURCE PORT");
bufferedSend(error);
endBufferedOps();
throw new TFTPTransferErrorException(
"Incorrect source port in request reply.");
}
data.setPort(hostPort);
if(!host.equals(received.getAddress()))
{
host = received.getAddress();
data.setAddress(host);
sent.setAddress(host);
}
}
And then later we attempt to detect if a packet has been sent by someone other than the host that we initiated the conversation with:
// Comply with RFC 783 indication that an error acknowledgement
// should be sent to originator if unexpected TID or host.
if (host.equals(received.getAddress()) &&
received.getPort() == hostPort)
{
[...]
}
else
{
/* Hmmm, someone else is bugging us. Go away please :) */
error = new TFTPErrorPacket(received.getAddress(),
received.getPort(),
TFTPErrorPacket.UNKNOWN_TID,
"Unexpected host or port.");
bufferedSend(error);
continue _sendPacket;
}
> Apache Commons TFTP does not reject request replies that originate from a control port.
> ---------------------------------------------------------------------------------------
>
> Key: NET-414
> URL: https://issues.apache.org/jira/browse/NET-414
> Project: Commons Net
> Issue Type: Bug
> Components: TFTP
> Affects Versions: 2.2, 3.0
> Environment: Java 1.6 Patch 20
> Reporter: Chuck Wolber
> Priority: Minor
>
> When a TFTP request response arrives that incorrectly specifies its source port as the control port, the request should be rejected with an error code 5 (TFTPErrorPacket.UNKNOWN_TID) and suggested text "INCORRECT SOURCE PORT".
> This can happen when an incorrectly written TFTP server replies to a request from a control socket instead of building a new socket that attaches to an ephemeral port.
> Note 1: The expected response from a read request is a DATA packet. The expected response from a write request is an ACK packet.
> Note 2: The control port is implementation specific and not always port 69 (as defined by IANA).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-414) Apache Commons TFTP does not reject
request replies that originate from a control port.
Posted by "Sebb (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183808#comment-13183808 ]
Sebb commented on NET-414:
--------------------------
OK, we're getting closer.
As far as I can tell, the current TFTPClient code already implements the second code block above in both send and receive methods.
As to the first code block above, only the sendFile method has a justStarted variable - receiveFile seems to use lastBlock == 0 to detect the condition. Both methods already get the port from a parameter.
I'm wondering if we are looking at the same code base - are you looking at the trunk version, i.e:
https://svn.apache.org/repos/asf/commons/proper/net/trunk/src/main/java/org/apache/commons/net/tftp/TFTPClient.java
> Apache Commons TFTP does not reject request replies that originate from a control port.
> ---------------------------------------------------------------------------------------
>
> Key: NET-414
> URL: https://issues.apache.org/jira/browse/NET-414
> Project: Commons Net
> Issue Type: Bug
> Components: TFTP
> Affects Versions: 2.2, 3.0
> Environment: Java 1.6 Patch 20
> Reporter: Chuck Wolber
> Priority: Minor
>
> When a TFTP request response arrives that incorrectly specifies its source port as the control port, the request should be rejected with an error code 5 (TFTPErrorPacket.UNKNOWN_TID) and suggested text "INCORRECT SOURCE PORT".
> This can happen when an incorrectly written TFTP server replies to a request from a control socket instead of building a new socket that attaches to an ephemeral port.
> Note 1: The expected response from a read request is a DATA packet. The expected response from a write request is an ACK packet.
> Note 2: The control port is implementation specific and not always port 69 (as defined by IANA).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira