The dynamic loader used by Gentoo allows setuid binaries to preload libraries in standard system paths using LD_PRELOAD. Together with "insecure" libraries this allows a local user to gain root privileges. I discovered this problem during software compilation using fakeroot. Suddenly files on the real filesystem where owned by root.root. Soon I found out that this exploit was already known at Debian in 1998, but obviously has never been fixed upstream. See this thread: http://www.geocrawler.com/mail/thread.php3?subject=LD_PRELOAD+used+with+setuid+programs+%28was+Re%3A+Fakeroot+security+problem%29&list=237 The test described in http://www.geocrawler.com/mail/msg.php3?msg_id=1222630&list=237 shows that Gentoo is still vulnerable (which explains my "problems" using fakeroot): === Begin screenshot === sascha@cube:~$ LD_PRELOAD=funny /bin/su /bin/su: error while loading shared libraries: funny: cannot open shared object file: No such file or directory sascha@cube:~$ === End screenshot === The patch can be found at "http://lists.debian.org/debian-sparc/1998/debian-sparc-199802/msg00018.html". Please fix this ASAP in Gentoo and inform the upstream maintainers. Thanks! Reproducible: Always Steps to Reproduce: 1. LD_PRELOAD=funny /bin/su Actual Results: /bin/su: error while loading shared libraries: funny: cannot open shared object file: No such file or directory Expected Results: Password: Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.21-cube-2 i686 AMD Athlon(tm) processor GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/vice/etc /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/afs/modload /etc/afs/C /etc/afs/afsws /etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 libg++ mad gtkhtml gdbm berkdb libwww gtk cdr -3dfx 3dnow -aalib acl afs -alsa apm -arts avi -bonobo crypt -cups dga -directfb doc -dvd encode -esd -evo -fbcon -ggi gif -gnome -gnome-libs -gphoto2 -gpm guile hbci -icc -icc-pgo imap imlib ipv6 -java jpeg kde kerberos lcms ldap -matrox maildir mbox mikmod mmx monitor -motif mozilla mpeg -mule mysql nas ncurses nls -odbc oggvorbis opengl oss pam -pcmcia -pda pdflib -perl png -pnp postgres python qt qtmt quicktime readline -ruby samba sasl sdl slang -slp -snmp socks5 spell ssl -static -svga -tcltk -tcpd tetex tiff truetype -voodoo3 X xml xml2 -xmms xv -zeo zlib" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O3 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://hybrid.sascha.silbe.org/gentoo-portage" FEATURES="sandbox ccache"
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.
