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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:20:21 PDT