Home page logo

bugtraq logo Bugtraq mailing list archives

Re: FTP denial of service attack
From: avalon () COOMBS ANU EDU AU (Darren Reed)
Date: Wed, 8 Dec 1999 15:20:14 +1100

In some mail from Henrik Nordstrom, sie said:

Darren Reed wrote:

         3. The port specification is changed by a command from the

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:

      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

      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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]