From owner-freebsd-current Sun Nov 3 13:35:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2789537B401; Sun, 3 Nov 2002 13:35:56 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7453743E4A; Sun, 3 Nov 2002 13:35:55 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gA3LZmC4052426; Sun, 3 Nov 2002 13:35:48 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gA3LZm0c052425; Sun, 3 Nov 2002 13:35:48 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Sun, 3 Nov 2002 13:35:48 -0800 From: David Schultz To: Robert Watson Cc: Miguel Mendez , kientzle@acm.org, morganw@chemikals.org, current@FreeBSD.ORG Subject: Re: libc size Message-ID: <20021103213548.GB52281@HAL9000.homeunix.com> Mail-Followup-To: Robert Watson , Miguel Mendez , kientzle@acm.org, morganw@chemikals.org, current@FreeBSD.ORG References: <20021103155858.3be6eda9.flynn@energyhq.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Robert Watson : > > I can't come up right now with an idea of how exploiting LD_LIBRARY_PATH > > could be useful with any of these, but the possibility exists. OTOH, the > > recently added priviledge elevation feature should make it possible to > > have *no* setuid programs on a system, and have the kernel elevate > > priviledges for certain syscalls, based on the policy created by > > systrace. > > LD_LIBRARY_PATH is disabled for setuid binaries -- the kernel sets the > P_ISSETUGID flag, which is exported to userspace by issetugid(), which is > in turn checked by the rtld, which will refuse to observe that > environmental variable (and a number of others) as a result. We have > plenty of dynamically linked setuid binaires in the system already, and > it's not a problem. Setuid binaries are in pretty good shape, since LD_LIBRARY_PATH is ignored for them. But most of the other standard binaries on the system are problematic because they are trusted, but they in turn trust the value of LD_LIBRARY_PATH, which is not always a safe thing to do. For example, if an administrator disables a user's account by setting the shell to a dynamically linked /sbin/nologin, the user can override the restriction by setting an LD_LIBRARY_PATH in his ~.ssh/environment file pointing to a trojaned libc. (This attack requires that he be able to access his home directory, either before being locked out or over NFS or FTP.) You can correctly argue that setting a user's shell to /sbin/nologin is the wrong way to disable the account. Fine. Remove /sbin/nologin. I still claim that this is just one example of what can go wrong when you divide trust between libc and your standard binaries. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message