Re: FTP denial of service attack

[hno () HEM PASSAGEN SE (Henrik Nordstrom)]

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.

> > All FTP servers I have tried does this.
>
> And those are which ones ?  Having read the RFC, I would counter your
> claim and say they're not compliant with rfc959.  I hope this isn't
> one you've written yourself O:-)

I have mostly tried connection management on WU-FTPd based servers, but
also a couple of Microsoft NT, OpenVMS and others.

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).

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.

Your exploit is a effective DOS on most FTP servers. Best way around it
would be for the FTP server to exponentially delay data channel reopen
request if the reopen rate is high relative to the amount of sucessful
data transfers, and to make sure the host operating system has a timeout
for FIN_WAIT_2 (not entirely legal in TCP, but needed today to avoid
several DOS cases related to FIN_WAIT_2)

--
Henrik Nordstrom