Re: LD_PRELOAD used with setuid programs (was Re: Fakeroot security problem)
On Mon, Feb 09, 1998 at 09:30:15PM +0000, 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, and also add
> libnfslock to the list). If there weren't any someone would have
> presented these patches much earlier.
I disagree. That sort of things shouldn't be done by an
ordinary user, but by the sysadmin (writing wrappers for the programs
involved, for example).
The package `libnfslock' adds one line to /etc/ld.so.preload.
That file has always worked, even with setuid programs, and will not
stop working because of this patch.
>
> ------- Start of forwarded message -------
> Message-ID: <Pine.SUN.3.94.980208153330.7034A-100000@dfw.dfw.net>
> Date: Sun, 8 Feb 1998 15:39:10 -0600
> Reply-To: Aleph One <aleph1@DFW.DFW.NET>
> From: Aleph One <aleph1@DFW.DFW.NET>
> Subject: Re: Another ld-linux.so problem
> To: BUGTRAQ@NETSPACE.ORG
>
> On Sat, 7 Feb 1998 carson@TLA.ORG wrote:
>
> > 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)
> >
> > and have it work. This is basically what the runsocks script does.
If that is needed, then that `runsocks' script should be a
setuid binary that does it.
> Another example: installing a library that overides mktemp, tempnam and
> other dangerous library functions with more secure ones. So the feature
> is indeed useful. The correct behavior should be for the dynamic linker
> to give up at the first error. Alternatively you should be able to
> configure such libraries via the configuration file instead of an
> environment variable. You cant do so now as far as I can tell.
Suppose that some library corrects one important security fix
in `/bin/su' replacing a `dangerous library function', and the
sysadmin adds that library to /etc/ld.so.preload. If we still can use
LD_PRELOAD with setuid binaries, an ordinary user could do:
$ LD_PRELOAD=libc.so.6 /bin/su
in order to use the symbols from libc.so.6 instead of the ones in your
library (yes, LD_PRELOAD is evaluated before /etc/ld.so.preload).
Additionaly, it's very difficult for me to trust all the
libraries in /lib, /usr/lib, and all the directories contained in
/etc/ld.so.conf... for example, do you really think that it's safe to
use LD_PRELOAD with the libraries `libc.so.4' or `libc.so.5' in a
libc6-compiled setuid binary?
--
Juan Cespedes
--
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: