[2366] in bugtraq
Re: Does the shared lib bug work on any suid program ?
daemon@ATHENA.MIT.EDU (Justin Mason)
Wed Nov 8 03:25:30 1995
Date: Mon, 6 Nov 1995 15:30:51 +0000
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Justin Mason <jmason@iona.ie>
X-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <199511031307.OAA00824@visbl.rus.uni-stuttgart.de>
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.
