Date:         Fri, 16 Mar 2001 10:13:07 -0800
From: Crist Clark <crist.clark@GLOBALSTAR.COM>
Subject:      Re: Multiple vendors FTP denial of service
To: BUGTRAQ@SECURITYFOCUS.COM

I would like to point out that this "bug" people have discussing really
does not have a lot to do with FTP daemons, but is more of a general
globbing issue. Go and type,

  $ cd /
  $ ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*

At the command line and see what happens. (Having a good sized tree
above where you execute the 'ls' is important to getting the full effect
when doing this on the command line or at an FTP prompt which is why I
suggest going to / just to be sure.)

Except for the FTP daemons which work in novel ways, this is not even a
denial of service attack. Typically, the parent, listening daemon
spawns a new process for each control connection. If the person who is
connected to the daemon then uses the above "attack" they kill their own
daemon. They could do the same thing by logging off. The parent daemon
is not affected nor are other users currently connected. (Assuming that
there are sane resource limits in place of course).

What 'novel' daemons might be affected by this? Those that have different
user IDs not associated with different system user IDs. In this case, the
operating system cannot differentiate between different FTP users, thus
one user can DoS the others by exhausting shared resources. However, some
very clever daemons may have resource limitations per-user within their
own user base.

Before people start running around trying to filter 'ls' arguments in the
daemon, IMHO, the correct solution to the "problem" is proper resource
limitations per user (there are undoubtably other resource attacks through
an FTP daemon too). For users at the operating system level, most OSes have
resource-limiting capabilities, so it is just a matter of doing it. The real
issue is fixing FTP daemons with their own user bases that do not have the
capability to impose their own per-user resource limits. That's the only bug
here.

I did not post earlier 'cause I figured someone would bring this up right
away.
--
Crist J. Clark                                Network Security Engineer
crist.clark@globalstar.com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.  If
the reader of this e-mail is not the intended recipient, or the employee
or agent responsible to deliver it to the intended recipient, you are
hereby notified that any review, dissemination, distribution or copying
of this communication is strictly prohibited.  If you have received this
e-mail in error, please contact postmaster@globalstar.com