Analysis of Linux Kernel Vulnerabilities (PDF)

Added on - 01 Oct 2021

  • 5


  • 5691


  • 15


  • 0


Trusted by +2 million users,
1000+ happy students everyday
Showing pages 1 to 2 of 5 pages
Linux kernel vulnerabilities:
State-of-the-art defenses and open problems
Haogang ChenYandong MaoXi WangDong Zhou
Nickolai ZeldovichM. Frans Kaashoek
MIT CSAILTsinghua University
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
respectto kernelprotection 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.
An OS kernel is a part of the trusted computing base (TCB) of
many systems.Vulnerabilities in the kernelitself 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 digitalor hard copies of allor partof 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/3of the vulnerabilities are in kernel modules
or drivers,and that conversely,1/3of 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.
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 severalat-
tackclasses.Memory corruptiontypically allows an adversary to
perform arbitrary operations in the kernel, and is thus a superset
of other types of attacks, such aspolicy 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 omitsaccess_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),
VulnerabilityMem. corruptionPolicy violationDoSInfo. disclosureMisc.
Missing pointer check60120
Missing permission check015301
Buffer overflow131120
Integer overflow120530
Uninitialized data001280
Null dereference002000
Divide by zero00400
Infinite loop00300
Data race / deadlock10700
Memory mismanagement001000
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.
Missing pointer check843100
Missing permission check17312110
Buffer overflow1531542
Integer overflow1944821
Uninitialized data29713522
Null dereference2093710
Divide by zero420011
Infinite loop311100
Data race / deadlock851110
Memory mismanagement1071101
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 thatwe 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
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/3are in loadable kernel modules. Less
than 20% of vulnerabilities that we examined are in device drivers.
You’re reading a preview
Preview Documents

To View Complete Document

Click the button to download
Subscribe to our plans

Download This Document