Re: ld.so bug - LD_DEBUG_OUTPUT follows symlinks

[Michal Zalewski <lcamtuf () DIONE IDS PL>]

On Wed, 27 Sep 2000, Jakub Vlasek wrote:

> [jv] ~/x export LD_DEBUG=libs LD_DEBUG_OUTPUT=/home/jv/x/debug
> [jv] ~/x ls -l
> -rw-rw-r--    1 jv       jv            308 Sep 27 11:40 debug.22810
> [jv] ~/x su
>  (LD_DEBUG_OUTPUT ignored, data written to terminal)
> Password:
> [root] /home/jv/x ls -l
> -rw-rw-r--    1 jv       jv            308 Sep 27 11:40 debug.22810
> -rw-rw-r--    1 root     root         1850 Sep 27 11:41 debug.22812
> -rw-r--r--    1 root     root          374 Sep 27 11:41 debug.22819
> -rw-r--r--    1 root     root          308 Sep 27 11:41 debug.22820 <- can
> be symlink

...and all you need to make this attack work is local root password ;) In
fact, this problem does not affect setuid programs itself (because
LD_DEBUG_OUTPUT is ignored in this case), but affects programs spawned
from privledged programs after setuid(geteuid()) - in case privledges are
not dropped, but raised, and effective *id is equal to real *id. This
problem is similar to "unsetenv() fails to unset LD_PRELOAD" problem, and
does not affect any setuid program directly. Such way of calling programs
is quite uncommon (maybe except su, which is protected by password,
anyway), and is insecure for other reasons, as well. So, in general,
there's no reason to panic, unless you have some badly written setuid
crap.

_______________________________________________________
Michal Zalewski [lcamtuf () tpi pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=