Re: FTP denial of service attack

[avalon () COOMBS ANU EDU AU (Darren Reed)]

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