Re: Q: Impact of globbing vulnerability in ftpd

From: Robert Watson (
Date: 04/23/01

Date: Mon, 23 Apr 2001 10:22:11 -0400 (EDT)
From: Robert Watson <>
To: Victor Sudakov <>

On Mon, 23 Apr 2001, Victor Sudakov wrote:

> As far as I understand, it can be exploited only after a user has logged
> in, so ftpd is already chrooted and running with the uid of the user at
> the moment. What serious trouble can an attacker cause under these
> conditions?

It is true that the globbing vulnerability cannot be exploited until a
login has occurred, as prior to authentication, there are no opportunities
to present the FTP server with an expression that is expanded using
glob(). However, logging in as an anonymous user, where enabled, is
sufficient to allow the vulnerability to be exploited. This problem is
compounded because the FTP server only runs with an effective UID of the
user, as it needs to rebind new privileged ports in active mode. All
vulnerabilities in the FTP daemon are very serious because of this
behavior; I've been considering the idea of a flag to ftpd to force the
use of passive mode by all clients (violation of spec, and nasty to many
clients and firewalls, no doubt), which would allow the server to run with
less privilege.

Even if the attacker only exploits the rights of the effective
(authenticated) user, it may be possible to break out of the chroot() if
there are processes outside of the chroot() running as the same user. For
example, if ftpd switches to the "nobody" uid for anonymous users, and
there is a web server running as "nobody" which executes CGI (thus giving
up the P_SUGID bit); in such a scenario, the user can both influence (see,
signal, ...) processes not chroot()'d, but also attach to them using
debugging services. Note: chroot() is *not* a comprehensive security
feature, it is a file system namespace feature. Improper use of chroot(),
such as overloading use of the uid by executing code with the same uid
without identical chroot() limitations, will result in possible
undesirable effects.

So the sort of it is: this is a serious vulnerability that should be
addressed by anyone running the FTP daemon, especially those with
anonymous FTP enabled. Because the vulnerability is in glob, there are
actually a variety of other software authors who may need to evaluate the
safety of their code.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project NAI Labs, Safeport Network Services

To Unsubscribe: send mail to
with "unsubscribe freebsd-security" in the body of the message