Matthew Burgess wrote: > On Sun, 24 Oct 2010 10:25:26 -0700, Bryan Kadzban > <br...@kadzban.is-a-geek.net> wrote: > >> 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. > > I tried this on a freshly built LFS-20101024 but couldn't reproduce > the problem. As a non-root user I get just the ping usage message. > As the root user, I get: > > ERROR: ld.so: object '/tmp/libbad.so.0' cannot be loaded as audit > interface: undefined symbol: la_version: ignored > followed by the ping usage message, which is what is described in > the vulnerability.
Yeah, that's the description, but the real question is whether the __attribute__((constructor)) function was run. > However, there's still no /usr/bin/bad directory created. ...And it sounds like it wasn't. Weird. I get the same as a non-root user (though this system is pretty old; as I said earlier, glibc 2.10.1), but as root, I get the same error message, and /usr/bin/bad is mkdir'ed, as expected. (I can also add a printf in that init() function, and it does get printed when ping is run as root, but not when it's run as a normal user.) Ah, I think I see. You have to put libbad.so into /lib64 (emulating libpcprofile), then set LD_AUDIT to just "libbad.so.0", with no path. At that point it works as expected (at least for me). (Though this is a multilib setup. But ping is 64-bit; on a single-bit-width system you should be able to just use /lib instead.) > I probably just screwed something up as the vulnerability as > originally described, using libpcprofile.so, which is built & > installed as part of the Glibc package, triggers the bug. Yeah, I see that I have a libpcprofile as well, and it does act the same way when loaded with LD_AUDIT. So this is a problem even on glibc 2.10.1. > It'll be a while until I run another full build, but I'm recompiling > glibc now, with the patch I uploaded earlier. I'll post results > tomorrow, but expect it to work just fine. Well, if I had any other users on this system, I'd think about patching 2.10.1 and trying it out -- but since I don't, I'll probably just wait until the next full system rebuild. (Replacing glibc on a running system is ... nontrivial. :-( )
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