Subject: FTP compromise. (fwd)

From: Phil Poole <[email-masked]>
Date: Tue, 9 Sep 1997 11:43:33 -0400 (EDT)

Stan,

	You might need to address this one.

	It is also a valid compromise on Solaris 2.5.X running 
	2.4.2 Beta 14.

	I was able to kill my system earlier today..the system 
	load just continued to climb until it crashed.

---------- Forwarded message ----------
Date: Tue, 9 Sep 1997 14:43:46 +0100
From: Josef Karthauser <[email-masked]>
To: [email-masked]
Subject: FTP compromise.

I found this today.  Any comments?

BUG:            wu_ftpd (all versions)

TESTED:         BSDI 3.0 (all patches), FreeBSD 2.2.1

DATE:           15th Aug 1997

REPEAT BY:      Log into a wu_ftp server (either anonymously or as a user)
                and issue the command...

                nlist ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/
                ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/
                ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/
                ../*/../*/../*/../*/../*../*../*

DESCRIPTION:    You can severly compromise the ftp servers performance.
                This command will create a HUGE directory listing, no
                matter how many files/directories are in the current
                directory (this is recursive).

CONSEQUENCES:   These vary.  On my FreeBSD 2.2 box I was able to eat up
                all memory and swap memory until the kernel spewed
                "out of swap space" errors and killed a few processes.
                It also eats up all available CPU space (up to 99.22%
                on my box).  If repeated a few times you will no
                longer use up swap space and the processor usage will
                rocket and stay there for quite a while (hours).  Since
                the ftpd program is still processing the command your
                ftp session will not idle timeout.  However, if you
                do decide to kill your attacking ftp session, ftpd
                will still process teh command and therefore, the hosts
                resources will take a beating.

                Basically, it looks like any user can severely drain
                your systems resources - a kind of Denial of Service
                attack.  I was able to use up all remaining processor
                time for two hours (would have gone on for much longer
                only I got bored and kill it).

CONTACT:        You can email me at [email-masked] if you
                want to discuss this problem further (or let me know
                if it works on any other ftpd).

--
Josef Karthauser
Technical Manager       Email: [email-masked]
Pavilion Internet plc.  [Tel: +44 1273 607072  Fax: +44 1273 607073]

----- End of forwarded message from Aleph One -----

-- 
--
       Phil Poole	| Unix Systems Administrator
     [email-masked]	| Frederick Biomedical SuperComputing Center
      (301) 846-5721	| Frederick MD, 21702

---

From: [email-masked] (Andy Church)
Date: Tue, 09 Sep 1997 12:57:58 EDT

[snippage]
>                nlist ../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/

     As messy as the glob code is, I think the solution is to put in some
checks for globerr != NULL -- it looks like the code currently goes happily
on with its recursive matching even after the glob list is full and Gcat()
puts an error message in globerr.  (Actually, it would be better
implemented by having functions like Gcat() return success/failure instead
of void, if anyone feels like rewriting the whole thing.)

     While we're on the topic, setting CPU time limits on processes like
/bin/ls executed by the daemon would be a good idea as well--"ls -lR" on a
large tree would do some pretty nasty stuff.

  --Andy Church                  | If Bell Atlantic really is the heart
    [email-masked]       | of communication, then it desperately
    www.dragonfire.net/~achurch/ | needs a quadruple bypass.