Re: Does the shared lib bug work on any suid program ?

[jmason () iona ie (Justin Mason)]

Bernd Lehle said:

> - Choose any suid program, that uses a library call, You know the name
> - example: su calls crypt(3)
> - take the library that contains crypt and delete crypt from it
> - add a crypt function that does exec(sh)
> - rebuild the shared library with the new cypt
> - set the shared library path to Your home
> - su
> Right after the Password was typed in, You should have a root shell...
> This game could be played with any suid program, where You know what routines
> it calls.

Most reasonably sane operating systems will ignore the shared library
search path when executing setuid programs, relying instead on the
builtin default (eg /usr/lib). That takes care of the problem you
mention, and this behaviour is built into the kernel.

All well and good, except when a program is run as root with your
environment; then the above restriction doesn't come into effect.
Usually this happens as a result of being exec'd by a setuid-root
program (see the 8glm "at" hole) or as a result of something more
unusual such as this telnetd thing.

By the way, an addendum to ckd's patch: Adam Shostack mentioned LANG as
another useful env var to propagate, along with TZ, USER, TERM, DISPLAY
and TERMCAP.

--j.