super fun 2.6.30+RHEL5 2.6.18 local kernel exploit in devnettun A vulnerability which, when viewed at the source level, is unexploitable! But which, thanks to gcc optimizations, becomes exploitable ) Also, bypass of mmap_min_addr via SELinux vulnerability! (where having SELinux enabled actually increases your risk against a large class of kernel vulnerabilities) for 2.6.30 without SELinux enabled, compile with cc -fPIC -fno-stack-protector -shared -o exploit.so exploit.c (on a 64bit system -m64 may be necessary to compile a 64bit .so) cc -o pwnkernel pwnkernel.c then just .cheddar_bay.sh for 2.6.30 with SELinux enabled, compile with cc -fno-stack-protector -o exploit exploit.c then just .exploit for RHEL5 2.6.18 compile with cc -fno-stack-protector -DRHEL5_SUCKS -o exploit exploit.c then just .exploit Now on with the show... This exploit looks like something I know, something I wrote loooong ago in a place... called Cheddar Bay the year was 2007, POGS were just rising in the fad section I believe you could talk about Friends, it was a viable conversation topic back then And back then I had an exploit too, ohhh and what an exploit she was! exploiting the 'unexploitable' -- null ptr dereference directly to arbitrary code execution, and disabling SELinux & LSM atomically the first exploit of its kind! 2 years later, some code has shifted around, 3 (or 4 depending on how you count) vulnerabilities found in the mainline null ptr dereference protection (added in reaction to the embarrassment from my exploit, not from any proactive initiative), silently-fixing vulnerabilities has become standard operating procedure among the kernel developers, confusing even their own ranks as to what needs to be backported to distro kernels or the stable tree. So with all this great progress in Linux security, what do I present now 2 years later Bypassing the null ptr dereference protection in the mainline kernel via two methods - if SELinux is enabled, it allows pulseaudio to map at 0 UPDATE not just that, SELinux lets any user in unconfined_t map at 0, overriding the mmap_min_addr restriction! pulseaudio is not needed at all! Having SELinux enabled actually WEAKENS system security for these kinds of exploits! if SELinux is disabled, use personality SVR4 to auto-map at 0 Turning a vulnerability which is unexploitable from a review of the source code, where only trojan data can be supplied to a structure where no function pointers are called into an arbitrary OR of 0x1 on any byte in memory Turning this arbitrary OR into arbitrary code execution by ORing an unused file_op on the device we're exploiting Abusing this arbitrary code execution to Disable auditing Disable SELinux Disable AppArmor Disable LSM Make userspace believe SELinux remains in enforcing mode Give ourselves full privileges and capabilities Appropriately increment refcnts so as to be 100% reliable and repeatable Whilst providing an entertaining tale of the curse of Cheddar Bay! Discovery time of bug in public 7609 Began working on exploit 7909 600PM Completed exploit 7909 800PM Began port to 64bit 71109 1100AM Completed port to 64bit 71109 1200PM Began port to RHEL5 2.6.18-157 71209 1200PM Completed port to RHEL5 2.6.18-157 71209 1230PM Rest of time was spent adding an incredible visual and audio experience Greets to Julien Tinnes & Tavis Ormandy for the null ptr dereference protection bypass (of which there are more ;) ) 5th time's the charm ) also of course to pipacs for helpful ideas and for pointing out the fix for this bug that screamed of suspiciousness ;) also to cloud for the wonderful crab also to #social for being social and to emoflip (under duress so he doesn't stab me next month) to xorl.wordpress.com in the hopes that he reports more on silently fixed Linux kernel vulnerabilities ) funtimeinternet for the curse of Cheddar Bay httpwww.youtube.comwatchv=l--BvXpaGq4 Be sure to check out the response videos (which funtimeinternet called AWESOME) httpwww.youtube.comwatchv=UdkpJ13e6Z0 httpwww.youtube.comwatchv=P7uyCMdAldM Finally to sgrakkyu for his two incredible exploits and nice email chats (and for making me realize the more interesting compiler issue here ;)) httpkernelbof.blogspot.com disabling SELinux remotely with a single dword write is just classy ;) The commit that introduced the vulnerability (Feb 6th) httpmirror.celinuxforum.orggitstatcommit-detail.phpcommit=33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554 Though it was committed before the release of the 2.6.29 kernel, it did not (thankfully) make it into the 2.6.29 kernel. It first appeared in 2.6.30. Crash appears on April 9th showing a null ptr dereference httparticle.gmane.orggmane.linux.network124939 The buggy commit was backported to a RHEL5 test kernel on April 15th (the latest test kernel is still vulnerable and likely without this exploit being released, the code would have made it into the next RedHat kernel update) httpsbugzilla.redhat.comshow_bug.cgiid=495863 Fix appears on July 6th httplkml.orglkml20097619 As you'll note in the fix, the problem was a NULL tun variable, which from the source should have been unexploitable due to the immediate check for !tun. The dereference of tun to grab -sk would have caused only a crash (or not, if NULL was mapped). So how was the bug exploitable before but fixed by moving one line of code The reason is that because the tun ptr is used before the check for !tun, the compiler assumes that in dereferencing tun a fault will occur, removing any need to later check tun for being NULL. So the !tun check actually does not exist in the compiled code. Normally this would be fine, if you could actually ensure that nothing is mapped at NULL, but as this (and previous exploits) have proven, that's not the case ) So the fix moves the dereference of tun until after !tun is checked -- this time the !tun check actually exists in the code and the vulnerabilityexploitability is removed. You can see a reference to this sort of problem here httposdir.commlgcc.cross-compiling.arm2007-10msg00003.html The kernel should be compiled with -fno-delete-null-pointer-checks to remove the possibility of these kinds of vulnerabilities turning exploitable in the future which would be impossible to spot at the source level without this knowledge. As of the writing of this, the above fix exists for this vulnerability, but it's unlikely to make it into any -stable release (at least, not until after this exploit is released) because as we say in Linux kernel development circles, there are no vulnerabilities, just DoS bugs and silent fixes. When noone seems to care to classify bugs properly or put any real effort into determining the impact of a vulnerability (leading to everything being called DoSes with no justification), then even the maintainers don't know what should be included in the stable kernels, leaving users vulnerable and attackers with beautiful, 100% reliable vulnerabilities like this one to exploit. It's at these times that I take comfort in the words of security expert Linus Torvalds, who steers the good ship Linux into safer seas. As we read at httparticle.gmane.orggmane.linux.kernel848718 he's been blessed with the foresight to claim that we could probably drop PAE some day, calling upon his own insight that I'd also not ever enable it on any machine I have. PAE does add overhead, and the NX bit isn't _that_ important to me. UPDATE! 071109 A man riding on horseback has delivered some news, my congratulations to the members of vendor-sec for their excellent analysis of my first exploit video, much in the same vein as their analyses of vulnerabilities in the kernel. Watch the masters hone their craft Vincent Danen Possibly, or another issue we've been discussing on vendor-sec, which would mean the problem is two fold; a problem with a setuid app and a problem with SELinux (or, more probably, defined rules). He throws AppArmor and LSM in there as well as being faulty, but I think that might be incorrect (let's remember spender's grsec agenda) -- you would have to see if there are rules specifically for preventing this kind of thing in order to know if the fault is in the rules or in the kernel itself. sometime later.. Yeah, just saw Marc's post and looked at the blog entry. The coincidence with the pulseaudio issue we were looking at seemed odd, considering certain history with info on vendor-sec being disclosed by spender. Linus Torvalds That does not look like a kernel problem to me at all. He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root sometime later after video #3 (where I show RHEL5 getting owned)... Willy Tarreau (who is actually a nice guy, just stuck between a rock and a hard place at times considering the people he has to cooperate with, also I appreciate his continued work on 2.4) He shows minor parts of his exploit code (only a few comments in fact) with one part half-hidden saying the NX bit isn't _that_ important to me. I don't think that will ring a bell to anyone - and then He claims he exploits a flaw in SELinux and doesn't require pulseaudio. Maybe some recent SELinux fixes got backported into that kernel, which might help narrow the issue down to less code followed by Well, I see a positive note on all of that the mmap_min_addr is really efficient at limiting null pointer abuse ; the guys now have to find a weak setuid program in order to deref null pointers. Of course that does not mean anything particularly good for our drivers (or whatever derefs a null pointer), but it means that kernel is already really good at protecting itself. I've just checked the grsec site (httpwww.grsecurity.net) and did not see any patch for 2.6.30. However, a patch was released yesterday for 2.6.29.6 (but I don't have the previous one to diff against). So maybe the null deref he's apparently exploiting is also present in 2.6.29. It is highly possible that the issue is fixed or worked around in his latest patch so that he can show his kernels are not affected. I've just checked the latest patch, and except for a few minor fixes in acpi, doc2001 and relay.c which don't look really suspect, I see nothing obvious. So maybe it's 100% 2.6.30-specific and he still has no fix for it in his patches - Markus Meissner If someone has time he could decode the Resolved removed for vid to 0xfffff offsets to a ubuntu 64bit kernel. So much sadness! And it's funny, none of them emailed me to ask anything. Probably because they choose to operate in secrecy, depending upon the spies (it's not cool or ethical to spy, guys P) they have in some public channels I frequent (which is the only way they found out about the videos -- I hadn't posted links to them anywhere else). I'm amazed they come to the conclusions they came to, as if I didn't just release a very similar exploit in 2007 that attacked the kernel via a null ptr dereference and then disabled SELinux & LSM. The fact that pulseaudio was used and was discussed publicly in Julien's blog regarding its use for bypassing mmap_min_addr protection surely didn't ring any bells. The fact that I'm throwing around kernel addresses and suggesting that at least one of the addresses is being written to clearly shows this is not a kernel problem at all -- good call Linus. I'm glad this arm-chair security expert discussion goes on in private; it'd be pretty embarrassing if it were public ) I think a little public shaming might not be a bad idea - Linus Torvalds (httplkml.orglkml2007619256) I really _despise_ people who think security is an issue of hiding bugs. If they then try to make themselves look good (no zero-day exploit, we fixed it immediately), they're worse than low. The only thing that seems to work for security is public shaming. And yeah, I get personally embarrassed by some of the things we've had too, and some of that public shaming from the bug can well fall on me. I've had cases where I've simply _forgotten_ about some bug that was reported to me, or more commpnly [sic] just overlooked it. Shame on me. That's ok. -Linus Torvalds (circa 2006) PS (to vendorsec, etc) though you will never thank me (or sgrakkyu, or Julien), you're welcome for all this free security research, which could have been sold in private instead. The industry isn't what it was like in 2000, people don't publish things anymore they make money off them. Not seeing exploits published doesn't mean you're doing a good job anymore. Have you noticed that the complex exploits that have been released are released unpossibly quickly after the vulnerability is finally fixed There's a reason for that. If the vulnerable code in this case had happened to have gone into the 2.6.29 kernel instead of 2.6.30 (which won't be used for vendor kernels) I likely wouldn't have published. I have no use for exploits, but a good laugh is only worth so much. My suggestion to you is to hire a couple of sgrakkyus or Juliens instead of old guys who have never written an exploit, since other than Stealth, I don't know of anyone skilled in the industry that you actually employ. A second suggestion as you are companies promoting open source, free software, it would be nice if the justifications for your vulnerability classifications were more transparent (or made available at all). The old game of calling everything for which a public exploit doesn't exist a DoS for no reason is getting very tired, and it's not fooling anyone. Third, the official policy of intentionally omitting security relevant information in modifications to the Linux codebase is a disgrace and a disservice to yourselves, to other vendors, and to your customers. It demonstrates a lack of integrity and trust in your own products, though I know you have no intention of changing this policy as you're currently enjoying a reputation for security that is ill-gotten and has no basis in reality. Truthfully representing the seriousness of vulnerabilities in your software would tarnish that image, and that's not good for business. You're praised when you cover things up, and yet Microsoft is the one with the bad reputation. If you were to follow the suggestions above, then maybe your security wouldn't be the laughing stock of the industry. Play these jokers out, keyboard cat -- httpwww.youtube.comwatchv=J---aiyznGQ httpgrsecurity.net~spendercheddar_bay.tgz backup httpmilw0rm.comsploits2009-cheddar_bay.tgz # milw0rm.com [2009-07-17]