No Ring Untarnished

[Symantec]

No Ring Untarnished
<p>As little as three years ago, the concept of remote kernel exploitation remained arcane for most people in the security industry and was believed in some circles to be practically impossible, mostly due to reliability issues. However, things in the security realm change quickly. Reliable exploit techniques come and go, new security mechanisms are introduced, and arcane exploitation concepts are revisited. Sometimes an exploitation concept that was once brushed off as too unreliable is reconsidered, bringing it again into focus as a useful and feasible attack vector.</p>

<p>Kernel vulnerabilities themselves are nothing new, of course. The exploitation of local kernel flaws has been a popular pastime for many researchers and hackers over the years, and in many cases these flaws were shown to be exploited just as reliably as a local flaw in userland software. However, being local to the system has its advantages; the level of interactivity with the system and the data that is available make for more reliable and/or predictable results. We have seen more than a fair share of remote kernel flaws over the years as well, some of which were leveraged in historical attacks (such as the Teardrop denial of service attack). </p>

<p>Many of the remote flaws discovered in the past have been limited to denial of service, or at least have not been exhaustively researched publicly to fully determine their potential to be exploited for remote code execution. It’s likely that in some circles, many of the flaws brushed off by discoverers and the industry in general as simple denial of service attacks have in fact been privately investigated and quite possibly have been proven to be exploitable to execute arbitrary code.</p>

<p>Some of the first tidbits of information regarding exploiting remote kernel flaws were made available in November 2004 by SoBeIt. Details were posted to a forum on exploiting a remote kernel flaw in a Symantec kernel driver, along with details about developing shellcode that would execute in the kernel. The post didn't garner much public attention, however, and it wasn’t until February 2005 that remote kernel exploitation started to get more public attention, thanks mainly due to the release of the <a href="http://research.eeye.com/html/papers/download/StepIntoTheRing.pdf">Step Into The Ring 0</a> paper written by Barnaby Jack of eEye security.</p>

<p>In November 2006, the authors of the Metasploit Framework developed and released a <a href="http://blog.metasploit.com/2006/10/kernel-mode-payloads-in-metasploit-30.html">significant new component</a>, allowing exploit authors to trivially execute userland payloads through a provided kernel stager payload. This eliminated a large portion of complicated work that a researcher would have to develop, and allowed the researcher to instead focus on simply achieving code execution. A <a href="http://www.uninformed.org/?v=6&a=2">paper describing this component</a> and the process of exploiting wireless kernel flaws on Windows was also released. These releases also corresponded with the release of the first public and trivial-to-use remote kernel exploits, released as part of the <a href="http://projects.info-pull.com/mokb/">Month of Kernel Bugs</a>. This series of events put to rest any public scepticism regarding the feasibility of remote kernel exploitation and its potential use by less sophisticated hackers.</p>

<p>Naturally, many other operating systems soon fell victim to the discovery of these vulnerabilities. In December 2006, a <a href="http://lists.grok.org.uk/pipermail/full-disclosure/2006-December/051176.html">buffer overflow was discovered</a> in the Linux MadWifi driver and was shown to be exploitable with the <a href="http://www.securityfocus.com/bid/21486/exploit">release of two exploits</a> for the issue. In January 2006, a wireless flaw in a FreeBSD driver was discovered by Karl Jamnar and was said to be exploitable, but no public details on exploiting it were made available. In March 2007, Karl gave a <a href="http://www.blackhat.com/presentations/bh-europe-07/Eriksson-Janmar/Whitepaper/bh-eu-07-eriksson-WP.pdf">presentation at BlackHat Europe</a> describing exploitation in detail. Also in March, <a href="http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1703"> Core Security disclosed a flaw</a> in the OpenBSD IPv6 networking stack and released a fully functional exploit to their customers. In August 2007, a <a href="http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1887"> public paper was released </a>describing the process in detail.</p>

<p>Most recently, in a paper released in September 2007, David Maynor <a href="http://www.uninformed.org/?v=8&a=4">provided step-by-step details</a> on discovering a remote Mac OS X wireless driver flaw and developing an exploit capable of executing code. A Metasploit exploit module that demonstrates the attack was released. This latest paper puts the final nail in the coffin for the notion that remote kernel exploitation isn’t feasible or practical. Now almost every major operating system has been shown to have remote kernel flaws that can be exploited to execute arbitrary code. </p>

<p>Over the past few years, it’s been proven that when exploiting kernel flaws things can be much more complex to sort out and much less reliable. In many cases, novel ideas and techniques have to be used to succeed on a per-flaw basis. However, it has also been shown that with determination and creativity, some vulnerabilities that are relatively trivial to exploit are accessible to everyday researchers. Now exploitation of kernel flaws opens a previously unavailable opportunity that can in many cases fully ignore common security mechanisms such as firewalls, address space layout randomisation (ASLR), nonexecutable memory, and access controls. In some cases, the prevalence of these technologies in userland may well explain why researchers are resorting to the path of least resistance, which in this case might be the exploitation of kernel-based flaws.</p>

<p>Now that it has been demonstrated that no code will go unexploited, I think it’s time to revisit kernel security. As it stands, most operating systems that are implementing security mechanisms in userland are for the most part ignoring the kernel. Kernel memory (including the stack) is still executable in most cases, address space layout randomization isn't available, etc. Fortunately for Linux users, the <a href="http://www.grsecurity.net/">grsecurity</a> (PaX) kernel patch is available and provides enhanced security features such as randomized kernel stacks and nonexecutable kernel data. Hopefully, other operating systems will soon follow suit.<br />
</p>
http://www.symantec.com/enterprise/security_response/weblog/2007/09/no_ring_untarnished.html
http://www.symantec.com/enterprise/security_response/weblog/2007/09/no_ring_untarnished.html
Tue, 25 Sep 2007 05:00:00 -0800