Summary: | privilege escalation using LD_PRELOAD with setuid binaries | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Sascha Silbe <sascha-gentoo-bugzilla> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED WORKSFORME | ||
Severity: | critical | CC: | lcars |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sascha Silbe
2003-07-12 05:46:33 UTC
yep, this is how ppl used to exploit sshd and telnetd in older versions I wrote a little preload module to try and confirm this and it does not seem to work. I dont think this is exploitable as the default behavior of glibc should drop the suid bit. Can anybody confirm this happens? i cant reproduce, the manpage says "For setuid/setgid ELF binaries, only libraries in the standard search directories that are also setuid will be loaded." Any objections to changing resolution as INVALID ? Yes, I do object. My build process still creates files as root even though it runs as a normal user. I was not able to reproduce it on Hanno Boeck's Laptop, but as soon as I find time I'll try to create a minimal installation in a UML showing the problem. For the time being, these are the exact versions I use: sys-libs/glibc-2.3.2-r1 sys-apps/fakeroot-0.4.4-r1 The privileges of the user running the build process: uid=1000(sascha) gid=100(users) groups=100(users),4(adm),6(disk),10(wheel),11(floppy),16(cron),18(audio),19(cdrom),20(dialout),1004(ftp),35(games),80(cdrw),245(slocate),250(portage),120(wlan),1033(infra) Sascha, "Yes, I do object. My build process still creates files as root even though it runs as a normal user." Isnt this the point of fakeroot? Take a look at this session i just made, for example: taviso@insomniac:~$ cat test.c #include <stdio.h> int main(){ printf("%d\n",(int)geteuid()); } taviso@insomniac:~$ gcc -ansi -pedantic -o test test.c taviso@insomniac:~$ ls -l test -rwxr-xr-x 1 taviso users 6771 2003-09-26 01:52 test* taviso@insomniac:~$ ./test 1000 taviso@insomniac:~$ cat preload.c #include <stdio.h> int geteuid(void) { fprintf(stderr,"w00t.\n"); return 2; } taviso@insomniac:~$ gcc -ansi -pedantic -shared -o libpreload.so preload.c taviso@insomniac:~$ ls -l libpreload.so -rwxr-xr-x 1 taviso users 6668 2003-09-26 01:52 libpreload.so* taviso@insomniac:~$ LD_PRELOAD=./libpreload.so ./test w00t. 2 taviso@insomniac:~$ sudo chmod u+s test ; sudo chown root test ; ls -l test -rwsr-xr-x 1 root users 6771 2003-09-26 01:52 test* taviso@insomniac:~$ ./test 0 taviso@insomniac:~$ LD_PRELOAD=./libpreload.so ./test 0 Take a look at this fakeroot session, isnt this what your experiencing? taviso@insomniac:~$ whoami taviso taviso@insomniac:~$ fakeroot 'touch foobar; ls -l foobar' -rw-r--r-- 1 root root 0 2003-09-26 01:57 foobar taviso@insomniac:~$ ls -l foobar -rw-r--r-- 1 taviso users 0 2003-09-26 01:57 foobar Within the fakeroot environment, it will look like files are owned by root, but in reality they are owned by me. here are some of the comments from the dynamic loader source code: /* This is an extra security effort to make sure nobody can preload broken shared objects which are in the trusted directories and so exploit the bugs. */ /* ... */ Here the author stats() the preloaded library, if is _NOT_ Suid or he cant test it (eg,stat() fails) This happens: /* ... */ /* The shared object cannot be tested for being SUID or this bit is not set. In this case we must not use this object. */ __close (fd); fd = -1; /* We simply ignore the file, signal this by setting the error value which would have been set by `open'. */ errno = ENOENT; /* ... */ Here is some code from another part: /* Make sure we don't use untrusted directories if we run SUID. */ // Author runs some checks, then... if (unsecure) /* Simply drop this directory. */ continue; There are lots more checks like this, im confident you are experiencing the effects of the fakeroot application, which is specifically designed to fool programs into thinking they are root, and can create files owned by root. libraries cannot be preloaded for suid binaries, unless they are also suid and in a trusted directory (which is by design). The purpose of fakeroot (and the reason I use it) is to run the build process as a normal user, but pretend to be root within the build environment. So it cannot overwrite anything in the system, only in it's build environment. But currently, some processes in the build environment get REAL root privileges, not just pretended ones. They can overwrite files in the real system and cannot be deleted by the user running the build process (!). Well, how about resolving WFM unless someone can produce an example script... WFM sounds good. Any objections from anybody else? Changing to WFM for now. Will report back later when I can reproduce the problem on another system. |