New version

work/01paper.tex

@@ -13,6 +13,13 @@
 \usepackage{textcomp}
 \usepackage{xcolor}
 
+% code listings
+\usepackage{minted}
+\usepackage{relsize}
+% acronyms
+\usepackage{acro}
+\acsetup{list-long-format=\capitalisewords}
+
 %additional packages
 %\usepackage[ngerman]{babel}
 \usepackage[utf8]{inputenc}
@@ -32,6 +39,8 @@
 \input{glossary}
 %%fuer abkuerzungen end
 
+\include{acronyms}
+
 \begin{document}
 
 \title{Overview Over Attack Vectors and Countermeasures for Buffer Overflows}
@@ -77,35 +86,44 @@ bounds writes are almost always critical and result in code execution
 vulnerabilities or at least application crashes.
 
 
-\section{Main Part, TODO}\label{ref:main} %TODO!!!!
+% \section{Main Part, TODO}\label{ref:main} %TODO!!!!
 
-\subsection{Background}\label{ref:background}
+\section{Background}\label{ref:background}
 
 % TODO: many references
 
-\subsubsection{Technical Details}
+\subsection{Technical Details}
 
 Exploitation of buffer overflow vulnerabilities almost always works by
-overriding the return address in the current stack frame, so when the `ret`
-instruction is executed, an attacker controlled address is moved into the
-instruction pointer register and the code pointed to by this address is
-executed. Other ways include overriding addresses in the PLT of a binary so
-that, if a linked function is called, an attacker controlled function is called
-instead, or (in C++) overriding the vtable where the pointers to an object's
-methods are stored.
+overriding the return address in the current stack frame, so when the
+\mintinline{ASM}{RET} instruction is executed, an attacker controlled address is
+moved into the instruction pointer register and the code pointed to by this
+address is executed. Other ways include overriding addresses in the \ac{plt} of
+a binary so that, if a linked function is called, an attacker controlled
+function is called instead, or (in C++) overriding the vtable where the pointers
+to an object's methods are stored.
 
-\subsubsection{Implications}
+\subsection{Implications}
 
-\subsection{Concept and Methods}\label{ref:concept}
+\section{Concept and Methods}\label{ref:concept}
 
-\subsubsection{Runtime Bounds Checks}
+\subsection{Methods}
+
+This paper will describe several techniques that have been proposed to fix the
+problems introduced by buffer overflows. The performance impact, effectiveness
+(e.g.\ did the technique actually prevent exploitation of buffer overflows?) and
+how realistic it is for the technique to be used in real-world code (e.g.\ can
+it be introduced into an existing codebase incrementally?). In the end, the
+current state will be discussed.
+
+\subsection{Runtime Bounds Checks}
 
 The easiest and maybe single most effective method to prevent buffer overflows
 is to check, if a write or read operation is out of bounds. This requires
 storing the size of a buffer together with the pointer to the buffer and check
 for each read or write in the buffer, if it is in bounds at runtime.
 
-\subsubsection{Prevent/Detect Overriding Return Address}
+\subsection{Prevent/Detect Overriding Return Address}
 
 Since most traditional buffer overflow exploits work by overriding the return
 address in the current stack frame, preventing or at least detecting this, can
@@ -115,8 +133,7 @@ secure memory area that is guarded by read-only memory, so it cannot be
 overwritten by overflows. When returning, the copy of the return address is
 compared to the one in the current stack frame and only, if it matches, the ret
 instruction is actually executed\cite{Rad2001}. While this is effective against
-return oriented programming based exploits, it does not protect against vtable
-overrides.
+\ac{rop} based exploits, it does not protect against vtable overrides.
 
 An older technique from 1998 proposes to put a canary word between the data of a
 stack frame and the return address\cite{Stackguard1998}. When returning, the
@@ -126,53 +143,78 @@ but can be defeted, if there is an information leak that leaks the cannary to
 the attacker. The attacker is then able to construct a payload, that keeps the
 canary intact.
 
-\subsubsection{Restricting Language Features to a Secure Subset}
-\subsubsection{Static Analysis}
-\subsubsection{Type System Solutions}
+\subsection{Restricting Language Features to a Secure Subset}
+\subsection{Static Analysis}
+\subsection{Type System Solutions}
 
 \citeauthor{Dep2007} propose an extension to the C type system that extends it
-with dependent types. These types have an associated value, e.g. a pointer type
+with dependent types. These types have an associated value, e.g.\ a pointer type
 can have the buffer size associated to it. This prevents indexing into a buffer
-with out of bounds values.
+with out-of-bounds values. This extension is a superset of C so any valid C code
+can be compiled using the extension and the codebase can be improved
+incrementally. If the type extension is advanced enough, the additional
+information can even be used as the base of a formal verification.
 
-\subsubsection{ASLR}
+\subsection{Address Space Layout Randomization}
 
-ASLR aims to prevent exploitatoin of buffer overflows by placing code at random
-locations in memory. That way, it is not trivial to set the return address to
-point to the payload in memory. This is effective against generic exploits but
-can still be exploited in combination with information leaks or other techniques
-like heap spraying. Also on 32 bit systems, the address space is small enough to
-try a brute-force attempt until the payload in memory is hit.
+\Ac{aslr} aims to prevent exploitatoin of buffer overflows by placing code at
+random locations in memory. That way, it is not trivial to set the return
+address to point to the payload in memory. This is effective against generic
+exploits but can still be exploited in combination with information leaks or
+other techniques like heap spraying. Also on 32 bit systems, the address space
+is small enough to try a brute-force attempt until the payload in memory is hit.
 
-\subsubsection{w\^{}x Memory}
+\subsection{w\^{}x Memory}
 
-This mitigation makes memory either writable or executable. That way, an
-attacker cannot place arbitiary payloads in memory. There are still techniques
-to exploit this by reusing existing executable code. The ret-to-libc exploiting
-technique uses existing calls to the libc with attacker controlled parameters,
-e.g.\ if the programm uses the "system" command, the attacker can plant
-"/bin/sh" as parameter on the stack, followed by the address of "system" and get
-a shell on the system. Return oriented programming (a superset of ret-to-libc
-exploits) uses so called ROP gadgets, combinations of memory modifying
-instructions followed by the ret instruction to build instruction chains, that
-execute the desired shellcode. This is done by placing the desired return
-addresses in the right order on the stack and reuses the existing code to
-circumvent the w\^{}x protection.
+w\^{}x (also known as \ac{nx}) makes memory either writable or executable. That
+way, an attacker cannot place arbitiary payloads in memory.  There are still
+techniques to exploit this by reusing existing executable code.  The ret-to-libc
+exploiting technique uses existing calls to the libc with attacker controlled
+parameters, e.g.\ if the programm uses the \mintinline{shell}{system} command,
+the attacker can plant \mintinline{shell}{/bin/sh} as parameter on the stack,
+followed by the address of \mintinline{shell}{system} and get a shell on the
+system. \ac{rop} (a superset of ret-to-libc exploits) uses so called ROP
+gadgets, combinations of memory modifying instructions followed by the ret
+instruction to build instruction chains, that execute the desired shellcode.
+This is done by placing the desired return addresses in the right order on the
+stack and reuses the existing code to circumvent the w\^{}x protection.
 
 
-\subsection{Discussion}\label{ref:discussion}
+\section{Discussion}\label{ref:discussion}
 
-\subsubsection{Ineffective or Inefficient}
+\subsection{Ineffective or Inefficient}
 
-Methods that have been shown to be ineffective (e.g. can be circumvented easily)
-or inefficient (to much runtime overhead)...
+\subsubsection{\ac{aslr}}
 
-\subsubsection{State of the Art}
+\Ac{aslr} has been really effective and is included in all major operating
+systems. Some even use kernel \ac{aslr}. Since this mechanism is active at %TODO
+runtime, it does not require any changes in the code itself, the programm only
+has to be compiled as a \ac{pie}.
+
+\subsubsection{w\^{}x}
+
+With the rise of \ac{rop} techniques, w\^{}x protection has been shown to be
+ineffective. It makes vulnerabilities harder to exploit but does not prevent
+anything.
+
+\subsubsection{Runtime Bounds Checks}
+
+Checking for overflows at runtime is very effective but can have a huge
+performance impact so it is not feasible in every case. It also comes with other
+footguns. There might be integer overflows when calculating the bounts which
+might introduce other problems.
+
+Methods that have been shown to be ineffective (e.g.\ can be circumvented
+easily) or inefficient (to much runtime overhead)\ldots
+
+\subsection{State of the Art}
 
 What techniques are currently used?
 
+\subsection{Outlook}
 
-\section{Conclusion and Outlook}\label{ref:conclusion}
+
+\section{Conclusion}\label{ref:conclusion}
 
 While there are many techniques, that protect against different types of buffer
 overflows, none of them is effctive in every situation. Maybe we've come to a
@@ -190,7 +232,7 @@ unsafe C.
 \begin{itemize}
 
   \item RAD:\ A Compile-Time Solution to Buffer Overflow Attacks\cite{Rad2001}
-    (might not protect against e.g.\ vtable overrides, PLT address changes,
+    (might not protect against e.g.\ vtable overrides, \ac{plt} address changes,
     \dots)
 
   \item Dependent types for low-level programming\cite{Dep2007}
@@ -201,12 +243,16 @@ unsafe C.
 
   \item Type-Assisted Dynamic Buffer Overflow Detection\cite{TypeAssisted2002}
 
+  \item On the Effectiveness of NX, SSP, RenewSSP, and \ac{aslr} against Stack
+    Buffer Overflows\cite{Effectiveness2014}
+
 \end{itemize}
 
 
-\printbibliography
+\printbibliography{}
 % \bibliographystyle{IEEEtran}
 % \bibliography{bibliography}
+\printacronyms{}
 
 \end{document}
 % vim: set filetype=tex ts=2 sw=2 tw=80 et spell :