Kernel-mode exploits primer - International Secure System Lab

close enough to establish a wireless link, to name only a fewreasons why 802.11 device driver vulnerabilities seem suchan attractive target. Like any device for network communication,wireless devices rely on specific communicationprotocols which state how certain goals (i.e. finding availablenetworks, connecting to a secured network, exchangingdata etc.) can be achieved. These protocols lay downall rules and limitations imposed on each message and definecommon structures. Quite often, drivers rely heavilyon their communication partners’ strict adherence to thesestructures and rules. Obviously, this works fine as long asno partner violates any of the restrictions. Sometimes however,hardware devices may not function properly or driversfail to behave as expected or to follow the mandatory structures.This can lead to problems or even system crasheson the receiving end of the communication. When deliberatelycrafting a malformed packet and sending it to a vulnerablehost (i.e. a machine using a poorly programmed devicedriver) an attacker cannot only crash the receiving hostbut may even be able to run arbitrary commands by using abuffer-overflow.Obviously, developing an exploit is useless as long as novulnerability is known to serve as foundation for the exploit.Furthermore, it is not worthwhile to create new exploits foralready well-known problems as there are typically alreadyexploits available, not to mention that patches and updateshave usually been released to work against such an attack.It should come as no surprise, then, that this paper has aconnection to finding new wireless device driver vulnerabilities:in a related project[10] we are currently investigatinginto a new and efficient means to fuzz 1 wireless devicedrivers in an emulated environment. We hope that it willbe possible to easily find potential vulnerabilities using ourfuzzer. In order to test whether a vulnerability is harmfulwe want to be able to efficiently create proof-of-concept exploits,and this is where the present work comes into play:this paper will describe the process of exploiting vulnerabilitiesin kernel-mode. Following the approach presented by[3] we want to create a framework that allows for executionof user-space payloads in kernel-mode on Linux systems.In the following sections we will explain the general ideasbehind the approach, followed by an in-depth description ofan exemplary Windows- and Linux-exploit.2 Windows kernel-mode exploitsIn [2] bugcheck and skape discuss the theory of kernelmodeexploits on Windows at great length. There is also1 Fuzz testing, or simply fuzzing, is a software testing technique developedat the University of Wisconsin-Madison that has proved particularlyeffective in detecting potential security vulnerabilities in protocol implementations.plenty of material about extensive research of this topic beforeand after them available from other sources (e.g., see[8], [3], or [5]). Not surprisingly, the Windows kernel-modeexploits available from the Metasploit framework today arebased on considerable portions of the work above. Since wewill be using the Metasploit exploits later on, we will dedicatethis section to an overview of some of the importanttheoretic principles of these exploits. For further details onmost of the issues introduced here, refer to [2].Kernel-mode exploits tend to be relatively more involvedthan their respective counterparts in userland. The reasonfor this, quite obviously, lies in the complexity of kernelspaceitself. For example, what if the exploit’s payload isexecuted in the context of an hard- or software interrupt?Furthermore, kernel libraries and interfaces are very differentfrom those available to user-applications. Ironically, thisfact weighs so heavy that a kernel-mode exploit will typicallytry to safely return to user-space to execute code. Asdescribed in [3] this reason was also in the way the newMetasploit framework handles kernel-mode exploits: in anutshell, the idea is to load a regular user-space payload (ofwhich there is an ample supply in the framework) and createan environment from within kernel-mode that is able toexecute the payload. In essence, this process consists offour distinct components; bugcheck and skape [2] speak of:migration, stager, recovery, and stage. Depending on theactual vulnerability only a subset of these components maybe required for successful exploitation.The first step, migration, is unique to kernel-mode exploits.Contrary to user-space, a process in kernel-spacemay be executing in the context of a hard- or software interrupt— the Windows kernel in particular operates on socalled interrupt request levels (IRQL). This may have significantconsequences: for example, a process running ata certain IRQL may not be able to block, reference certainmemory ranges, or to call important library routines. That isto say, it may be necessary for an exploit to work to be executedat a lower IRQL than where the exploit originally occurred.Obviously, one possibility to achieve this is by migratingthe payload into a different context to be executed.In general, there are different strategies to choose from —which one to apply is usually dependent on the exploit inquestion. Here are some migration strategies described in[2]:• It is possible to directly adjust the IRQL. While thisis perhaps the easiest and most straight forward approach,it may potentially result in serious crashes ordeadlocks if simply leaving the higher IRQL leads toan illegal state (e.g. if the interrupt had acquired alock prior to the exploit that now unexpectedly staysin place).• Another popular technique of payload migration works2