Content

work/01paper.tex

@@ -71,19 +71,23 @@ When the first programming languages were designed, memory had to be managed
 manually to make the best use of slow hardware. This opened the door for many
 kinds of programming errors. Memory can be deallocated more than once
 (double-free), the programm could read or write out of bounds of a buffer
-(information leaks, buffer overflows). Languages that are affected by this are
-e.g. C, C++ and Fortran. These languages are still used in critical parts of
-the worlds infrastructure, either because they allow to implement really
-performant programms, because they power legacy systems or for portability
-reasons. Scientists and software engineers have proposed lots of solutions to
-this problem over the years and this paper aims to compare and give an overview
-about those.
+(information leaks, \acp{bof}). Languages that are affected by this are e.g. C,
+C++ and Fortran. These languages are still used in critical parts of the worlds
+infrastructure, either because they allow to implement really performant
+programms, because they power legacy systems or for portability reasons.
+Scientists and software engineers have proposed lots of solutions to this
+problem over the years and this paper aims to compare and give an overview about
+those.
 
 Reading out of bounds can result in an information leak and is less critical
-than buffer overflows in most cases, but there are exceptions, e.g.\ the
-Heartbleed bug in OpenSSL which allowed dumping secret keys from memory. Out of
-bounds writes are almost always critical and result in code execution
-vulnerabilities or at least application crashes.
+than \acp{bof} in most cases, but there are exceptions, e.g.\ the Heartbleed bug
+in OpenSSL which allowed dumping secret keys from memory. Out of bounds writes
+are almost always critical and result in code execution vulnerabilities or at
+least application crashes.
+
+In 2018, 14\% (2368 out of 16556)~\cite{Cve2018} of all software vulnerabilities
+that have a CVE assigned, were overflow relates. This shows that, even if this
+type of bug is very old and well known, it's still relevant today.
 
 
 % \section{Main Part, TODO}\label{ref:main} %TODO!!!!
@@ -94,14 +98,26 @@ vulnerabilities or at least application crashes.
 
 \subsection{Technical Details}
 
-Exploitation of buffer overflow vulnerabilities almost always works by
-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.
+Exploitation of \ac{bof} vulnerabilities almost always works by 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.
+
+A simple vulnerable programm might look like this:
+
+\begin{minted}{c}
+int main(int argc, char **argv) {
+  char buf[50];
+  for (size_t i = 0; i < strlen(argv[1]); i++) {
+    buf[i] = argv[1][i];
+  }
+  return 0;
+}
+\end{minted}
 
 \subsection{Implications}
 
@@ -110,38 +126,39 @@ to an object's methods are stored.
 \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.
+problems introduced by \acp{bof}. The performance impact, effectiveness (e.g.\
+did the technique actually prevent exploitation of \acp{bof}?) 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.
+The easiest and maybe single most effective method to prevent \acp{bof} 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. Still almost any language
+that comes with a runtime, uses runtime checking.
 
 \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
-be quite effective without much overhead at runtime. \citeauthor{Rad2001}
-describe a technique that stores a redudnant copy of the return address in a
-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
+Since most traditional \ac{bof} exploits work by overriding the return address
+in the current stack frame, preventing or at least detecting this, can be quite
+effective without much overhead at runtime. \citeauthor{Rad2001} describe a
+technique that stores a redudnant copy of the return address in a 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 \mintinline{ASM}{RET}
+instruction is actually executed~\cite{Rad2001}. While this is effective against
 \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
-canary is checked, if it is still intact and if not, a buffer overflow occurred.
-This technique is used in major operating systems %TODO
-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.
+stack frame and the return address~\cite{Stackguard1998}. When returning, the
+canary is checked, if it is still intact and if not, a \ac{bof} occurred.  This
+technique is used in major operating systems %TODO
+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.
 
 \subsection{Restricting Language Features to a Secure Subset}
 \subsection{Static Analysis}
@@ -157,12 +174,12 @@ information can even be used as the base of a formal verification.
 
 \subsection{Address Space Layout Randomization}
 
-\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.
+\Ac{aslr} aims to prevent exploitatoin of \acp{bof} 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.
 
 \subsection{w\^{}x Memory}
 
@@ -216,8 +233,8 @@ What techniques are currently used?
 
 \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
+While there are many techniques, that protect against different types of
+\acp{bof}, none of them is effctive in every situation. Maybe we've come to a
 point where we have to stop using memory unsafe languages where it is not
 inevitable. There are many modern programming languages, that aim for the same
 problem space as C, C++ or Fortran but without the issues comming/stemming %TODO
@@ -227,24 +244,36 @@ go, without any language runtime and with deterministic memory management. For
 any other problem, almost any other memory safe language is better than using
 unsafe C.
 
-\section{Sources}
+\section{Sources (Dummy Section for Deadline)}
 
 \begin{itemize}
 
-  \item RAD:\ A Compile-Time Solution to Buffer Overflow Attacks\cite{Rad2001}
+  \item RAD:\ A Compile-Time Solution to Buffer Overflow Attacks~\cite{Rad2001}
     (might not protect against e.g.\ vtable overrides, \ac{plt} address changes,
     \dots)
 
-  \item Dependent types for low-level programming\cite{Dep2007}
+  \item Dependent types for low-level programming~\cite{Dep2007}
 
   \item StackGuard: Automatic Adaptive Detection and Prevention of
-    Buffer-Overflow Attachs\cite{Stackguard1998} (ineffective in combination
+    Buffer-Overflow Attachs~\cite{Stackguard1998} (ineffective in combination
     with information leaks)
 
-  \item Type-Assisted Dynamic Buffer Overflow Detection\cite{TypeAssisted2002}
+  \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}
+    Buffer Overflows~\cite{Effectiveness2014}
+
+  \item What Do We Know About Buffer Overflow Detection?: A Survey on Techniques
+    to Detect A Persistent Vulnerability~\cite{Detection2018}
+
+  \item Survey of Attacks and Defenses on Stack-based Buffer Overflow
+    Vulnerability~\cite{AtkDef2016}
+
+  \item Beyond stack smashing: recent advances in exploiting buffer
+    overruns~\cite{Smashing2004}
+
+  \item Runtime countermeasures for code injection attacks against C and C++
+    programs~\cite{Counter2012}
 
 \end{itemize}