Re: Q: Impact of globbing vulnerability in ftpd

From: Robert Watson (rwatson@freebsd.org)
Date: 04/23/01


Date: Mon, 23 Apr 2001 10:22:11 -0400 (EDT)
From: Robert Watson <rwatson@freebsd.org>
To: Victor Sudakov <sudakov@sibptus.tomsk.ru>


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
robert@fledge.watson.org NAI Labs, Safeport Network Services

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



Relevant Pages

  • Re: FTP guest access chroot not working
    ... the "root" dir for the chroot is /home/someguy/ftp ... # chroot ftp users ... cannot get out of that jail. ... if you created a symlink inside the jail that points to some real ...
    (comp.unix.sco.misc)
  • Re: FTPS Server?
    ... port numbers by deep packet inspection. ... It behaves exactly like an ordinary FTP ... See the chroot configuration in the man-page for sshd_config ... case standard port 22 stops working. ...
    (freebsd-stable)
  • Re: FTPS Server?
    ... port numbers by deep packet inspection. ... It behaves exactly like an ordinary FTP ... we need that for php-fpm chroot anyway... ... Running FreeBSD in a vmware did help to setup this, ...
    (freebsd-stable)
  • ftp & PAM chroot jail dir experts
    ... hope you ftp chroot dir experts can help me with this one, ... Jan 29 17:57:42 www kernel: Packet log: input ACCEPT lo PROTO=6 ... upload /var/ftp/* /etc no ...
    (comp.os.linux.security)
  • Re: how an hacker can bypass a chrooted environement ?
    ... chrooted environnement) and injecting it a shellcode (i.e ... This is called "breaking out of the chroot". ... the current WORKING directory is not changed -- it is OUTSIDE the root directory of the process. ... Cenzic has the most comprehensive solutions to meet your application security penetration testing and vulnerability management needs. ...
    (Pen-Test)