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
+(information leaks, \acp{bof}). Languages that are affected by this are e.g. C,
-e.g. C, C++ and Fortran. These languages are still used in critical parts of
+C++ and Fortran. These languages are still used in critical parts of the worlds
-the worlds infrastructure, either because they allow to implement really
+infrastructure, either because they allow to implement really performant
-performant programms, because they power legacy systems or for portability
+programms, because they power legacy systems or for portability reasons.
-reasons. Scientists and software engineers have proposed lots of solutions to
+Scientists and software engineers have proposed lots of solutions to this
-this problem over the years and this paper aims to compare and give an overview
+problem over the years and this paper aims to compare and give an overview about
-about those.
+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
+than \acp{bof} in most cases, but there are exceptions, e.g.\ the Heartbleed bug
-Heartbleed bug in OpenSSL which allowed dumping secret keys from memory. Out of
+in OpenSSL which allowed dumping secret keys from memory. Out of bounds writes
-bounds writes are almost always critical and result in code execution
+are almost always critical and result in code execution vulnerabilities or at
-vulnerabilities or at least application crashes.
+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
+Exploitation of \ac{bof} vulnerabilities almost always works by overriding the
-overriding the return address in the current stack frame, so when the
+return address in the current stack frame, so when the \mintinline{ASM}{RET}
-\mintinline{ASM}{RET} instruction is executed, an attacker controlled address is
+instruction is executed, an attacker controlled address is moved into the
-moved into the instruction pointer register and the code pointed to by this
+instruction pointer register and the code pointed to by this address is
-address is executed. Other ways include overriding addresses in the \ac{plt} of
+executed. Other ways include overriding addresses in the \ac{plt} of a binary so
-a binary so that, if a linked function is called, an attacker controlled
+that, if a linked function is called, an attacker controlled function is called
-function is called instead, or (in C++) overriding the vtable where the pointers
+instead, or (in C++) overriding the vtable where the pointers to an object's
-to an object's methods are stored.
+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
+problems introduced by \acp{bof}. The performance impact, effectiveness (e.g.\
-(e.g.\ did the technique actually prevent exploitation of buffer overflows?) and
+did the technique actually prevent exploitation of \acp{bof}?) and how realistic
-how realistic it is for the technique to be used in real-world code (e.g.\ can
+it is for the technique to be used in real-world code (e.g.\ can it be
-it be introduced into an existing codebase incrementally?). In the end, the
+introduced into an existing codebase incrementally?). In the end, the current
-current state will be discussed.
+state will be discussed.
 
 \subsection{Runtime Bounds Checks}
 
-The easiest and maybe single most effective method to prevent buffer overflows
+The easiest and maybe single most effective method to prevent \acp{bof} is to
-is to check, if a write or read operation is out of bounds. This requires
+check, if a write or read operation is out of bounds. This requires storing the
-storing the size of a buffer together with the pointer to the buffer and check
+size of a buffer together with the pointer to the buffer and check for each read
-for each read or write in the buffer, if it is in bounds at runtime.
+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
+Since most traditional \ac{bof} exploits work by overriding the return address
-address in the current stack frame, preventing or at least detecting this, can
+in the current stack frame, preventing or at least detecting this, can be quite
-be quite effective without much overhead at runtime. \citeauthor{Rad2001}
+effective without much overhead at runtime. \citeauthor{Rad2001} describe a
-describe a technique that stores a redudnant copy of the return address in a
+technique that stores a redudnant copy of the return address in a secure memory
-secure memory area that is guarded by read-only memory, so it cannot be
+area that is guarded by read-only memory, so it cannot be overwritten by
-overwritten by overflows. When returning, the copy of the return address is
+overflows. When returning, the copy of the return address is compared to the one
-compared to the one in the current stack frame and only, if it matches, the ret
+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
+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
+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.
+canary is checked, if it is still intact and if not, a \ac{bof} occurred.  This
-This technique is used in major operating systems %TODO
+technique is used in major operating systems %TODO
-but can be defeted, if there is an information leak that leaks the cannary to
+but can be defeted, if there
-the attacker. The attacker is then able to construct a payload, that keeps the
+is an information leak that leaks the cannary to the attacker. The attacker is
-canary intact.
+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
+\Ac{aslr} aims to prevent exploitatoin of \acp{bof} by placing code at random
-random locations in memory. That way, it is not trivial to set the return
+locations in memory. That way, it is not trivial to set the return address to
-address to point to the payload in memory. This is effective against generic
+point to the payload in memory. This is effective against generic exploits but
-exploits but can still be exploited in combination with information leaks or
+can still be exploited in combination with information leaks or other techniques
-other techniques like heap spraying. Also on 32 bit systems, the address space
+like heap spraying. Also on 32 bit systems, the address space is small enough to
-is small enough to try a brute-force attempt until the payload in memory is hit.
+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
+While there are many techniques, that protect against different types of
-overflows, none of them is effctive in every situation. Maybe we've come to a
+\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}