Subject: passive mode questions

From: Dave Wreski <[email-masked]>
Date: Wed, 9 Dec 1998 13:00:55 -0500 (EST)

Hi all.  I'm currently using wu-ftpd-2.4beta17, and have a question about
passive mode.  If I have web browser clients, I require passive mode,
correct?  Passive mode is also the preferred method, because it allows the
server to define the ports available, correct?

It seems using passive mode I can create a form of denial-of-service by
repeatedly making a passive mode connection.  Is anyone familiar with this
problem, and how can it be fixed?

Thanks,
Dave

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 9 Dec 1998 14:18:51 -0500 (EST)

On Wed, 9 Dec 1998, Dave Wreski wrote:

> Hi all.  I'm currently using wu-ftpd-2.4beta17, and have a question
> about passive mode.  If I have web browser clients, I require passive
> mode, correct?  Passive mode is also the preferred method, because it
> allows the server to define the ports available, correct?

You are correct, most web broswers only support PASV mode.

As an FTP site administrator, you prefer PASV mode because your server
cannot be used to attack other servers with it.  for that reason, WU-FTPD
does not allow PORT to instruct the server to connect back to any machine
other than the machine issuing the PORT command.  The daemon and the
protocol actually do not really care which method is used.

The server does not 'define' the ports available, however.  It simply asks
the system to give it a client port to listen on.  On most systems that
port number is randomly chosen (making a DoS difficult) but on some it's
sequentially chosen and an attacker can predict which port will be next
used for a PASV connection.  The attacker can then steal the connection to
send/receive whatever the client/victim was doing.

There is an extension in the VR-series (and in BeroFTPD) which allow the
admin to restrict the range of ports chosen for PASV mode.  This is
intended to make the range smaller to easy firewall administration.
Currently, the code in VR uses a linear search and is, therefore,
vulnerable socket stealing.  I have an improved random-selection scheme in
hand but have not had time yet to code it up.

> It seems using passive mode I can create a form of denial-of-service
> by repeatedly making a passive mode connection.  Is anyone familiar
> with this problem, and how can it be fixed?

I'm not sure what you're asking here.  If you mean you can steal the PASV
port; yes, on some systems, you can.  That's not a DoS, though.  If you
mean repeatedly issuing a PASV command to the server; no, you should not
be able to create a DoS.  The deamon closes the previous port prior to
honoring the new PASV command, freeing that resource back to the system.  
I've tested this on Linux and the port is freed very quickly, it does not
hang about in a TCP WAIT state.  I imagine it's possible to issues a large
number of STOR/PASV or RETR/PASV sequences with sufficiently short files
that you may have a number of sockets laying about in TCP WAIT but, at
least on my Linux system, I have been unable to cause and significant
backlog of such sockets.

Some time ago, running a much older Linux kernel, I was able to force
resource starvation due to bugs in the TCP WAIT state.  I saw this more
with HTTP sockets than FTP, and the problem was corrected by the time I
upgraded to Redhat 4.2

All of my testing has been on Beta-18 and with the VR patches.  I have
never tried these tests against Beta-17.  I imaging it's possible
(although unlikely) there's a problem with the PASV mode in earlier
versions.

There are a few patches in the VR sets which address some issues
concerning port openning/closing for both PORT and PASV mode.  these
patches, however, were to correct sequencing (especially when switching
between the two modes) so the report for the STAT command was correct.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195