\documentclass[conference]{IEEEtran}
\IEEEoverridecommandlockouts{}
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
\usepackage{csquotes}
\usepackage[style=ieee,backend=biber]{biblatex}

\addbibresource{./bibliography.bib}

\usepackage{amsmath,amssymb,amsfonts}
\usepackage{algorithmic}
\usepackage{booktabs}
\usepackage{graphicx}
\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}
\usepackage{hyperref}
\usepackage{url}
%%fuer abkuerzungen begin
\usepackage[acronym,hyperfirst = false]{glossaries}
\glsdisablehyper{}
%\usepackage[acronym,acronymlists={main, abbreviationlist},shortcuts,toc,description,footnote]{glossaries}
\newglossary[clg]{abbreviationlist}{cyi}{cyg}{List of Abbreviations}
\newglossary[slg]{symbolslist}{syi}{syg}{Symbols}
\renewcommand{\firstacronymfont}[1]{\emph{#1}}
\renewcommand*{\glspostdescription}{}	% Punkt am Ende jeder Beschreibung entfernen
\renewcommand*{\acrnameformat}[2]{#2 (\acronymfont{#1})}	% Langform der Akronyme
\makeglossaries{}
\date{\today}
\input{glossary}
%%fuer abkuerzungen end

\include{acronyms}

\begin{document}

\title{Overview Over Attack Vectors and Countermeasures for Buffer Overflows}

\author{\IEEEauthorblockN{Valentin Brandl}
\IEEEauthorblockA{\textit{Faculity of Computer Science and Mathematics} \\
\textit{OTH Regensburg}\\
Regensburg, Germany \\
valentin.brandl@st.oth-regensburg.de\\
MatrNr. 3220018}
}

\maketitle

\begin{abstract}
TODO
\end{abstract}

\begin{IEEEkeywords}
Buffer Overflow, Software Security
\end{IEEEkeywords}



\section{Motivation}\label{ref:motivation}

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.

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.


% \section{Main Part, TODO}\label{ref:main} %TODO!!!!

\section{Background}\label{ref:background}

% TODO: many references

\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.

\subsection{Implications}

\section{Concept and Methods}\label{ref:concept}

\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.

\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
\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.

\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
can have the buffer size associated to it. This prevents indexing into a buffer
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.

\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.

\subsection{w\^{}x Memory}

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.


\section{Discussion}\label{ref:discussion}

\subsection{Ineffective or Inefficient}

\subsubsection{\ac{aslr}}

\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}\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
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
from these languages. If it is feasible to use a garbage collector, Go might
work just fine. If real-time properties are required, Rust could be the way to
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}

\begin{itemize}

  \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 StackGuard: Automatic Adaptive Detection and Prevention of
    Buffer-Overflow Attachs\cite{Stackguard1998} (ineffective in combination
    with information leaks)

  \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{}
% \bibliographystyle{IEEEtran}
% \bibliography{bibliography}
\printacronyms{}

\end{document}
% vim: set filetype=tex ts=2 sw=2 tw=80 et spell :
