-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathintroduction.tex
171 lines (154 loc) · 10 KB
/
introduction.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
\section{Introduction}
\label{sec.introduction}
%\cappos{Paragraph: Bad guys (hackers, NSA, etc.) are using zero day bugs in
%the kernel to do bad things...}
%For many years system designers and developers have had to deal with a common security issue --
%how to defend against threats hidden within the system's own code. Despite
% decades of effort, researchers still frequently uncover new flaws in operating
% system kernels. Such flaws are dangerous because, if triggered by an untrusted
% program, these bugs can lead to such security threats as privilege escalation
% [CVE-2016-0728], [CVE-2015-8660], denial of service [CVE-2015-8539], [CVE-2015-5364],
% and memory corruption [CVE-2014-9529].
%
The number of attacks in which zero-day vulnerabilities have been exploited has more than
doubled from 2014 to 2015~\cite{zero-day}. Skilled hackers can find a security
flaw in a system and use it to hold the system's users hostage , e.g., by
gaining root access and compromising the host~\cite{linux-0day}. Similarly, zero-day
vulnerabilities can be exploited~\cite{fbi-0day} or held back~\cite{nsa-0day} by government
agencies, thus rendering millions of devices vulnerable.
%for national security reasons
%\cappos{Must be OS kernel zero days. Firefox
%doesn't matter and privacy isn't the biggest concern. It's someone breaking
%into systems due to a flaw like this.}
%It is difficult to defend against these new and
%unknown vulnerabilities, leading to an arms race between hackers and software
%developers.
%
In theory, running a program in an operating-system-level virtual machine (OSVM) like Docker or LXC should
prevent it from triggering bugs in the host OS kernel. However, to be
effective, the isolation provided by such systems must meet two challenging criteria. First, the OSVM's
software must not contain any bugs that could allow the program to escape the
machine's containment and interact directly with the host OS.
Unfortunately, these issues are very common in OSVMs. Virtualbox reports more than 40 such
vulnerabilities~\cite{Virtualbox-Vulnerabilities} and more than 100 bugs have
been found in VMware Workstation~\cite{VMWare-Vulnerabilities}.
Given the large amount of complex code needed for such a system, it is understandable that flaws could occur,
leaving tens of millions of user machines at risk~\cite{linux-0day}.
Secondly, isolation will not work if a malicious
program can access a portion of the host OS's kernel that contains a
zero-day flaw \cite{CVE-2016-5195}. This may occur even if the containment of the OSVM is
working as designed.
Many system calls made within an OSVM eventually
result in calls in the host OS (e.g., network I/O from the guest
OSVM results in network I/O by the host OS kernel). If one of these paths in
the OS kernel contains a zero-day security bug, the attacker
may be able to trigger and exploit it.
%aspect of this isolation is preventing the program from triggering bugs
%in the host OS kernel or in the OSVM itself. However,
%The search for an ideal way to protect kernel code has been hampered by limited
%knowledge of the security impact of its interaction with user programs.
%A number of strategies have been attempted. One prevailing belief was that virtual
%machines could provide enough isolation to execute programs safely.
%However, when Virtualbox reports 40 vulnerabilities \cite{Virtualbox-Vulnerabilities},
% and more than 100 bugs have been found in VMware Workstation,
%it suggests that isolation alone may not be enough. Other researchers have looked
% to the development of metrics capable of pinpointing bugs, and,
%securing just those vulnerable areas\cite{PittSFIeld, ozment2006milk}. As these
%examples indicate, the design of secure systems has been somewhat, hit-or-miss.�
% Observations may lead to
% the reduction of specific threats, but not to a reproducible, broadly applicable,
%quantitative design solution.
%With this paper, we move one step closer to designing secure OSVM systems that are
%resilient to zero-day flaws.
In this paper, we propose a new security metric that helps devise designs for secure OSVM systems that are
resilient to zero-day flaws.
We discovered that security bugs in the Linux kernel have strong correlation with popular paths.
We start with the proposition that kernel code found in popular paths, associated with frequently-used programs,
has less potential risk of bugs than code in less-used parts of the kernel.
Our intuition behind this proposition is that bugs in the popular paths are
more frequently found in software testing, because of the numerous times they are executed by
diverse pieces of software.
We performed a quantitative analysis of resilience
to flaws in two versions of the Linux kernel (version 3.13.0 and version 3.14.1), and
found that only about 3\% of the bugs were present in popular code paths,
despite these paths accounting for about one third of the total reachable
kernel code.
This key information inspired the idea that
if we could design virtual machines that only use popular kernel paths,
it would greatly increase resilience to zero-day bugs in the host OS kernel.
%When we ran the same study on the same Linux kernel versions
%using two other metrics
%(Chou \cite{PittSFIeld} and Ozment \cite{ozment2006milk}),
%we found them less effective at predicting the location of zero-day bugs.
Unfortunately, demonstrating that security bugs are concentrated on unpopular
code paths is only the first step to arguing that this leads to useful and
practical design approaches. Potential objections, which we evaluated are:
\begin{itemize}
\item It might not be possible in real-life codebases to successfully avoid ``uncommon'' paths. Perhaps other applications, or future versions of the applications we tested, frequently require the use of ``uncommon'' paths, thus making our metric untenable?
\item The exploits that adversaries use change over time. Perhaps our observation that common paths are safer is only an artifact of when we did our measurements and is not predictive of future exploits?
\item Lastly, can developers make use of this observation in a practical setting? That is, is it feasible for developers to actively try to avoid uncommon code paths?
\end{itemize}
To test these objections we built a prototype system which forces applications
to only use popular kernel paths.
Our prototype, Lind, pairs two components -- Google's Native Client
(NaCl) \cite{NaCl-09} and Seattle's Repy \cite{Repy-10}.
NaCl serves as a computational module that isolates
binaries, providing memory safety for legacy programs running in our OSVM.
It also passes system calls invoked by the program to the operating system interface, called SafePOSIX.
SafePOSIX re-creates the broader POSIX functionalities needed by applications, while being contained within the Repy sandbox.
An API in the sandbox only allows access to popular kernel paths, while
the small (8K LOC) sandbox kernel of Repy isolates flaws in SafePOSIX
to prevent them from allowing direct access to the host OS kernel.
To test the effectiveness of our ``popular paths'' metric,
we replicated 35 kernel bugs that had been
discovered in Linux kernel version 3.14.1. We attempted to trigger those
bugs in Lind and three other virtualized environments,
including Docker, LXC, and Graphene.
Our results show that applications in Lind were substantially less likely to trigger
kernel bugs.
By so doing we demonstrated that forcing an application to only use popular
OS kernel approach can be an effective and practical method to improve
system security.
In summary, the main contributions of this paper are as follows:
\begin{itemize}\setlength\itemsep{0em}
%\item
%We postulate a new approach for securing privileged code,
%such as the OS kernel, based on the idea that popular kernel paths contain
%fewer bugs. \cappos{I'm not sure how this differs from 3...}
\item
We propose a quantitative metric that evaluates security at the line-of-code level.
We discover that security bugs in the Linux kernel have strong correlation with popular paths.
We verified our hypothesis that popular paths have significantly fewer security bugs than other paths.
%Yiwen: cut
%Compared against other proposed metrics,
%such as the age of code~\cite{ozment2006milk}, or
%the increased risk in driver code~\cite{PittSFIeld}.
%We find that choosing popular kernel paths is a much more effective metric for identifying lines of code that are unlikely to contain security flaws.
\item
Based on the ``popular paths'' metric, we postulate a new approach for securing privileged code,
and develop a new design scheme called \lip. It
accesses only popular code paths
through a very small trusted computing base.
The need for complex functionality is addressed by re-creating riskier system calls
in a memory-safe programming language within a secure sandbox.
\item
To demonstrate the practicality of the ``popular paths'' metric, we built a prototype virtual machine, Lind, using the \lip design,
and test its effectiveness against three other virtual machines. We find that
Lind exposes 8-12x fewer zero-day kernel bugs.
\end{itemize}
% Yiwen: I'd like to cut this roadmap
%The remainder of this paper is organized as follows.
%Section \ref{sec.motivation-and-background} presents the scope of our study
%and precisely describes our threat model.
%Earlier kernel protection metrics and how they performed
%against our newly proposed metric are discussed in Section \ref{sec.metric}.
%We discuss handling bugs in the OSVM software in
%Section~\ref{sec.design}, while focusing on design strategies for preventing exploitation of zero-day kernel
%bugs in the host OS.
%Section \ref{sec.design} also describes our \lip design scheme.
%In Section \ref{sec.implementation} we discuss the construction of our Lind
%prototype, while Section \ref{sec.evaluation} provides a quantitative
%security analysis of Lind compared to other virtualization systems.
%Section \ref{sec.limitation} outlines limitations of our study.
%Finally, Section \ref{sec.related_work} reviews existing work relevant to Lind's security goals,
%while the cogent points relayed in the paper are reviewed in Section \ref{sec.conclusion}.