From owner-freebsd-security Mon Apr 23 7:21:51 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id DE26E37B423 for ; Mon, 23 Apr 2001 07:21:48 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3NEMBf99054; Mon, 23 Apr 2001 10:22:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 23 Apr 2001 10:22:11 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Victor Sudakov Cc: freebsd-security@freebsd.org Subject: Re: Q: Impact of globbing vulnerability in ftpd In-Reply-To: <20010423111632.B17342@sibptus.tomsk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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