\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, \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 \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 related. 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!!!!

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

% TODO: many references

\subsection{Technical Details}

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}

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

\subsection{Methods}

This paper describes several techniques that have been proposed to fix the
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 developers to use the technique in real-world code (e.g.\ is
incremental introduction into an existing codebase possible). In the end, there
is a discussion about the current state.

\subsection{Runtime Bounds Checks}

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 \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 \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}
\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 is improved incrementally.
If the type extension is advanced enough, the additional information might form
the base for a formal verification.

\subsection{Address Space Layout Randomization}

\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
it is still posible to exploit \ac{bof} vulnerabilities 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
\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
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 (Dummy Section for Deadline)}

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

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


\printbibliography{}
% \bibliographystyle{IEEEtran}
% \bibliography{bibliography}
% \printacronyms{}

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