[457] in linux-security and linux-alert archive
Re: linux a.out ld.so problem
daemon@ATHENA.MIT.EDU (Aleph One)
Mon Nov 6 16:49:26 1995
Date: Mon, 6 Nov 1995 14:32:41 -0600 (CST)
From: Aleph One <aleph1@dfw.net>
To: medulla <medulla@infosoc.com>
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.LNX.3.91.951106061044.389A-100000@ereet.org>
Where you fall in the same trap that telnetd did. You are obiusly root
because you need to be to run strace on ls. There for the test for suidness
will fail because ruid == euid. Try doing the test without being root.
Aleph One / aleph1@dfw.net
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
On Mon, 6 Nov 1995, medulla wrote:
> Date: Mon, 6 Nov 1995 06:11:30 -0500 (EST)
> From: medulla <medulla@infosoc.com>
> To: linux-security@tarsier.cv.nrao.edu
> Subject: linux a.out ld.so problem
>
> 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
>
