Date: Sun, 3 Nov 2002 13:35:48 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Miguel Mendez <flynn@energyhq.homeip.net>, kientzle@acm.org, morganw@chemikals.org, current@FreeBSD.ORG Subject: Re: libc size Message-ID: <20021103213548.GB52281@HAL9000.homeunix.com> In-Reply-To: <Pine.NEB.3.96L.1021103135713.62308A-100000@fledge.watson.org> References: <20021103155858.3be6eda9.flynn@energyhq.homeip.net> <Pine.NEB.3.96L.1021103135713.62308A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Robert Watson <rwatson@FreeBSD.ORG>: > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021103213548.GB52281>