Small fixes

* Resolve ToDos
* Fix layout issues
* Fix typos and rephrase some sentences

Author: florianhofhammer

Report.tex

@@ -22,7 +22,6 @@
 \include{chapters/03-current-defense-mechanisms}
 \include{chapters/04-attack-vectors}
 \include{chapters/05-improvements}
-%\include{chapters/structure}
 \include{chapters/06-further-reading}
 \include{chapters/07-conclusion}
 

abstract.tex

@@ -9,19 +9,22 @@
 \begin{abstractpage}
   \begin{abstract}{american}
     The goal of the presented paper is to summarize different stack buffer overflow attack and defense methods in a single paper.
-    During this process, the question arises how some defense methods can be bypassed by an attacker and how a defender can improve on the defense mechanisms to thwart stack buffer overflow based attacks.
+    In this context, the question arises how some defense methods can be bypassed by an attacker and how a defender can improve on the defense mechanisms to thwart stack buffer overflow based attacks.
 
     To achieve these goals and answer these questions, several attack methods and their implications on the security of currently deployed defense mechanisms are presented.
     They show that even on modern systems, stack buffer overflow vulnerabilities can be exploited to execute arbitrary code controlled by an attacker under specific circumstances.
     Although stack buffer overflows are hard or impossible to exploit depending on the circumstances of the vulnerability and the system configuration, the need for security measure enhancements arises.
     Such improvements and expansions on current defense mechanisms against stack buffer overflows are also presented and compared with regard to their performance implications on a system.
-
-    As a result, it can be seen that stack buffer overflow exploits have gotten harder over the last years but that there are still possibilities to exploit such vulnerabilities.
-    This paper shows that there are several possibilities to counter said attacks and that there is thus still a lot of space for improvement.
   \end{abstract}
   \vspace{2em}
   \begin{abstract}{french}
-    Résumé français
+    L'objectif de l'article présenté est de résumer en un seul document les différentes méthodes d'attaque et de défense contre les débordements de pile.
+    Dans ce contexte, la question se pose de savoir comment certaines méthodes de défense peuvent être contournées par un attaquant et comment un défenseur peut améliorer les mécanismes de défense pour contrecarrer les attaques basées sur le débordement de pile.
+
+    Pour atteindre ces objectifs et répondre à ces questions, plusieurs méthodes d'attaque et leurs implications sur la sécurité des mécanismes de défense actuellement déployés sont présentées.
+    Elles montrent que même sur les systèmes modernes, les vulnérabilités liées au débordement de pile peuvent être exploitées pour exécuter du code arbitraire contrôlé par un attaquant dans des circonstances spécifiques.
+    Bien que les débordements de pile soient difficiles ou impossibles à exploiter selon les circonstances de la vulnérabilité et la configuration du système, il est nécessaire d'améliorer les mesures de sécurité.
+    Ces améliorations et extensions des mécanismes de défense actuels contre les débordements de pile sont également présentées et comparées en ce qui concerne leurs implications sur les performances d'un système.
   \end{abstract}
 \end{abstractpage}
 

appendix.tex

@@ -3,6 +3,78 @@
 \chapter{Supporting code}
 \label{chp:app:supporting-code}
 
+\begin{lstlisting}[language=bash,float=ht,caption={Disassembly excerpt of the 64 bit binary compiled from the code in \cref{lst:local-global-buffer} with \texttt{gcc -o local-global-buffer -O1 local-global-\linebreak[0]buffer.c}, retrieved with \texttt{objdump -D -{}-no-show-raw-insn local-\linebreak[0]global-buffer}}, label={lst:local-global-buffer-disassembly-non-fortified}]
+0000000000001169 <main>:
+1169:       push   %rbx
+116a:       sub    $0x30,%rsp
+116e:       mov    %fs:0x28,%rax
+1177:       mov    %rax,0x28(%rsp)
+117c:       xor    %eax,%eax
+117e:       lea    0xe83(%rip),%rdi
+1185:       callq  1030 <puts@plt>
+118a:       mov    $0x100,%edx
+118f:       lea    0x2eea(%rip),%rsi
+1196:       mov    $0x0,%edi
+119b:       callq  1060 <read@plt>
+11a0:       lea    0xe89(%rip),%rdi
+11a7:       callq  1030 <puts@plt>
+11ac:       mov    %rsp,%rbx
+11af:       mov    $0x100,%edx
+11b4:       mov    %rbx,%rsi
+11b7:       mov    $0x0,%edi
+11bc:       callq  1060 <read@plt>
+11c1:       mov    %rbx,%rdx
+11c4:       lea    0x2eb5(%rip),%rsi
+11cb:       lea    0xe86(%rip),%rdi
+11d2:       mov    $0x0,%eax
+11d7:       callq  1050 <printf@plt>
+11dc:       mov    0x28(%rsp),%rax
+11e1:       sub    %fs:0x28,%rax
+11ea:       jne    11f7 <main+0x8e>
+11ec:       mov    $0x0,%eax
+11f1:       add    $0x30,%rsp
+11f5:       pop    %rbx
+11f6:       retq
+11f7:       callq  1040 <__stack_chk_fail@plt>
+\end{lstlisting}
+
+\begin{lstlisting}[language=bash,float=ht,caption={Disassembly excerpt of the 64 bit binary compiled from the code in \cref{lst:local-global-buffer} with \texttt{gcc -o local-global-buffer -D\_FORTIFY\_SOURCE=2 -O1 local-global-buffer.c}, retrieved with \texttt{objdump -D -{}-no-show-\linebreak[0]raw-insn local-global-buffer} (note the call to \texttt{\_\_read\_chk} instead of \texttt{read} in line 20)}, label={lst:local-global-buffer-disassembly-fortified}]
+0000000000001179 <main>:
+1179:       push   %rbx
+117a:       sub    $0x30,%rsp
+117e:       mov    %fs:0x28,%rax
+1187:       mov    %rax,0x28(%rsp)
+118c:       xor    %eax,%eax
+118e:       lea    0xe73(%rip),%rdi
+1195:       callq  1040 <puts@plt>
+119a:       mov    $0x100,%edx
+119f:       lea    0x2eda(%rip),%rsi
+11a6:       mov    $0x0,%edi
+11ab:       callq  1060 <read@plt>
+11b0:       lea    0xe79(%rip),%rdi
+11b7:       callq  1040 <puts@plt>
+11bc:       mov    %rsp,%rbx
+11bf:       mov    $0x20,%ecx
+11c4:       mov    $0x100,%edx
+11c9:       mov    %rbx,%rsi
+11cc:       mov    $0x0,%edi
+11d1:       callq  1030 <__read_chk@plt>
+11d6:       mov    %rbx,%rcx
+11d9:       lea    0x2ea0(%rip),%rdx
+11e0:       lea    0xe71(%rip),%rsi
+11e7:       mov    $0x1,%edi
+11ec:       mov    $0x0,%eax
+11f1:       callq  1070 <__printf_chk@plt>
+11f6:       mov    0x28(%rsp),%rax
+11fb:       sub    %fs:0x28,%rax
+1204:       jne    1211 <main+0x98>
+1206:       mov    $0x0,%eax
+120b:       add    $0x30,%rsp
+120f:       pop    %rbx
+1210:       retq
+1211:       callq  1050 <__stack_chk_fail@plt>
+\end{lstlisting}
+
 \lstinputlisting[language=C,float=ht,caption={C program outputting an environment variable's memory location in a target program {\cite[147\psq]{Erickson2008}}},label={lst:getenvaddress}]{code/getenvaddress.c}
 
 %%% Local Variables:

chapters/01-introduction.tex

@@ -5,8 +5,7 @@ \chapter{Introduction}
 Entering only the search term ``buffer overflow'' returns a list of 10945 \gls{cve} entries%
 	\footnote{Even though the \gls{cve} search advisory states that such keywords may yield incorrect results, checking random samples of the results showed that the results were in fact correctly corresponding to the given search terms.}%
 .
-Those high numbers show that this kind of memory vulnerability is still very widespread, even though it has already been presented towards the end of the last century, for example in \citeauthor{AlephOne1996}'s famous paper \citetitle{AlephOne1996} \cite{AlephOne1996}.
-\todo{Maybe rework last phrase... technically not 100\% correct}
+Those high numbers show the importance of this kind of memory vulnerability which has already been presented towards the end of the last century, for example in \citeauthor{AlephOne1996}'s famous paper \citetitle{AlephOne1996} \cite{AlephOne1996}.
 
 To the author's best knowledge, no scientific papers providing an overview over stack buffer overflow exploit mechanisms and measures to mitigate such exploits exist.
 Thus, the goal of this report is to gather information from scientific work and consolidate and compare the findings of different researchers in a single paper to provide an overview and a collection of ideas for exploit development and mitigation.

chapters/02-background.tex

@@ -22,23 +22,22 @@ \section{System model}
 In the cases where references to the Linux kernel, the \gls{glibc} or the \gls{gcc} are made, they refer to specific versions of those software products.
 In later versions, the behavior might change in order to mitigate some of the weaknesses described in this report.
 
-Those specific software versions comprise version 5.4.44 of the Linux kernel%
-\footnote{Source code can be viewed online at \href{https://git.kernel.org/stable/h/v5.4.44}{git.kernel.org} \cite{LKD2020}}%
+Those specific software versions comprise version 5.4.50 of the Linux kernel%
+\footnote{Source code can be viewed online at \href{https://git.kernel.org/stable/h/v5.4.50}{git.kernel.org} \cite{LKD2020}}%
 .
 This release is a \gls{lts} release which means that it will be maintained until the end of 2025 \cite{LKO2020}.
 The version of \gls{glibc} is 2.31%
 \footnote{Source code can be viewed online at \href{https://sourceware.org/git/?p=glibc.git;a=tree;h=6ee690ef6fa36bf79d2e05b5a30a4f7e10ba3937;hb=9ea3686266dca3f004ba874745a4087a89682617}{sourceware.org}}%
 .
 \gls{gcc} is used in in the latest 9.x line version 9.3.0.
 
-At the time of writing this report, newer stable releases of the Linux kernel and \gls{gcc} are already available (5.7 for the Linux kernel \cite{LKO2020a}, 10.1 for \gls{gcc} \cite{FSF2020}).
-\todo{Look up whether the referenced parts changed at all or if everything's still valid for the new versions}
+At the time of writing this report, newer stable releases of the Linux kernel and \gls{gcc} are already available (5.7.x line for the Linux kernel \cite{LKO2020a}, 10.x line for \gls{gcc} \cite{FSF2020}).
 However, this does not impose any problems on the real-world consequences of this report's contents.
 The newest editions of popular Linux distributions for \texttt{x86\_64/amd64} processor architectures like Red Hat Enterprise Linux (version 8.2), Ubuntu (version 20.04 \gls{lts}), Debian (version 10.4) are based on the Linux 5.4 \gls{lts} kernel line or even older versions%
 \footnote{See also discussion on \href{https://www.reddit.com/r/webhosting/comments/beg0z0/should_i_use_an_lts_version_of_ubuntu_for_my_web/}{reddit.com} on whether to use \gls{lts} versions for production server deployment}
 \cite{RedHat2020,Canonical2020,SPI2020,SPI2020a}.
 Also, the highest kernel version used for development of the Android mobile \gls{os}, which has a market share of about 70\% \cite{Statcounter2020}, is Linux 5.4 \gls{lts} \cite{GoogleLLC2020}.
-Thus, it is safe to assume that the majority of devices running Linux kernels or kernels closely derived from the Linux kernel run version 5.4.44 or lower.
+Thus, it is safe to assume that the majority of devices running Linux kernels or kernels closely derived from the Linux kernel run version 5.4.50 or lower.
 
 A similar observation can be made for \gls{gcc} version 9.3.0.
 The aforementioned Linux distributions all by default ship the \gls{gcc} package in version 9.3.0 or below \cite{RedHat2020a,Canonical2020a,SPI2020b}.
@@ -177,7 +176,6 @@ \section{Stack Buffer Overflows}
 
 If an attacker can control the data which is copied onto the stack, they%
 	\footnote{In this paper, the gender-neutral singular pronoun ``they'' and pronouns derived from it are used instead of singular ``he'', ``she'' or pronouns derived from those if no specific gender is provided for a person.}
-	\todo{Check if this is the first occurrence, otherwise move footnote to the first one}
 can carefully craft an input string so that they can overwrite the \gls{sfp} or \gls{rip} with attacker-controlled data and thus control where the program tries to look for function-local data (overwritten \gls{sfp}) or to continue execution (overwritten \gls{rip}) after it returns from the current function.
 A stack buffer overflow always occurs if a buffer just like \texttt{c} in \cref{lst:vulnerable-function} is filled with more data than it can hold.
 This does not necessarily mean that the \gls{sfp} or \gls{rip} is overwritten by a stack buffer overflow, but in most cases this is the goal of an attacker in order to divert control flow in the program's execution or manipulate a function's data.

chapters/03-current-defense-mechanisms.tex

@@ -32,8 +32,7 @@ \subsection{The \texttt{\_FORTIFY\_SOURCE} macro}
 For example, \texttt{strcpy} is replaced with \texttt{\_\_strcpy\_chk}.
 If the check fails, the program execution is aborted with an error message \cite{Kerrisk2020,Sharma2014}.
 
-The \texttt{\_FORTITY\_SOURCE} macro can either be manually set to a value higher than 0 or is automatically activated when compiler optimizations are enabled, for example by passing the \texttt{-O3} flag to \gls{gcc} \cite{Kerrisk2020,Sharma2014,Sidhpurwala2018}.
-\todo{Include example? Not sure}
+The \texttt{\_FORTITY\_SOURCE} macro value can be set to a value higher than 0 and is then activated when compiler optimizations are enabled, for example by passing the \texttt{-O3} flag to \gls{gcc} \cite{Kerrisk2020,Sharma2014,Sidhpurwala2018} (cf. \cref{lst:local-global-buffer-disassembly-non-fortified,lst:local-global-buffer-disassembly-fortified} based on \cref{lst:local-global-buffer} without and with source fortification enabled).
 
 \citeauthor{Jelinek2004} states in the announcement of the original implementation of this feature that the runtime overhead of the checks is very small and that the compiler automatically omits the checks if it can prove at compile time that no overflow can occur \cite{Jelinek2004}.
 
@@ -124,7 +123,7 @@ \section{Executable space protection}
 
 These flags allows marking specific pages as non-executable, such as the memory pages containing a program's stack.
 Furthermore, a \gls{wxorx} approach on modern systems marks memory pages as either writable or executable but not both at the same time.
-This approach can be seen as an extension to just marking the stack as non-executable and prevents an attacker from executing code he has written into the program's memory space before.
+This approach can be seen as an extension to just marking the stack as non-executable and prevents an attacker from executing code they have written into the program's memory space before.
 
 \section{Function pointer protection}
 \label{sec:function-pointer-protection-current}