On Wed, 30 Oct 1996, Mike Long wrote:

> 
> >Date: Wed, 30 Oct 1996 12:46:52 -0600 (CST)
> >From: Peter Seebach <seebs@solon.com>
> 
> >But you know, we have a similar problem already....
> >
> >	LD_LIBRARY_PATH=... login -p sync
> >(if you have sync as a login...)
> >
> >In general, I think this has the potential to be a security bug worth
> >looking at...
> 
> login is a setuid-root binary.  IIRC, ld.so ignores LD_LIBRARY_PATH
> when it loads setuid (& setgid?) dynamic binaries.

Incorrect.  ld.so ignores LD_LIBRARY_PATH (and LD_PRELOAD, which can do
similar things) when a program is setuid or setgid (ie. when uid/gid !=
euid/egid), however login is NOT setuid when called from getty since getty
is already running as root.

To be more precise, the check is: (from src/gnu/usr.bin/ld/rtld/rtld.c)

       /*
         * Make sure we do not allow the library search path
         * to be modified through the environment if we are
         * running either setuid or setgid.
         */
        uid = getuid(); euid = geteuid();
        gid = getgid(); egid = getegid();
        careful = (uid != euid) || (gid != egid);
        if (careful) {
                unsetenv("LD_LIBRARY_PATH");
                unsetenv("LD_PRELOAD");
        }


This is the entire cause of the telnetd hole on many systems a while ago; 
since login runs with uid == euid when called from telnetd, ld.so listened
to LD_LIBRARY_PATH which telnetd so kindly passed; instant root. 

This proposed change does have some security risks which are potentially
quite serious, but I don't see anything which can not be avoided fairly
easily.