proposal draft 1
This commit is contained in:
parent
172da4ca29
commit
d080a2352d
10 changed files with 249 additions and 307 deletions
|
|
@ -60,178 +60,38 @@ Vrije Universiteit Amsterdam
|
|||
\newpage
|
||||
|
||||
\section*{Abstract}
|
||||
|
||||
Explain here the context, problem, prior work, your own approach, and expected impact if the project is successful. The word count is a maximum of 250.
|
||||
|
||||
Note:
|
||||
\begin{enumerate}
|
||||
\item This can be seen as a short summary of the combined Introduction and Conclusion sections.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
We will reproduce parts of Maar et al. \cite{tugraz:tlbsidechannel} and use them to perform a location disclosure attack on security critical kernel data structures. This will allow for further attacks which would usually be prevented by ASLR. To do so we will use kernel defenses that change the page mappings to 4kB and exploit a TLB side channel along with allocator massaging to leak the page-aligned address of critical data structures. We then further deduce precise addresses as well as performing error checking to improve success rate. \\
|
||||
|
||||
\section{Introduction} \label{sec:introduction}
|
||||
|
||||
Explain the research project. Also include here the personal value you hope to derive from this project.
|
||||
|
||||
Explain at least:
|
||||
\begin{enumerate}
|
||||
\item The context of this research project. How broad do you see the impact of a good result? (Will you change the world? The science of Europe? The industry of the Netherlands?)
|
||||
|
||||
\item The key terms addressed in this research project. You will expand on this element in Section~\ref{sec:background}.
|
||||
|
||||
\item The main problem addressed in this research project. You will expand on this element in Section~\ref{sec:problem}.
|
||||
|
||||
\item The key prior work related to this research project. You will expand on this element in Section~\ref{sec:related}.
|
||||
|
||||
\item The main research question, possibly paraphrased. You will expand on this element in Section~\ref{sec:researchq}. (If possible, also indicate the core of the approach, or an insight that can lead to it. You will expand on this element in Section~\ref{sec:approach}.)
|
||||
|
||||
\item The expected contribution of this research, for the scientific community and/or for your employer. You will expand on this element in Sections~\ref{sec:researchq}, \ref{sec:approach}, and~\ref{sec:plan}.
|
||||
|
||||
\item Expected contribution of this research, for yourself. How will this project develop you? How will it develop your career?
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
For example, consider the project leading to publication~\cite{DBLP:conf/sc/AndreadisVMI18}:
|
||||
\begin{enumerate}
|
||||
\item Context: datacenters, the backbone of cloud computing and our digital economy.
|
||||
\item Key terms: datacenters, scheduling, reference architecture.
|
||||
\item Problem: understanding and improving the process of scheduling in datacenters.
|
||||
\item Key prior work: research on scheduling in large-scale systems, scheduling practices in Big Tech companies (Google, Microsoft, Alibaba, etc.)
|
||||
\item Main research question: How to design a good abstraction for datacenter scheduling? Key insight: a unified reference architecture is a good abstraction for the scheduling process.
|
||||
\item Expected contribution, community: a survey, a reference architecture, an analysis of existing systems as mapped to the new reference architecture, a simulator implementing the reference architecture as the scientific instrument, experiments in simulation, description of a process for others to use the reference architecture, analysis of threats to validity.
|
||||
Plus: a technical report accompanying the publication\footnote{The technical report is published as open science: \url{https://arxiv.org/pdf/1808.04224.pdf}}, various public talks, etc. (The team also went for and obtained the ACM reproducibility badge, which among others requires publishing FOS software and FAIR data.)
|
||||
\item Expected contribution, personal: development into an independent researcher.
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
The goal of the project is to expose the location of security critical data structures such as the \texttt{cred} struct which would usually be prevented through (Kernel) ASLR. To do so we will use one of the technique presented in prior work by Maar et al. \cite{tugraz:tlbsidechannel} using TLB contention patterns caused by certain kernel defenses in combination with allocator massaging and in the process reproduce a subset of their findings. We will demonstrate the attack on an 8th Gen or newer Intel CPU and a 6.8 kernel. Depending on other factors, more systems may be evalutated. \\
|
||||
|
||||
\section{Background} \label{sec:background}
|
||||
Under usual circumstances kernel objects are memory mapped to 2MB pages, however Maar et al. \cite{tugraz:tlbsidechannel} identify 3 kernel defenses which change the memory mapping (partially) to 4kB. With this an attacker can ensure the target object is located in one of those 4kB mappings and loaded into the TLB. Then using access primitives creates a TLB contention pattern, based on which the page-aligned address of the target can be inferred and further the exact address of the target can be deduced.\\
|
||||
|
||||
Explain the key concepts needed to understand this work.
|
||||
See also Section~II of ~\cite{DBLP:conf/sc/AndreadisVMI18}.
|
||||
|
||||
The 3 kernel defenses are \texttt{CONFIG\_STRICT\_MODULE\_RWX}, \texttt{CONFIG\_SLAB\_VIRTUAL} and \\ \texttt{CONFIG\_VMAP\_STACK}. As the name suggests the last one only changes the mapping of the stack to 4kB and therefore only allows leakage of the kernel stack which is not interesting to us. \texttt{CONFIG\_STRICT\_MODULE\_RWX} is more interesting, however Maar et al. \cite{tugraz:tlbsidechannel} were unable to reliably leak the \texttt{cred} struct specifically using this exploit. This leaves \texttt{CONFIG\_SLAB\_VIRTUAL} which is a kernel defense introduced in the patched kernel for the Google KernelCTF. Other than \texttt{CONFIG\_STRICT\_MODULE\_RWX} this changes the entire heap mapping to 4kB instead of just the area around a loaded module. This potentially increases TLB noise but achieving a near 100\% success rate should still be possible with use of error correction. \\
|
||||
|
||||
\section{Problem} \label{sec:problem}
|
||||
|
||||
Explain in this section the main problem addressed in this work. The goal is to emphasize the value of a research project that addresses the problem. See also Sections~I and~III.A of~\cite{DBLP:conf/sc/AndreadisVMI18}.
|
||||
|
||||
Notes:
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Define the scope of the problem.
|
||||
|
||||
\item
|
||||
Refer back to the background~(see Section~\ref{sec:background}) for key terms.
|
||||
\end{enumerate}
|
||||
KASLR as a defense obfuscates the location of security critical objects which could be used in many exploits if exposed. If we are able to find a stable exploit to expose the location of these objections and therefore partially break KASLR many attacks previously prevented by it become possible again. In this use case, specifically data-only attacks greatly benefit from the potential data leaked here. \\
|
||||
|
||||
\section{Related Work} \label{sec:related}
|
||||
|
||||
Explain in this section related work on the problem explained in Section~\ref{sec:problem}. The goal is to emphasize the extent and the key elements of related work.
|
||||
See also Sections~I and~VII of~\cite{DBLP:conf/sc/AndreadisVMI18}.
|
||||
|
||||
Notes:
|
||||
\begin{enumerate}
|
||||
\item
|
||||
At this stage of your research career, this part will include a brief survey of the state-of-the-art, guided by the project supervisor.
|
||||
|
||||
\item
|
||||
Review and summarize the related work. What is known already? What should be known but isn't?
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
Maar et al. \cite{tugraz:tlbsidechannel} is clearly related as my work will be largely reproducing a subset of this work and provide everything required to use it for further data-only attacks. \\
|
||||
Further Gruss et al. \cite{tugraz:prefetch} may be relevant as it is used to distinguish mapped pages without violating access permissions. \\
|
||||
|
||||
\section{Research Question(s)} \label{sec:researchq}
|
||||
|
||||
Explain in this section the core research of the project. The goal is to show that the research is sufficiently balanced and broad. See also Sections~I and the short formulations (e.g., ``we investigate...'') in the following sections of~\cite{DBLP:conf/sc/AndreadisVMI18}. \\ \\
|
||||
|
||||
Notes:
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Formulate the main research question.
|
||||
|
||||
\item
|
||||
Define the scope of the project. Typically, the scope of the project is much smaller than the scope of the problem (defined in Section~\ref{sec:problem}).
|
||||
|
||||
\item
|
||||
Define detailed research questions. For each, explain at least: \textit{Why?}, \textit{Why important?}, and \textit{Why challenging?}
|
||||
|
||||
\end{enumerate}
|
||||
We invastigate the location disclosure attacks presented in Maar et al \cite{tugraz:tlbsidechannel} and investigate if we can provide a simple, usable disclosure attack to leak the location of security critical data structures which can be chained with further attacks. \\
|
||||
|
||||
\section{Approach} \label{sec:approach}
|
||||
In the first step we will analyze the most feasible way to leak the information of interest. Then we will attempt to perform such a disclosure attack on interesting data structures in a way which can be used in combination with follow-up attacks. If possible a last step may involve testing the attack on later kernels or different hardware. \\
|
||||
|
||||
Explain in this section how you anticipate you can answer the question(s) formulated in Section~\ref{sec:researchq}. The goal is to show that the research is feasible. For this reason, this section is mainly methodological; the pragmatic plans on how to complete all this work follow, in Section~\ref{sec:plan}. See, for example, Sections~I (overview) and~V.A (experiment design) of~\cite{DBLP:conf/sc/AndreadisVMI18}.
|
||||
|
||||
Notes:
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Describe the approach, for each research question. Emphasis on method(s) -- What? Expected contribution.
|
||||
|
||||
\item
|
||||
Introduce intuition about the key innovation and/or conceptual contribution.
|
||||
|
||||
\item
|
||||
Try to explain why the approach would work. Explain the expected technical contribution.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\section{Plan} \label{sec:plan}
|
||||
|
||||
Explain in this section how you expect to complete the parts defined in Section~\ref{sec:approach}. The goal is to show the work is feasible in the allocated time.
|
||||
\
|
||||
Notes:
|
||||
\begin{enumerate}
|
||||
\item
|
||||
Understand this is a preliminary plan.
|
||||
|
||||
\item
|
||||
Try to define at least the large components of the project. To do this, discuss with the project supervisor and/or consult a good article published recently in the field. For the running example, consult~\cite{DBLP:conf/sc/AndreadisVMI18}.
|
||||
|
||||
\item
|
||||
Try to plan tasks with a granularity of at most one week, and ideally with a granularity of a day. Try to make the near-future tasks SMART. Plan tasks long into the future of the project as \textit{slack}.
|
||||
|
||||
\item
|
||||
Try to attach milestones and key deliverables to the most important tasks. Make sure deliverables include the final report (or article) and at least one presentation (hopefully, in a major scientific venue).
|
||||
|
||||
\item
|
||||
Revisit the plans as soon as you complete a task, but especially after the first few tasks of a kind, e.g., a literature review task (you read a new article), a design iteration (you made or improved a design), an implementation task (you coded a new feature), an experiment task (you conducted one experiment).
|
||||
|
||||
\end{enumerate}
|
||||
\newpage
|
||||
For the running example, the research plan included:
|
||||
\begin{verbatim}
|
||||
```
|
||||
I plan to take the first two research questions in one step, since
|
||||
they are closely related:
|
||||
|
||||
To build a representative abstraction, I need to survey the
|
||||
existing approaches in the field. This way, the validation step
|
||||
is combined with the design step. This combined stage I
|
||||
intend to work on in the coming three months, and
|
||||
have a first report on my results ready by late January 2017.
|
||||
|
||||
After this stage is completed, I will begin integrating it in the
|
||||
OpenDC project [n.b., the simulator].
|
||||
Because I can imagine that this step will take a
|
||||
substantial amount of time, I plan to have produced a first,
|
||||
full prototype of this integration by May 2017.
|
||||
|
||||
I will try to keep the paper writing process parallel to
|
||||
these two stages as much as possible. However, knowing that
|
||||
this is difficult, I am allocating the time from June to
|
||||
July of 2017 to tie together the pieces and get
|
||||
this paper ready for publication.
|
||||
```
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
|
||||
The first step is mostly theoretical, however it may be necessary to reexamine the decisions made if further challenges arise in later steps. \\
|
||||
The next step will be performed on provided hardware, preferrably using VMs but if this proves impossible also on bare metal following the steps learned in the setups of the VM. \\
|
||||
|
||||
\section{Conclusion} \label{sec:conclusion}
|
||||
We will use a kernel defense to force 4kB page mapping for security critical data structures. Then we will use kernel allocator massaging and a TLB side channel to leak their location despite KASLR being enabled. We will further use error correction to attempt to provide a stable exploit which can be used for further exploits. \\
|
||||
|
||||
Revisit the context, problem statement, related work, and research design. See, for example, Section~VIII of~\cite{DBLP:conf/sc/AndreadisVMI18}.
|
||||
|
||||
|
||||
\newpage
|
||||
% For more on bibliography styles, see
|
||||
% https://www.overleaf.com/learn/latex/Bibtex_bibliography_styles
|
||||
\bibliographystyle{abbrv}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue