Exploiting Fedora 16 with CVE-2012-0056
As most server admins should have heard by now, there’s a new cross-platform local root exploit available, associated with CVE-2012-0056 using /proc/<pid>/mem. While the exploit in the blog post uses /bin/su as a target suid executable, Fedora is doing a good job at least for that binary, using ASLR and thus defeating the exploit. But usingfind /usr/bin -uid root -perm -u+s | while read file; do if readelf -h $file | grep -Eq "Type:s*"; then echo $file; fi; done
gives you a list of quite some other binaries not using ASLR with the suid bit set, thus being possible victims. The other thing that such a binary needs to be vulnerable is outputting some user-provided content to either stdout or stderr. Because I didn’t know all of the listed binaries, I went for something I knew: /usr/bin/newgrp simply says newgrp: group 'foobar' does not exist on invocation with some invalid group. Great!
While this simple change was sufficient to exploit Ubuntu again (Ubuntu is also vulnerable to the original code), Fedore just greeted me with a segfault. So I fired up gdb to find out, why. Luckily, it was able to tell me the function in which the segfault occured: audit_log_acct_message. So instead of wondering why the segfault occured in the first place (the binary didn’t look as if this function would be overwritten by overwriting exit like in the original code), I decided to try overwriting this function instead of exit. And voila, it worked! I only had a few Fedora boxes to test, so I can’t say for sure if newgrp is always compiled with auditing support. If it isn’t, this function call doesn’t have to be present!
So what is the patch status for the common distros:
- Debian: not vulnerable due to old kernel
- Ubuntu:
vulnerable to original exploit! And the Launchpad page doesn’t seem as if anybody is working on it. Fixed with kernel release 3.0.0.15.17 - Fedora: vulnerable to modified exploit! While their bugzilla says, the fix from upstream was committed (and that it would be harder to exploit the issue – nope, don’t think so), it doesn’t seem as if a new kernel package had been released.
- Archlinux:
already patched vulnerable (at least when the offset is given manually, see this screenshot)