motivation-and-background.tex

\section{Goals and Threat Model}
\label{sec.motivation-and-background}

Our goal in this work is to use our metric to guide better design
security systems, such as virtual machines. Specifically, we focus on 
situations where there is a \emph{host OS} that contains vulnerabilities
that an attacker could exploit. To combat this, code is executed in a 
\emph{security system}, such as a guest OS VM, system call interposition module, or library OS. 
The attacker is able to run an \emph{attack program} in this security system with the goal of exploiting an unpatched vulnerability in the host OS.

An attacker could potentially take two approaches. First, the attack program could exploit a flaw in the host OS by 
performing an action in the security system that triggers a flaw in
the host OS. Effectively, the attacker is taking advantage of the security 
system utilizing paths in the kernel which have vulnerabilities.
Second, the attack program could exploit a flaw in the security system to 
escape its containment. Once the attacker has exploited this flaw, the
attack program can make system calls in the host OS directly, which allows
the attacker to trigger a known exploit. We discuss both of these attack 
scenarios in this work.


Several solutions are out of scope of this
work. We do not compare with solutions that do not run on a full-fledged 
privileged operating system, such as virtualization that uses a 
hypervisor~\cite{Xen-03} or hardware-based virtualization 
solution~\cite{IntelVT} as they do not cover all kernel paths. 
%\yanyan{because they don't cover all kernel paths?} 
%We will need to do more measurement and analysis
%in future work to see if security flaws in these systems also fall along
%paths in the privileged functionality that are not commonly-used by popular
%programs.

To summarize, our threat model makes the following assumptions.

\begin{itemize}\setlength\itemsep{0em}
\item The attacker knows about one or more unpatched vulnerabilities in the 
host OS.

\item The attacker is permitted to execute code in the security
system.

\item If the attack program can trigger a vulnerability in any privileged code,
whether in the host OS or the security system, the attacker is successful in 
compromising the system.

\end{itemize}

%\subsection{Function and Design of the OS Kernel}
%
%\yiwen{This subsection title 2.1 seems not very accurate to me. 
%We are not talking about the ``function'' or ``design'' of an OS kernel, 
%but rather the potential risks that a kernel could be facing.}
%
%The kernel is responsible for
%managing input and output requests from servers and converting this information
%into system calls to execute operations. User applications depend directly on
%their ability to access critical resources, such as memory, I/O, or CPU, from the
%kernel, which provides interfaces to serve these requests, Unfortunately, these
%types of operations bring the kernel in contact, with complex and potentially
%malicious programs. OS kernels are vulnerable to adversarial attacks, which have
%increased in frequency over time.
%In 2014, 215 vulnerabilities in all types of kernels were reported~\cite{NVD},
%of which 125 were in the Linux kernel alone.\lois{These two statements are related,
% but they are not cause and effect. The \# of vulnerabilities does not directly correlate
% to the number of attacks. The vulnerabilities are in the code, right?}
%With the constant addition of new features~\cite{Metrics-13}, the kernel's
%attack surface keeps increasing For example, the Linux kernel grew from 6.6 MLOC
%in v2.6.11 (March 2005) to 16.9 MLOC in v3.10 (June 2013)~\cite{Linux-13}. A
%common assumption is that there is a connection between the size of the attack
%surface and a kernel's potential vulnerability, though this has not been proved
%conclusively.
%\lois{I found a paper that studies this relationship. It
%probably should be cited. I'll provide that information offline.I also think
%this paragraph needs at least one more sentence emphasizing the difficulty of
%protecting the kernel.}
%
%%\cappos{Likely cut this.  I think it is excessive.}
%
%%Such a huge kernel codebase has lead to excessive exploitation, where it has been plagued by a number of common software flaws.
%%These flaws have raised serious security concerns and caused severe damage to systems.
%%\lois{Are these sentences needed? Is this what Justin thought was excessive? If so, I agree.}
%%The common vulnerability and exposure (CVE) database reports indicate stack and heap buffer overflow vulnerabilities
%%have been used to launch denial of service attacks through crashing the systems  (CVE-2013-2892).
%~\cite{CVE-2013-2892}, Other vulnerabilities such as the execution of arbitrary code (CVE-2009-3234) %~\cite{CVE-2009-3234},
%%or to allow local users to gain privileges via a crafted application (CVE-2013-1828) are also among the reports.
%%~\cite{CVE-2013-1828}. Memory disclosure vulnerabilities (CVE-2009-3002) have been also exploited to
%%allow local users to read the contents of some kernel memory locations
%%~\cite{CVE-2009-3002} , or to obtain potentially sensitive information from kernel stack memory (CVE-2010-4073). %~\cite{CVE-2010-4073}.
%%Attackers have also used use-after-free vulnerability to gain kernel privileges, i.e. CVE-2013-4343.
%%~\cite{CVE-2013-4343}. \lois{If this is what Justin thought was excessive, I would still agree.
%%It is too much of a "laundry list" of random examples, with no specifics.}
%
%%The number of kernel vulnerabilities and their potential for exploitation,
%%plus the fact that user applications rely on the kernel to execute
%programs,
%%present a compelling motive for designing securer systems that can run
%applications with a better degree of safety. \yanyan{this paragraph does
%not say anything new.}

%\subsection{Threat Model}
%
%%The primary =secure system is to restrict a program to a subset of privileges.
%%Most systems mediate this access to
%%the underlying operating system through a set of functions.
%One of the great risks of a kernel exploitation is the access
%it grants a potential attacker to privileged code. In most systems, the kernel
%mediates access to the underlying system. Triggering kernel vulnerabilities
%could extend access privileges
%to attackers,thus sacrificing any intended protection~\cite{Repy-10}.

%\gholami{I doubt this is the goal of the system. I think system goals are CIA
%properties that can be assured through confinement for example?}.

%With what is known about the vulnerability of kernel code, we make the
%following assumptions about potential attacks:
%
%\begin{enumerate}
%\item  Bugs may exist in any complex code, including any security systems
%placed between the kernel and the user applications. These flaws can be triggered
%both intentionally by a malicious party, or unintentionally through contact with
%untrusted programs.
%
%\item An attacker also has the ability to execute code inside
%of a virtualization system, such as an operating system VM or library OS.
%
%\item Once vulnerabilities are triggered within kernel code, an attacker can gain the
%privileged access delegated to this part of kernel. This gives an attacker unrestricted
%access to the system.
%
%\end{enumerate}
%
%To respond to such a threat, it is feasible to build a functionality that
%possesses few vulnerabilities, as long as the codebase is kept to a minimum.
%
%%\cappos{How do I explainthe sandbox TCB???  How is this different from a hypervisor?}