Improving Mac OS X Security

Through Gray Box Fuzzing Technique

Stefano Bianchi Mazzone Mattia Pagnozzi Aristide Fattori

[email protected] [email protected] [email protected]
Dipartimento di Informatica Dipartimento di Informatica Dipartimento di Informatica
Università degli Studi di Milano Università degli Studi di Milano Università degli Studi di Milano

Alessandro Reina Andrea Lanzi Danilo Bruschi

[email protected] [email protected] [email protected]
Dipartimento di Informatica Dipartimento di Informatica Dipartimento di Informatica
Università degli Studi di Milano Università degli Studi di Milano Università degli Studi di Milano

ABSTRACT possibly developed by third parties. Often, such compo-

The kernel is the core of any operating system, and its se- nents are not as secure as the kernel, because of the lack
curity is of vital importance. A vulnerability, in any of of testing, and their typical closed-source nature [1, 2, 19,
its parts, compromises the whole system security model. 3]. Furthermore, kernels have countless entry points for user
Unprivileged users that find such vulnerabilities can easily data. System calls, file systems, and network connections,
crash the attacked system, or obtain administration privi- among others, allow user-fed data to reach important code
leges. In this paper we propose LynxFuzzer, a framework to paths in the kernel. If a bug is found in such paths, it can
test kernel extensions, i.e., the dynamically loadable com- lead to vulnerabilities that compromise the entire system
ponents of Mac OS X kernel. To overcome the challenges security. Testing the user-to-kernel interface is really im-
posed by interacting with kernel-level software, LynxFuzzer portant because it can reveal a potential privilege escalation
includes a bare-metal hardware-assisted hypervisor, that al- vulnerability that represents one of the main targets attack
lows to seamlessly inspect the state of a running kernel and nowadays [20]. Windows and Linux user-to-kernel interfaces
its components. We implemented and evaluated LynxFuzzer have been deeply analyzed and many tools exist for their
on Mac OS X Mountain Lion and we obtained unexpected testing and verification. On Mac OS X, the user-to-kernel
results: we indivuated 6 bugs in 17 kernel extensions we communication approach used by kernel extensions [5] is rel-
tested, thus proving the usefulness and effectiveness of our atively young and has not been extensively analyzed before.
framework. Furthermore, the number of OS X adoptions is growing at
a continuously rising pace and this will soon attract the at-
tention from cyber-criminals.
Categories and Subject Descriptors In this paper, we present the design and implementation
D.4 [Operating Systems]: Reliability – Verification – Se- of LynxFuzzer, a framework to automatically find vulnerabil-
curity and Protection ities in kernel extensions (kexts), i.e., dynamically loadable
components of the Mac OS X kernel. Kexts are built ad-
1. INTRODUCTION hering to the IOKit framework [5], the official toolkit for
creating OS X kernel extensions (also used in the iOS envi-
Kernel security is of vital importance for a system. A vul-
ronment). LynxFuzzer uses a gray box fuzzing approach and
nerability, in any of its parts, may compromise the security
adopts dynamic test-case generation. This means that it au-
model of the whole system. Unprivileged users that find
tomatically extracts information from the target extensions
such vulnerabilities can easily crash the attacked system, or
and uses them to dynamically adapt its input generation
obtain administration privileges. Unfortunately, kernels are
techniques. More precisely, we implemented three different
an evermore attractive target for attackers, and the number
fuzzing engines inside LynxFuzzer: a simple generation en-
of kernel vulnerabilities is rising at an alarming rate [18].
gine that produces pseudo-random inputs that only respect
Looking for vulnerabilities in kernel-level code is a daunt-
kext-defined constraints, a mutation engine that builds input
ing task, because of its many intricacies. Indeed, modern
data from previously sniffed valid inputs, and an evolution-
kernels are extremely complex and have many subsystems,
based engine that leverages evolutionary algorithms [6] and
uses code coverage level as a main validating feature.
We decided to build LynxFuzzer hypervisor component
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are on top of the open source hardware-assisted virtualization
not made or distributed for profit or commercial advantage and that copies framework HyperDbg [13] mainly because of the many dif-
bear this notice and the full citation on the first page. To copy otherwise, to ficulties of running Mac OS X inside commonly available
republish, to post on servers or to redistribute to lists, requires prior specific virtualization software. In fact Apple is well-known for its
permission and/or a fee. custom hardware (e.g., the Magic Mouse), which is not often
EuroSec ’14 April 13–16, 2014, Amsterdam, Netherlands
emulated by common hypervisors. This shortcoming would
Copyright 2014 ACM 978-1-4503-2715-2/14/04 ...$15.00.
http://dx.doi.org/10.1145/2592791.2592793 ...$15.00. prevent LynxFuzzer from testing some of the drivers in OS
X. Moreover an hardware-assisted environment assures the User
User
Process
possibility of gathering dynamic information about the state Process User
User
Process
of the machine during the crash of the system. In summary Process
our work contributes the following:
User mode
• We design LynxFuzzer, a framework that is able to
Kernel mode
automatically find vulnerabilities in kernel extensions
(kexts), i.e., dynamically loadable components of the User User
Mac OS X kernel. We have tackled serveral implemen- Client Client
tation challenges to make an efficient fuzzing system. DT #1 DT #2

• We devise a set of efficient and trasparent techniques Kext

to automatically extract the fuzzing input constraints
that allow the system to reduce the inputs searching Figure 2: Invoking a kext’s method.
space and to efficiently fuzz the Mac OS X user-to-
kernel communication interface.
• We developed a prototype of the fuzzying system, and of number and type of data that can be received by and
performed an experimental evaluation on serveral kext returned to the caller. The list of these methods and con-
extensions. Our experiments show that the system is straints on their parameters are stored into a structure of ut-
able to individuate 6 bugs in 17 kexts we analyzed. most importance (both for IOKit and for our fuzzing frame-
Two of these bugs have already been patched in OS X work): the dispatch table. Each kext can define one or more
10.9 (Maverick) and have been assigned the following dispatch table. Each table is an array of structures, each
CVE-ID by Apple: CVE-2013-5166 and CVE-2013- one containing a function pointer, allowed input and output
5192. values, as well as the number and size of the values that can
be accepted (or that are returned) by the method. If the
2. IOKIT FUNDAMENTALS size of an input structure is not known a priori, the check
In this section we will give an overview of the IOKit frame- can be demanded to the receiving method, by specifying a
work, as this is basic for the understanding of LynxFuzzer. size of 0xffffffff in the table. It is possible to have, for
Mac OS X is an operating system developed by Apple and any driver, more than one dispatch table. IOKit, indeed, al-
currently adopted on Apple computers. Among its many lows kexts to offer multiple interfaces to user-space programs
components, the Kernel contains one that is particularly rel- at the same time. Each kext must also define one custom
evant for our work: the IOKit. IOKit is a “a collection of subclass of UserClient for each interface. Instances of these
system frameworks, libraries, tools, and other resources for subclasses are then loaded in the kernel memory along with
creating device drivers in OS X” [5]. It offers an object ori- the kext (Figure 2). Every UserClient object contains the
ented environment and a number of abstractions that make dispatch table corresponding to the interface it offers.
the (commonly painful) task of writing kernel components User-space programs can invoke kexts methods via IoCon-
much easier and “user space friendly”. The IOKit frame- nectCallMethod(), if the methods are specified in one of the
work contains many abstractions and components, and we kext dispatch tables. To be able to do so, however, the pro-
describe those relevant to our work in the following of this gram must first find the specific instance it wants to talk to.
section. To illustrate how this happens, we must first introduce one
more IOKit abstraction, the IOService. Each IOKit device
const I O E x t e r n a l M e t h o d D i s p a t c h driver is an object that inherits from the IOService class
UserClient :: sMethods [ k N um b er O fM e th o ds ] = { and a kext may contain different IOService objects at the
{ same time. Let us consider an example. There are typically
/* kMyScalarIStructIMethod */
( I O E x t e r n a l M e t h o d A c t i o n ) & UserClient :: sScalarIStructI , many USB devices connected to a computer and each one
/* One scalar input value */ needs its own driver. Such drivers are all contained in the
1, IOUSBFamily kext, and each of them is a specific IOService
/* The size of the input struct */
sizeof ( MySampleStruct ) ,
subclass (service, for short) for a device. When a user-space
/* No scalar output values */ process wants to communicate with one device, as we men-
0, tioned above, it establishes a mach connection [17] to IOKit
/* No struct output value */
0
and searches for the specific service associated to the device.
}, This process is called Device Matching [5].
/* ... */ Once the communication channel is established and the
} service is found, the user-space program uses IoConnect-
Figure 1: A sample dispatch table. CallMethod() to invoke the desired method. This transfers
A fundamental component of every OS is the communica- the control to the IOKit framework that, before actually ex-
tion between user- and kernel-space components. Windows ecuting the target method, performs a set of operations. At
and Linux offer such functionality through system calls and first, it retrieves the dispatch table entry from the UserClient
special virtual files (e.g., /dev/urandom). IOKit supports object. The entry is then passed to the externalMethod()
both techniques, but also adds a novel and much more com- function along with other parameters that allow to perform
plex mechanism, named DeviceInterface [17, 5]. the actual invocation of the kext method. This, however,
To leverage this mechanism, Kernel extensions [21] (i.e. happens only if the parameters correspond to what is speci-
drivers) define a set of methods that can be invoked by user- fied by the dispatch table entry, otherwise the invocation is
space programs. Such methods have limitations in terms blocked.
 The whole IOKit input control mechanism offers an addi- however, is not easy, since IOKit uses a number of abstrac-
tional protection layer, with respect to common mechanisms tion layers to hide such information to user-space programs.
such as ioctl, because checks are performed before param- We devised a solution by observing that, whenever a user-
eters are even moved from user- to kernel-space. Obviously, space program invokes IoConnectCallMethod(), the IOKit
all these constraints make the fuzzing process quite complex. will invoke its externalMethod() function. Thus, we pro-
It is almost useless to just fuzz functions of a kext with com- ceed as follows. LynxFuzzer hypervisor sets a breakpoint on
pletely random parameter sizes, as most invocations would the externalMethod() function and intercepts whenever it
be discarded by checks performed by IOKit. As we will see is executed. Once the trap is set, the tracer issues a request
in the next section, one of the key aspects of our fuzzer is its to the target kext with a selector value of 0. When the
ability automatically extract constraints on parameters from hypervisor intercepts the resulting externalMethod() exe-
the target and dynamically adapt its fuzzing techniques to cution, it extracts the base of the dispatch table, uses it to
get better efficiency. dump the whole table, and eventually returns it to the tracer
component. Finally, the tracer stores the extracted dispatch
3. LYNXFUZZER table into the data manager, so that other components can
The purpose of our fuzzer is to trigger bugs in kext code leverage this information for their operations.
that can be reached by user-space programs, by means of Note that the size of the dispatch table is not known a
the IOKit framework. A bug triggerable by user-space, in- priori, nor is contained in the parameters of the trapped
deed, may allow un-privileged users to crash the system, function. To solve this problem, LynxFuzzer leverages the
or even obtain arbitrary kernel-level code execution, which structured nature of such tables to infer how many entries
typically leads to privilege escalation attacks [20]. Further- it has and dump it. Indeed, each table entry is formed by:
more, we decided to focus our efforts on the DeviceInterface a function pointer, which must reside in the memory area
boundary-crossing mechanism, since it became the de facto of the target, and 4 consecutive integers, two of which must
user-to-kernel communication standard for OS X kernel ex- fall in the [0:16) range.
tensions. 3.2 Sniffer
As it should be clear from what we described in section 2,
there are many constraints that must be considered when Beside the checks performed by IOKit, the kext itself
invoking a kext method and such constraints are specific to could implement constraints on input values. Thus, Lynx-
each kext. Knowing constraints contained in the dispatch Fuzzer includes a sniffer component, that is able to intercept
table allows us to reduce the possible fuzzing space to what real executions (i.e., not artificially triggered by our frame-
is actually accepted by the kext, thus gaining much more ef- work) of the target methods and to extract their parameters.
ficiency. Thus, we designed LynxFuzzer so that it can extract To do so, we once again leverage LynxFuzzer hypervisor com-
these information in a completely automatic fashion and fuzz ponent that is able to transparently and seamlessly intercept
them autonomously. Furthermore, the automation of our whenever an interesting function is executed, and dump its
fuzzing infrastructure is not limited to this. Indeed, we are parameters, by inspecting the target kext memory.
able to extract valid input vectors used in non-artificial in- In particular, the hypervisor places a transparent break-
teractions between user- and kernel-level components. Such point on the externalMethod() function, whose parameters
inputs are used as a basis to elaborate new inputs aimed at contain enough information to retrieve valid inputs. Indeed,
improving the fuzzing strategy. the hypervisor uses the dispatch argument to discriminate
An overview of LynxFuzzer architecture is depicted in Fig- which kext is the target of the intercepted invocation and
ure 3. Our framework has two main components: one that selector to understand the method being called. Valid in-
resides in user-space and consists of 4 sub-components, and puts are extracted from IOExternalMethodArguments struc-
one built on top of our hypervisor analysis framework. Fig- ture containing the actual parameters that will be passed to
ure 3 also reports the main interactions between LynxFuzzer the callee. Such data structure contains fields that allow to
internal components. The tracer interacts with the hyper- precisely infer the number and size of input parameters that
visor to identify where the dispatch tables of the target are will be stored into the data manager.
(1, 2). Once discovered, the hypervisor retrieves them from 3.3 Fuzzer
the kernel memory and sends them back to the tracer that
stores them into the data manager for later use (2, 3). The
sniffer uses such information to intercept non-artificial Io- GE
ConnectCall() invocations and gather a set of valid inputs Request
ME Monitor
(4, 5). Finally, the fuzzer components starts invoking the Generator
EE
target methods with custom parameters (6), waiting for an
eventual panic (7). Depending on the selected fuzzing en-
gine, the fuzzer may use valid inputs precedently stored in
the data manager to generate new inputs or leverage cover-
age information (8). Target

3.1 Tracer
The tracer is the first component of LynxFuzzer to be ex- Figure 4: Fuzzer sub-components.
ecuted, as its task is finding out what to fuzz, i.e., it must
identify which of the target methods can be invoked. This The fuzzer is the main component of LynxFuzzer. After
information is contained into the dispatch tables of the tar- the tracer and the sniffer obtained all the ancillary informa-
get kext. Being able to locate the dispatch table of a kext, tion needed to properly fuzz one (or more) kext, the fuzzer
 5.Valid Inputs 7.Panic Inputs/Statistics
Data Manager

3.Dispatch Tables
6.IoConnectCall
Sniffer Tracer Fuzzer

User mode

2.Dispatch Table

8.Coverage Info.
Kernel mode

4.System
Requests
1.IoConnectCall

Entries
Target

Inspect/Intercept
Non-root mode
Root mode
Hypervisor

Figure 3: Architecture of LynxFuzzer and interactions between its components (gray areas).

creates test cases (i.e., set of inputs) for the kext methods target method. Then, it generates pseudo-random inputs
and invoke them through the IOKit device interface. Fig- and fill the structure that are then sent to the target, in-
ure 4 reports the inner architecture of the component, that voking the method through IoConnectCallMethod(). If the
has three main parts: a request generator, a set of fuzzing system does not crash, then the procedure begins anew.
engines and a monitor.
The request generator is an extremely versatile compo- 3.3.2 Mutation Engine (ME)
nent: it must operate independently from the target kext This second fuzzing approach follows a principle that is
and the selected fuzzing engine. In a typical execution, it the opposite of the previous one: every new input is gener-
receives a test case from the engine, checks that it respects ated from valid inputs collected by the sniffer component.
what is specified in the dispatch table entry of the target The fuzzing process is roughly made of the following steps.
method and properly crafts the argument for an IoConnect- Valid inputs that were previously gathered by the sniffer are
CallMethod() that eventually executes the target method in mutated with different functions. Then, request containing
the kext. such forged inputs are sent to the target method. If the
If the test case does not cause a crash, the kext sends back system does not crash, the monitor checks the response of
an answer that is received by the monitor. Depending on the kext, possibly excluding values that caused the kext to
the received answer and on the engine currently in use, the return an error from next mutations. This greatly increases
monitor may decide to alter the engine so that the next test the efficiency of the fuzzer, in the case of inputs structures
case will depend on the result of the previous one. As we with a variable size, because it gradually eliminates those
will see later in this section, both the mutation engine and that are not accepted because of checks performed in the
the evolution engine leverage this information. code of the target method. The set of mutation functions
LynxFuzzer, furthermore, implements the concept of session- used by this engine includes: bit flipping, byte flipping, byte
based fuzzing: we do not save just the request that triggers swapping and size change.
the bug, but we record every request that we make from the
beginning of the fuzzing session. This practice is common 3.3.3 Evolution Engine (EE)
when fuzzing stateful network protocols [8], but is also use-
ful in our scenario. There are indeed kexts that maintain The evolution engine tries to overcome the limitations of
a “state” that is changed by a number of different fuzzing the previous ones. In an effort to reduce the use of pseudo-
requests until an invalid state is reached and a bug is trig- randomness, it leverages concepts of evolutionary algorithms
gered. For this reason, recording communication sessions, to generate new inputs.
instead of single requests, greatly improves the reproducibil- The hearth of any evolutionary algorithm is the fitness
ity of a bug. To record communication sessions between the function, that depicts the fittest elements that will con-
fuzzer and a target kext, every request is stored in the data tribute to build new generations. In LynxFuzzer, we devised
manager. Finally, the fuzzing engine is responsible for the two different fitness functions: one that measures the code
production of input values (or input vectors) that will be coverage of an input vector and one that measures the dis-
used by the request generator. Details of the three different tance of an input from an ideal target vector (input that
engines that we implemented in LynxFuzzer are described in crashes the system). In the first case, we strive to create a
the following sections. set of input vectors that can give us the best code-coverage
rate possible. The second, on the other hand, is useful when
we want to individuate inputs similar to a given one (e.g., a
3.3.1 Generation Engine (GE) vector that is known to trigger a bug in the target).
This is the simplest and quickest engine of the three. Its
generation process may be summed up as follows. At first, Code coverage analysis. Our code coverage analysis meth-
it builds data structures that can contain the input for the od works as follows. Before starting to invoke kext methods,
 Code Coverage Perc. No. of Rps w/o Rps w/ Over-
Kext Methods Estimation Full
Kext
Inst. Tracing Tracing head

IOUSBFamily 64.8% 61.1% 33.7% AppleSMCLMU 1890 668.28 385.90 1.73x

AppleMikeyDriver 17457 517.54 283.28 1.83x
IOHIDFamily 86.4% 69.9% 11.4% AppleHDAController 12294 591.82 273.77 2.16x
SimpleDriver 96.6% 77.3% 34.3% IOHDAFamily 3376 634.17 278.41 2.28x
IOSurface 76.6% 58.8% 18.5% AppleSMC 5608 651.99 284.31 2.29x
AppleUSBHub 86.9% 54.5% 37.5% IOSurface 8866 434.84 112.44 3.87x
AppleHDA 101532 635.39 164.20 3.87x
IOUSBFamily 49920 204.89 42.76 4.79x
Table 1: Coverage analysis results. SimpleDriver 2261 424.91 74.01 5.74x
IOHIDFamily 63915 278.00 46.44 5.99x
Overall — — 3.45x
the fuzzer component communicates to the hypervisor (via
hypercall) the range of code pages of the kext. The hypervi- Table 2: Overhead of the code coverage analysis.
sor removes the EXEC permission from the EPT entries cor-
responding to received memory ranges. As soon as the kext
tries to execute code in such pages, it triggers an EPT vio- the target is another method of the same kext, we add its
lation and the hypervisor keeps track of the instruction that instructions to the overall count.
caused it. To proceed, it restores EXEC permission on the Unfortunately, this is not enough because, due to their
faulting page and configures the guest to perform a single- object-oriented nature, kexts include a high number of in-
step. When the hypervisor gets the control back, because direct CTIs, that cannot be followed statically. For such in-
of the resulting debug exception, it removes the permission, structions, we revert to dynamic analysis: we modified Lynx-
so that the next instruction will violate again. Once the Fuzzer code coverage analysis module so that it dumps the
fuzzed methods returns, the fuzzer sends another hypercall target of every indirect CTI executed in the kext code. If the
to disable the tracing. The hypervisor stores collected in- target corresponds to a method of the kext that had not been
formation into a buffer in the fuzzer address space so that deemed reachable by the static analysis, then we update the
it can be used by the user-space component to calculate the instructions count with the newly discovered method.
code coverage corresponding to the invocation. Table 1 reports the code coverage results of a subset of the
fuzzed kexts. Under the “Coverage” column we report three
different code coverage percentages, respectively calculated
4. EXPERIMENTAL EVALUATION over: the number of instructions of exported methods, the
This section presents the result of the experiment we con- static/dynamic estimation we just described and, finally, the
ducted to evaluate the effectiveness of LynxFuzzer. To this overall number of instructions contained in the kext.
purpose, we used the fuzzer to exercise a set of 17 differ- We also evaluated the overhead introduced by our code
ent Kernel Extensions and we found 6 bugs in them1 . More coverage method that we described in Section 3.3. To mea-
detailedly, 2 of the 6 have already been patched in OS X sure it, we run the generation engine on each method of 10
10.9 (Maverick) and have been assigned the following CVE- different kexts, with and without the code coverage analysis
ID by Apple: CVE-2013-5166 and CVE-2013-5192 [4]. The enabled, and measured the consequent decrease in terms of
remaining 4 are still unpatched and will be most likely ad- requests per second the kext was able to serve. For the sake
dressed in the next releases of OS X. of precision, measurements were repeated 10 times for each
All the experiments were conducted on a Mac OS X 10.8.2 module and results were averaged. The average overhead is
system (Mountain Lion), installed on Apple hardware (In- 3.45x, with a best and worst case of, respectively, 1.73x and
tel i5 CPU and 12GB of RAM). Thanks to the adoption 5.99x. Detailed results of this evaluation are reported in Ta-
of kernel-security measures in OS X, none of the bugs we ble 2. As we can see, we pay a high price for obtaining full
identified can be easily exploited to perform a privilege es- precision without modifying the target, yet this is a much
calation attack. lower overhead if compared with other techniques [22].
A metric that is usually associated with efficiency of a Finally, during our experiments we also measured the ef-
fuzzer, is the code coverage level. However, as also stated ficacy of each input generator engines to discover bugs. In
in [14], such metric may not be extremely significant: a particular we show that all the engines utilized were able to
fuzzer could even reach 100% code coverage of the analyzed discover the bugs with some difference in terms of perfor-
code, but yet fail at finding a bug. Since it is customary to mance. In particular the Evolution Engine with the code
report such information, however, we conducted an experi- coverage-based fitness function was faster than the other
ment to calculate the code coverage level of LynxFuzzer. two, while the Generation Engine was the slowest one.
Even if our hypervisor component can easily keep track
of every instruction that is executed in a given time-frame
(e.g., during the fuzzing), giving a precise measure of the
5. RELATED WORK
coverage of a kext is quite challenging. To give an estima- The closest work to LynxFuzzer is found in an online pre-
tion of the amount of code that can be reached from methods sentation by Xiaobo and Hao [10] that briefly analyzes the
exported in the dispatch table we use, once again, a hybrid possibility of fuzzing OS X kernel extensions through Devi-
static-dynamic technique. First, we statically count the in- ceInterface. Unfortunately, a deep comparison between such
structions of the exported methods and individuate all the work and LynxFuzzer is hindered by the lack of details of the
control transfer instructions (CTI). Then, for each CTI, if former. The depicted approach appears to be largely manual
and there is neither an analysis of performances nor results
1 of conducted fuzzing activities to compare.
Obviously, all the bugs were reported to Apple or the ap-
propriate vendor. Another similar, yet extremely more specific, approach is
presented by Keil and Kolbitsch [15] who propose a stateful [4] Apple. About the security content of OS X Mavericks
fuzzer for 802.11 device drivers. Beside its usage of stateful v10.9, Oct. 2013.
fuzzing, LynxFuzzer is quite different from this work, since it http://support.apple.com/kb/HT6011.
addresses generic kernel extensions and leverages hardware- [5] Apple Inc. I/O Kit Fundamentals.
assisted virtualization instead of emulation. https://developer.apple.com.
SLAM is a model checking engine whose goal is to au- [6] D. Ashlock. Evolutionary computation for modeling
tomatically verify if a program correctly uses external li- and optimization. Springer Science+ Business Media,
braries [7, 12]. On top of such engine, Microsoft created 2006.
Static Driver Verifier, a tool to automatically analyze the [7] T. Ball, B. Cook, V. Levin, and S. K. Rajamani.
source code of Windows device drivers and determine whether SLAM and static driver verifier: Technology transfer
they correctly interact with the Windows kernel. SLAM has of formal methods inside Microsoft. In Integrated
many limitations, if compared to LynxFuzzer. First, it re- formal methods, pages 1–20. Springer, 2004.
quires the source code of the drivers it analyzes. Second, its [8] G. Banks, M. Cova, V. Felmetsger, K. Almeroth,
scope is limited to the correctness of interactions with known R. Kemmerer, and G. Vigna. Snooze: toward a
libraries. Finally, users of SLAM must feed it with manu- stateful network protocol fuzzer. In Information
ally created rules that the tool will check for the verification, Security, pages 343–358. Springer, 2006.
thus requiring some manual effort.
[9] C. Cadar, V. Ganesh, P. M. Pawlowski, D. L. Dill, and
S2 E [11] is a binary analysis framework that implements
D. R. Engler. EXE: Automatically generating inputs
the idea of selective symbolic execution, a method to mini-
of death. In Proceedings of the 13th ACM Conference
mize the amount of code that needs to be executed symboli-
on Computer and Communications Security, 2006.
cally. Even if remarkably useful, for example we could use it
to simbolically execute every hardware-interacting part of a [10] X. H. Chen Xiaobo. Find Your Own iOS Kernel Bug,
kext, S2 E has some drawbacks. First, the runtime overhead 2012.
of 6x for concrete execution and 78x for symbolic execution [11] V. Chipounov, V. Kuznetsov, and G. Candea. S2e: A
is extremely high. Second, it is strongly binded to QEMU platform for in-vivo multi-path analysis of software
and, as we stated before, running Mac OS X inside an em- systems. In Proceedings of the 16th International
ulator is not trivial. Conference on Architectural Support for Programming
Dowser is probably the most advanced approach to fuz- Languages and Operating Systems, Newport Beach,
zing targeted at finding buffer overflows [14]. It uses a mix of California, USA, 2011.
static program analysis, concolic execution, and taint track- [12] E. M. Clarke, O. Grumberg, and D. A. Peled. Model
ing to automatically steer the execution of a program to in- checking. MIT press, 1999.
teresting locations, more likely to contain a buffer overflow. [13] A. Fattori, R. Paleari, L. Martignoni, and M. Monga.
In particular, the observation behind Dowser is that there Dynamic and transparent analysis of commodity
are particular sets of instructions that are more error-prone production systems. In Proceedings of the 25th
than others (e.g., pointer arithmetic). Dowser is extremely International Conference on Automated Software
powerful, and LynxFuzzer could benefit by adopting a sim- Engineering (ASE), September 2010.
ilar approach to its fuzzing activities. Unfortunately, our [14] I. Haller, A. Slowinska, M. Neugschwandtner, and
approach is aimed at testing closed source software, while H. Bos. Dowsing for overflows: A guided fuzzer to find
Dowser relies on the source code of the target to locate in- buffer boundary violations. In Proceedings of 22nd
teresting instructions. USENIX Security Symposium, Washington, DC, USA,
Finally EXE [9] and SmartFuzzer [16] are similar to Lynx- 2013.
Fuzzer, as they both use a combination of static and dynamic [15] S. Keil and C. Kolbitsch. Stateful fuzzing of wireless
analysis to automatically generate inputs vector that can ef- device drivers in an emulated environment. Black Hat
ficiently exercise user-space applications. Japan, 2007.
[16] A. Lanzi, L. Martignoni, M. Monga, and R. Paleari. A
6. CONCLUSION smart fuzzer for x86 executables. In Proceedings of the
LynxFuzzer is a fuzzing framework for Mac OS X kernel 3rd International Workshop on Software Engineering
extensions. LynxFuzzer leverages hardware-assisted virtual- for Secure Systems, 2007.
ization and three different input-generation engines to dis- [17] J. Levin. Mac OS X and IOS Internals: To the
cover bugs that could lead unprivileged users to crash the Apple’s Core. Wrox, 2012.
machine or to attempt privilege-escalation attacks. We im- [18] NIST. CVE and CCE statistics.
plement a prototype and we show in our experiments the http://web.nvd.nist.gov/view/vuln/statistics.
efficiency and efficacy of our system. LynxFuzzer was able [19] NIST. CVE-2013-0976, 2013. http://web.nvd.nist.
to discover bugs in 6 of them in 17 kernel extensions of Mac gov/view/vuln/detail?vulnId=CVE-2013-0976.
OS X Mountain Lion. [20] E. Perla and M. Oldani. A guide to kernel
exploitation: attacking the core. Syngress, 2010.
7. REFERENCES [21] A. Singh. Mac OS X Internals: A Systems Approach.
[1] CVE-2010-1794, 2010. http://web.nvd.nist.gov/ Addison-Wesley Professional, 2006.
view/vuln/detail?vulnId=CVE-2010-1794. [22] M. L. Soffa, K. R. Walcott, and J. Mars. Exploiting
[2] CVE-2013-0109, 2013. http://web.nvd.nist.gov/ hardware advances for software testing and debugging.
view/vuln/detail?vulnId=CVE-2013-0109. In Proceedings of the 33rd International Conference on
[3] CVE-2013-0981, 2013. http://web.nvd.nist.gov/ Software Engineering, 2011.
view/vuln/detail?vulnId=CVE-2013-0981.