More content

work/01paper.tex

@@ -8,8 +8,6 @@
 \usepackage{graphicx}
 \usepackage{textcomp}
 \usepackage{xcolor}
-\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
-    T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
 
 %additional packages
 %\usepackage[ngerman]{babel}
@@ -30,12 +28,11 @@
 \input{glossary}
 %%fuer abkuerzungen end
 
-
 \begin{document}
 
-\title{Paper Title *TODO edit*}
+\title{Overview Over Attack Vectors and Countermeasures for Buffer Overflows}
 
-\author{\IEEEauthorblockN{1\textsuperscript{st} Given Valentin Brandl}
+\author{\IEEEauthorblockN{Valentin Brandl}
 \IEEEauthorblockA{\textit{Faculity of Computer Science and Mathematics} \\
 \textit{OTH Regensburg}\\
 Regensburg, Germany \\
@@ -81,6 +78,57 @@ vulnerabilities or at least application crashes.
 % languages with unsafe, manual memory management are still in use and power
 % critical parts of the worlds infrastructure.
 
+
+\section{Main Part, TODO}\label{ref:main} %TODO!!!!
+
+\subsection{Background}\label{ref:background}
+
+text
+
+\subsection{Concept and Methods}\label{ref:concept}
+
+\subsubsection{Runtime Bounds Checks}
+\subsubsection{Prevent Overriding Return Address}
+\subsubsection{Restricting Language Features to a Secure Subset}
+\subsubsection{Static Analysis}
+\subsubsection{Type System Solutions}
+\subsubsection{ASLR}
+
+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}
+
+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.
+
+
+\subsection{Discussion}\label{ref:discussion}
+
+\subsubsection{Ineffective or Inefficient}
+
+\subsubsection{State of the Art}
+
+text
+
+\section{Conclusion and Outlook}\label{ref:conclusion}
+
+text
+
 \section{Sources}
 
 \begin{itemize}
@@ -100,36 +148,6 @@ vulnerabilities or at least application crashes.
 \end{itemize}
 
 
-\section{Main Part, TODO}\label{ref:main} %TODO!!!!
-
-\subsection{Background}\label{ref:background}
-
-text
-
-\subsection{Concept and Methods}\label{ref:concept}
-
-\begin{itemize}
-    \item Runtime bounds checks
-
-    \item Prevent overriding return address
-
-    \item Restricting language features to a secure subset
-
-    \item Static analysis
-
-    \item Dependent types (only allow indexing with values that are proven to be
-      in bounds)
-
-\end{itemize}
-
-\subsection{Discussion}\label{ref:discussion}
-
-text
-
-\section{Concusion and Outlook}\label{ref:conclusion}
-
-text
-
 
 \bibliographystyle{IEEEtran}
 \bibliography{bibliography}