In some mail from Henrik Nordstrom, sie said:
>
> Darren Reed wrote:
>
> > 3. The port specification is changed by a command from the
> > user.
>
> PASV falls into this category. PASV changes the server side of the port
> specification of the data channel. Remember that the port specifiaction
> in FTP consists of both sides of the connection (not to be confused with
> the PORT command which only specifies one side: the client side). FTP is
> a quite odd protocol from a TCP/IP point of view with very special
> assumptions on port numbers and a different notion of "port
> specification" than most other protocols.
[...]
> Not closing a existing data connection when a PASV command is accepted
> would be in violation of RFC 959 section 3.2 criteria 3. If in doubt if
> this is relevant to PASV, see section 3.3.
>
> FTP does not support more than one data channel per control channel.
> This limitation is both in connection management and command structure
> (syncronous command/reply, not pipelined).
Ok, readers excuse me for a second. Section 3.3 reads as follows:
[...]
3.3. DATA CONNECTION MANAGEMENT
Default Data Connection Ports: All FTP implementations must
support use of the default data connection ports, and only the
User-PI may initiate the use of non-default ports.
Negotiating Non-Default Data Ports: The User-PI may specify a
non-default user side data port with the PORT command. The
User-PI may request the server side to identify a non-default
server side data port with the PASV command. Since a connection
is defined by the pair of addresses, either of these actions is
enough to get a different data connection, still it is permitted
to do both commands to use new ports on both ends of the data
connection.
Reuse of the Data Connection: When using the stream mode of data
transfer the end of the file must be indicated by closing the
connection. This causes a problem if multiple files are to be
transfered in the session, due to need for TCP to hold the
connection record for a time out period to guarantee the reliable
communication. Thus the connection can not be reopened at once.
There are two solutions to this problem. The first is to
negotiate a non-default port. The second is to use another
transfer mode.
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer modes
(Block, Compressed) do not close the connection to indicate the
end of file. They have enough FTP encoding that the data
connection can be parsed to determine the end of the file.
Thus using these modes one can leave the data connection open
for multiple file transfers.
[...]
We don't want to reuse a connection.
Where does it say only one at a time ?
> If you still don't believe me, use netstat on the FTP server while your
> exploit it attacking it. The sockets will be stuck in FIN_WAIT_2 because
> the FTP server has closed it's end of the connection but your exploit
> code keeps it's end open (in CLOSE_WAIT state), thereby blocking the TCP
> from fully closing down the socket.
Different servers behave in different ways, it would seem. Definately
some *don't* close the first data connection before opening a second.
Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:19:19 PDT