[quotes and other stuff deleted. Please refer to the original postings.]
> It's much simpler than that:
>
> $ LD_PRELOAD=libdoesntexist /bin/su
> /bin/su: error in loading shared libraries
> libdoesntexist: cannot open shared object file: No such file or directory
>
> In other words, just use LD_PRELOAD. It is _not_ ignored on setuid binaries.
Either you are using an old ld-linux.so or your /bin/su is not suid
root. I believe you should upgrade.
To test your system, try this: Compile both "hack" and "libhack", set
LD_PRELOAD (and do 'export LD_PRELOAD'!) to the shared library and
test "hack" set and unset suid-root. The result is what the docs
promise, tested with ld-linux.so.1.9.6. Another reaction should be
considered reason to upgrade or reinstall. Btw: Its error output looks
like this:
rzlin1:/tmp/roman $ export LD_PRELOAD=/tmp/roman/foo
rzlin1:/tmp/roman $ ls
ls: can't load library '/tmp/roman/foo'
rzlin1:/tmp/roman $
/*- hack.c -- gcc -o hack hack.c ------------------------------*/
#include <stdio.h>
int main()
{
FILE *fd;
setuid(geteuid());
fd=fopen("/dev/null","r");
if(fd)
printf("File could be opened. Shared lib not loaded.\n");
exit(0);
}
/*-- end hack.c ------------------------------------------------*/
/*-- hacklib.c (the shared lib) -- gcc -shared -o libhack.so hacklib.c --*/
/* For Solaris: cc -G -o libhack.so hacklib.c */
#include <stdio.h>
#include <errno.h>
FILE *fopen(const char *filename, const char *mode)
{
printf("shared library loaded. uid: %i euid: %i \n",getuid(),geteuid());
/* Lots of evil stuff in here. Use your imagination. */
errno=-EINVAL;
return NULL;
}
/*-- end hacklib.c --------------------------------------------------*/
> (Something I wrote about the dangers of this some time ago):
>
>
> I linux (and the Solaris) dynamic linkers don't ignore
Sun Microsystems have solved this problem with Solaris years ago.
> LD_PRELOAD for setuid binaries. The documentation of the
> old (libc5, aka ld.so 1.8.1, 1.9 etc) said (incorrectly) that LD_PRELOAD
> was ignored when executing setuid binaries, and this is the behaviour
> I've always expected.
>
> But apparently the wisdom is that
> libraries that are installed on the system should be well written,
> and it should be safe for them to be specified in LD_PRELOAD.
> I am quite surprised by this attitude, and I think I've thought of 3
> situations where this behaviour of the dynamic linkers may _possibly_
> create security problems.
Impressive. Anyway, you are definitely right.
> I very much welcome responces from peope on this list. (Like:
> "Don't worry, you silly newbie, we know what we are doing"
[snip]
> (If you don't believe the dynamic linkers ignore LD_PRELOAD on setuid bins,
> type "LD_PRELOAD=libdoesntexist /bin/su".)
See example above. Either your /bin/su is not suid root or your
software is too old.
[snip]
> at this moment -- all I want to say is that there _is_ a potential security
> problem.
>
> Thanks,
There is a risk: ld-linux.so will respect LD_PRELOAD if you execute a
suid-root binary if you are root already. As root, this makes it easy
to use safer libraries instead of the standard ones, as Aleph pointed
out. (But why would one install `unsafe' libraries then?) Undoubtedly,
the feature can be of good use.
> --
> joost witteveen, joostje@debian.org
Greets, Roman.
_ _
| Roman Drahtmueller Death is God's way |
CC University of Freiburg of telling you not to
| email: roman@rzlin1.ruf.uni-freiburg.de be such a wise guy. |
- -