[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LD_PRELOAD used with setuid programs (was Re: Fakeroot security problem)



In an attempt to save the world from disaster, James Troup wrote:
> Juan Cespedes <cespedes@debian.org> writes:
> 
> > Yes, both ld-linux.so.2 and ld-linux.so.1 should be fixed; nobody
> > should be able to run a setuid program in a LD_PRELOAD environment.
> > At least, I can't find any reason to allow it, and many people could
> > use it to try to find exploits.
> 
> But there _are_ reasons to do allow it (see below

[quoted here]

> 
> > Yes. SOCKSifying stupid protocols that require binding ports <1024, for
> > example. Assuming you install libsocks5_sh.so in /usr/lib, you can do:
> >
> > $ (export LD_PRELOAD=/usr/lib/libsocks5_sh.so; rsh machine.outside.firewall
> > pwd)
> >
                         ^^^

The initial "/" in the LD_PRELOAD path will cause it to be ignored
already at the moment, for setuid binaries (ld-linux, anway. Not
sure about ld.so).


>, and also add
> libnfslock to the list).

OK, libnfslock seems more valid. But if it's only for libnfslock, maybe
it would be better to just install a replacement /lib/libc.


Oh, and BTW, when I posted to bugtraq about this, I got about 6
responsed from RH people that all said it didn't work for them
(typing "LD_PRELOAD=funny /bin/su"). That was on RH4.2, but
also from RH 5.0 (that one is libc6, isn't it) systems.

Does anybody have the possibility to check? It really seems the RH
people already patched their ld.so and ld-linux, as to ignore LD_PRELOAD.

(the test sympli is: Type "LD_PRELOAD=funny /bin/su". If you see it
complain about errors in loading shared libs, your dynamic linker didn't
ignore LD_PRELOAD. If, however, you get the "Passwd:" prompt, your linker
does ignore LD_PRELOAD).


> Another example: installing a library that overides mktemp, tempnam and
> other dangerous library functions with more secure ones. 

OK, seems to me it might be better to have those secure mktemp routines
in the c library.



-- 
joost witteveen, joostje@debian.org

The upstream maintainer is allowed to do things different 
than Debian, but only if he has good reasons to do so.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-sparc-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: