Analysis of Linux Kernel Vulnerabilities (PDF)

Linux kernel vulnerabilities:
State-of-the-art defenses and open problems
Haogang Chen Yandong Mao Xi Wang Dong Zhou†
Nickolai Zeldovich M. Frans Kaashoek
MIT CSAIL †Tsinghua University
ABSTRACT
Avoiding kernel vulnerabilities is critical to achieving security of
many systems, because the kernel is often part of the trusted com-
puting base. This paper evaluates the current state-of-the-art with
respect to kernel protection techniques, by presenting two case
studies of Linux kernel vulnerabilities. First, this paper presents
data on 141 Linux kernel vulnerabilities discovered from January
2010 to March 2011, and second, this paper examines how well
state-of-the-art techniques address these vulnerabilities. The main
findings are that techniques often protect against certain exploits
of a vulnerability but leave other exploits of the same vulnerabil-
ity open, and that no effective techniques exist to handle semantic
vulnerabilities—violations of high-level security invariants.
1. INTRODUCTION
An OS kernel is a part of the trusted computing base (TCB) of
many systems. Vulnerabilities in the kernel itself can allow an
adversary to bypass any kernel protection mechanisms, and com-
promise the system, such as gaining root access. Much research
has gone into mitigating the effects of kernel vulnerabilities, but
kernel vulnerabilities, and more importantly, kernel exploits, are
still prevalent in Linux. This paper investigates where the research
community may want to focus its attention, by analyzing past Linux
kernel vulnerabilities, categorizing them, evaluating what defensive
techniques might have been used to prevent them, and speculating
on what the remaining open problems are.
Surprisingly few studies have been performed to understand the
types of kernel vulnerabilities that occur in practice. A study by
Arnold et al. [3] argues that every kernel bug should be treated as
security-critical, and must be patched as soon as possible. Mokhov
et al. explore how kernel programmers patch known vulnerabili-
ties [19]. Christey and Martin report on vulnerability distributions
in CVE [8]; our study is also based on CVE and our findings are
consistent with that study, but ours focuses only on kernel vulnera-
bilities. Neither of the studies shed light on what techniques could
be used to prevent unknown vulnerabilities from being exploited. In
this paper, we present a case study of Linux kernel vulnerabilities
discovered from January 2010 to March 2011. We categorize these
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
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$10.00.
vulnerabilities by the kind of programming mistake the developers
made, and the impact it has on security.
Based on this list of kernel vulnerabilities, we perform a second
case study, by examining how effective techniques proposed by re-
searchers might be at mitigating vulnerabilities in the Linux kernel.
These techniques include runtime mechanisms such as code integrity
checks [22], software fault isolation [6, 15], and user-level device
drivers [5], as well as bug-finding tools and static analysis [1, 2].
This examination is not empirical, but is based purely on our un-
derstanding of the techniques. Nonetheless, we believe it can be
helpful in identifying what classes of vulnerabilities can already be
solved, and what open problems remain.
The findings of our two studies are as follows. First, we find
that there are 10 common classes of kernel vulnerabilities in Linux,
which may lead to attacks ranging from arbitrary memory modifi-
cations to information leaks to denial-of-service attacks. Second,
we find that about2/3 of the vulnerabilities are in kernel modules
or drivers, and that conversely, 1/3 of the bugs are found in the
core kernel. Third, we find that no single existing technique can
prevent all kernel vulnerabilities, and that a technique often miti-
gates some exploits of a vulnerability but does not address other
exploits of the same vulnerability. Fourth, there are certain classes of
vulnerabilities that are not addressed at all. For example, semantic
vulnerabilities, where high-level security invariants are violated, are
difficult to catch with state-of-the-art techniques that focus mostly
on memory safety and code integrity.
2. LINUX KERNEL VULNERABILITIES
Figure 1 categorizes the 141 Linux kernel vulnerabilities pub-
lished on the CVE list from January 2010 to March 2011 and the
type of attacks that can exploit the vulnerability. Despite their di-
versity, most of these vulnerabilities fall into 10 categories, based
on the kind of programming mistake the developers made, as listed
in the first column. Since each vulnerability can often be exploited
in several ways, we further categorize the exploits in several at-
tack classes. Memory corruption typically allows an adversary to
perform arbitrary operations in the kernel, and is thus a superset
of other types of attacks, such as policy violation, DoS, informa-
tion disclosure, and others. Therefore if a vulnerability leads to a
memory-corruption attacks, we do not count it under other attack
classes. The rest of this section discusses the types of vulnerabilities
we have found.
Missing pointer checks. The kernel omits access_okchecks or
misuses “faster” operations such as__get_user, which does not
validate the value of user-provided pointers or index variables to
ensure that they point to user-space memory only. These bugs enable
unprivileged processes to read from or write to arbitrary kernel
memory locations, leading to memory corruption (CVE-2010-4258),

Vulnerability Mem. corruption Policy violation DoS Info. disclosure Misc.
Missing pointer check 6 0 1 2 0
Missing permission check 0 15 3 0 1
Buffer overflow 13 1 1 2 0
Integer overflow 12 0 5 3 0
Uninitialized data 0 0 1 28 0
Null dereference 0 0 20 0 0
Divide by zero 0 0 4 0 0
Infinite loop 0 0 3 0 0
Data race / deadlock 1 0 7 0 0
Memory mismanagement 0 0 10 0 0
Miscellaneous 0 0 5 2 1
Total 32 16 60 37 2
Figure 1: Vulnerabilities (rows) vs. possible exploits (columns). Some vulnerabilities allow for more than one kind of exploit, but
vulnerabilities that lead to memory corruption are not counted under other exploits.
Vulnerability Total core drivers net fs sound
Missing pointer check 8 4 3 1 0 0
Missing permission check 17 3 1 2 11 0
Buffer overflow 15 3 1 5 4 2
Integer overflow 19 4 4 8 2 1
Uninitialized data 29 7 13 5 2 2
Null dereference 20 9 3 7 1 0
Divide by zero 4 2 0 0 1 1
Infinite loop 3 1 1 1 0 0
Data race / deadlock 8 5 1 1 1 0
Memory mismanagement 10 7 1 1 0 1
Miscellaneous 8 2 0 4 2 0
Total 141 47 28 35 24 7
Figure 2: Vulnerabilities (rows) vs. locations (columns).
information disclosure (CVE-2010-0003), DoS (CVE-2010-2248),
or privilege escalation (CVE-2010-3904 and CVE-2010-3081) if
the process controls what data to write.
Missing permission checks. The kernel performs a privileged oper-
ation without checking whether the calling process has the privilege
to do so. A vulnerability in this category results in a violation of a
kernel security policy. The attacks that can exploit this vulnerability
depend on what the security policy is, ranging from arbitrary code
execution (CVE-2010-4347), privilege escalation (CVE-2010-2071
and CVE-2010-1146), to overwriting an append-only file (CVE-
2010-2066 and CVE-2010-2537).
Buffer overflow.The kernel incorrectly checks the upper or lower
bound when accessing a buffer (CVE-2011-1010), allocates a smaller
buffer than it is supposed to (CVE-2010-2492), uses unsafe string
manipulation functions (CVE-2010-1084), or defines local variables
which are too large for the kernel stack (CVE-2010-3848). The
attacks that can exploit this vulnerability are memory-corruption
(for writes) or information-disclosure (for reads) attacks. An adver-
sary can mount privilege-escalation attacks by overwriting nearby
function pointers and subverting the kernel’s control flow integrity.
Integer overflow.The kernel performs an integer operation incor-
rectly, resulting in an integer overflow, underflow,or sign error.
The adversary can trick the kernel into using the incorrect value
to allocate or access memory, allowing similar attacks as allowed
by “buffer overflow” vulnerabilities.For example, overflow after
multiplication can cause the kernel to allocate a smaller-than-needed
buffer (CVE-2010-3442); underflow after subtraction can cause
memory corruption beyond the end of a buffer (CVE-2010-3873);
and sign errors during comparison can bypass bounds checking and
cause information disclosure (CVE-2010-3437).
Uninitialized data. The kernel copies the contents of a kernel buffer
to user space without zeroing unused fields, thus leaking potentially
sensitive information to user processes, such as variables on the
kernel stack (CVE-2010-3876). This category has 29 vulnerabilities,
the highest of all categories. A direct attack using this vulnerability
results in unintended information disclosure. However, vulnerabili-
ties in this category may enable other attacks, such as attacks that
require knowing the exact address of some kernel data structure,
private kernel keys, or other kernel randomness.
Memory mismanagement. This category includes vulnerabilities
in kernel memory management, such as extraneous memory con-
sumption (CVE-2011-0999), memory leak (CVE-2010-4249), dou-
ble free (CVE-2010-3080), and use-after-free errors (CVE-2010-
4169 and CVE-2010-1188). For the vulnerabilities that we ex-
amined, an adversary can mount DoS attacks by exploiting them,
although in general arbitrary memory corruption may be possible.
Miscellaneous. There are other types of vulnerabilities that usually
result in either process crashes, kernel panics, or hangs, such as null
pointer dereferences, divide by zeros (CVE-2011-1012 and CVE-
2010-4165), infinite loops (CVE-2011-1083 and CVE-2010-1086),
deadlocks (CVE-2010-4161), and data races (CVE-2010-4526 and
CVE-2010-4248).
One observation from the Figure 1 is that buffer and integer over-
flows are the top threats to the kernel’s integrity: 78% of memory
corruption exploits are caused by these two vulnerabilities. This
observation is consistent with the report by Christey and Martin [8].
Figure 2 shows the distribution of the vulnerabilities in the Linux
kernel source code tree, namely, the code statically linked into the
kernel image (“core”), device drivers (drivers ), network protocols
(net), file systems (fs ), and the sound subsystem (sound). We
observe that a non-trivial portion (1/3) of vulnerabilities are located
in the core kernel, while2/3 are in loadable kernel modules. Less
than 20% of vulnerabilities that we examined are in device drivers.
3. STATE-OF-THE-ART PREVENTION