As little as three years ago, the concept of remote kernelexploitation remained arcane for most people in the security industryand was believed in some circles to be practically impossible, mostlydue to reliability issues. However, things in the security realm changequickly. Reliable exploit techniques come and go, new securitymechanisms are introduced, and arcane exploitation concepts arerevisited. Sometimes an exploitation concept that was once brushed offas too unreliable is reconsidered, bringing it again into focus as auseful and feasible attack vector.
Kernel vulnerabilities themselves are nothing new, of course. Theexploitation of local kernel flaws has been a popular pastime for manyresearchers and hackers over the years, and in many cases these flawswere shown to be exploited just as reliably as a local flaw in userlandsoftware. However, being local to the system has its advantages; thelevel of interactivity with the system and the data that is availablemake for more reliable and/or predictable results. We have seen morethan a fair share of remote kernel flaws over the years as well, someof which were leveraged in historical attacks (such as the Teardropdenial of service attack).
Many of the remote flaws discovered in the past have been limited todenial of service, or at least have not been exhaustively researchedpublicly to fully determine their potential to be exploited for remotecode execution. It’s likely that in some circles, many of the flawsbrushed off by discoverers and the industry in general as simple denialof service attacks have in fact been privately investigated and quitepossibly have been proven to be exploitable to execute arbitrary code.
Some of the first tidbits of information regarding exploiting remotekernel flaws were made available in November 2004 by SoBeIt. Detailswere posted to a forum on exploiting a remote kernel flaw in a Symanteckernel driver, along with details about developing shellcode that wouldexecute in the kernel. The post didn't garner much public attention,however, and it wasn’t until February 2005 that remote kernelexploitation started to get more public attention, thanks mainly due tothe release of the Step Into The Ring 0 paper written by Barnaby Jack of eEye security.
In November 2006, the authors of the Metasploit Framework developed and released a significant new component,allowing exploit authors to trivially execute userland payloads througha provided kernel stager payload. This eliminated a large portion ofcomplicated work that a researcher would have to develop, and allowedthe researcher to instead focus on simply achieving code execution. A paper describing this componentand the process of exploiting wireless kernel flaws on Windows was alsoreleased. These releases also corresponded with the release of thefirst public and trivial-to-use remote kernel exploits, released aspart of the Month of Kernel Bugs.This series of events put to rest any public scepticism regarding thefeasibility of remote kernel exploitation and its potential use by lesssophisticated hackers.
Naturally, many other operating systems soon fell victim to the discovery of these vulnerabilities. In December 2006, a buffer overflow was discovered in the Linux MadWifi driver and was shown to be exploitable with the release of two exploitsfor the issue. In January 2006, a wireless flaw in a FreeBSD driver wasdiscovered by Karl Jamnar and was said to be exploitable, but no publicdetails on exploiting it were made available. In March 2007, Karl gavea presentation at BlackHat Europe describing exploitation in detail. Also in March, Core Security disclosed a flaw in the OpenBSD IPv6 networking stack and released a fully functional exploit to their customers. In August 2007, a public paper was released describing the process in detail.
Most recently, in a paper released in September 2007, David Maynor provided step-by-step detailson discovering a remote Mac OS X wireless driver flaw and developing anexploit capable of executing code. A Metasploit exploit module thatdemonstrates the attack was released. This latest paper puts the finalnail in the coffin for the notion that remote kernel exploitation isn’tfeasible or practical. Now almost every major operating system has beenshown to have remote kernel flaws that can be exploited to executearbitrary code.
Over the past few years, it’s been proven that when exploitingkernel flaws things can be much more complex to sort out and much lessreliable. In many cases, novel ideas and techniques have to be used tosucceed on a per-flaw basis. However, it has also been shown that withdetermination and creativity, some vulnerabilities that are relativelytrivial to exploit are accessible to everyday researchers. Nowexploitation of kernel flaws opens a previously unavailable opportunitythat can in many cases fully ignore common security mechanisms such asfirewalls, address space layout randomisation (ASLR), nonexecutablememory, and access controls. In some cases, the prevalence of thesetechnologies in userland may well explain why researchers are resortingto the path of least resistance, which in this case might be theexploitation of kernel-based flaws.
Now that it has been demonstrated that no code will go unexploited,I think it’s time to revisit kernel security. As it stands, mostoperating systems that are implementing security mechanisms in userlandare for the most part ignoring the kernel. Kernel memory (including thestack) is still executable in most cases, address space layoutrandomization isn't available, etc. Fortunately for Linux users, the
grsecurity(PaX) kernel patch is available and provides enhanced security featuressuch as randomized kernel stacks and nonexecutable kernel data.Hopefully, other operating systems will soon follow suit.