Re: FTP DoS - PORT and PASV effected.

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

Darren Reed wrote:

> btw, a similar sort of attack can be mounted using the PORT command.
> You just need to setup a local listener, etc, or get the ftp server
> to try connect to lots of network 10 sites in < 75 seconds before
> TCP connect's start timing out.  I'll leave that as an exercise for
> the reader - a correct fix for the PASV problem should fix this one
> as well (and the exploit is almost the same too).

I think the some development version of wu-ftpd is safe from the PORT
version of the attack. PORT (or default) data connection can only be
used once per transfer, and the some development versions of wu-ftpd
requires the client to close the data connection before it acknowledging
the transfer, thereby limiting the PORT version of the attack to once
per control connection. Most versions (i.e. the versions currently
commonly used) does not do this and can be exploited using PORT.

Thinking of it the PASV based attack can be stopped by similar (generic)
measures. Simply do NOT accept the establishment of a new data
connection unless the client has closed the previous connection. This
could be done in at least two ways without any noticeable impact on RFC
compliance:

a) When closing any existing data connection due to port specification
change, make sure the client also closes it's end of the connection
before continuing processing.

b) Do not accept the establishment of a new data connection until the
client has fully closed down any previous connection.

Of the two, alternative b is the one least likely to cause
interoperability problems with clients behaving badly. Both methods are
fully generic and not tied to any connection establishement method.

The FTP server should also clearly log (and close) any open data channel
on exit, to alert the administrator that there may be a problem.

Simply closing the control connection if a second PASV command is seen
is in my eyes not a good approach. While it may stop this particular DOS
it is very specific and can probably be fooled in one way or another. It
is also in violation of the spirit of RFC 959.

--
Henrik Nordstrom