[461] in linux-security and linux-alert archive
Re: linux a.out ld.so problem
daemon@ATHENA.MIT.EDU (Adrian )
Mon Nov 6 21:30:15 1995
Date: Mon, 6 Nov 1995 18:30:28 -0600
From: adrian@procyon.com (Adrian )
To: linux-security@tarsier.cv.nrao.edu, medulla@infosoc.com
> While I was playing around with the telnetd hole, I noticed something
> terribly wrong with a.out systems (elf is fine in my test). It seems that
> even if a program is suid or sgid, that the LD_LIBRARY_PATH is still being
> used, so setting login g+s will have no effect (and more worrisome is that
> any suid program can be abused to get root). Here is a example, am I missing
> something obvious? The ld.so man page clearly says the variable(s) are
> ignored when the app is suid or sgid, but this doesnt appear to be the case.
> --- snip
> hfpa:~# cp /lib/libc.so.4 /tmp
> hfpa:~# cp /bin/ls .
> hfpa:~# chmod g+s ls
> hfpa:~# strace -o ls.1 ./ls
> <snipped dir list>
> hfpa:~# grep /tmp ls.1
> hfpa:~# setenv LD_LIBRARY_PATH /tmp
> hfpa:~# strace -o ls.2 ./ls
> <snipped dir list>
> hfpa:~# grep /tmp ls.2
> uselib("/tmp/libc.so.4") = 0
>
> --- snip
I'm not sure why elf might be different, but I see a problem with
your demonstration. I'm assuming that the "#" in your prompt means
that you are root. The key thing is not that the s-uid bit is set
on the target binary, when you attempt to alter the LD_LIBRARY_PATH.
Rather it is the difference between the ruid and the euid when the
target binary loads. When a normal user executes a set-uid binary
owned by root, that normal users uid will remain the real-uid while
then effective-uid will be changed to root, so the two won't match,
and the LD_LIBRARY_PATH environment variable will be ignored. If
you are root when you execute the target binary, the set-uid bit
on a root owned set-uid binary will have no real effect. The
ruid and euid will still be equal, so the LD_LIBRARY_PATH variable
will have its effect.
---
L. Adrian Griffis
adrian@procyon.com
