context: describe stack clash/guard page

src/docs/parts/context/context.tex

@@ -245,9 +245,9 @@ The purpose is to demonstrate that the same program \gls{bbox} is instantiated t
     \label{shell::context::os-dev-concepts::program-process}
 \end{listing}
 
-It invokes \gls{bbox} with the "sh" (a shell utility) argument which in turn receives the "-c" (command execute" argument and another argument containing the expected command.
+It invokes \gls{bbox} with the \code{sh} (a shell utility) argument which in turn receives the \code{-c} (command execute" argument and another argument containing the expected command.
-This command consists of subsequent calls to \gls{bbox} invoking its builtin "ps" (a utility to print the process list) and "grep" (a tool to find text) utilities.
+This command consists of subsequent calls to \gls{bbox} invoking its builtin \code{ps} (a utility to print the process list) and \code{grep} (a tool to find text) utilities.
-The process list is received by passing "ps" as the argument to \gls{bbox} in the third execution.
+The process list is received by passing \code{ps} as the argument to \gls{bbox} in the third execution.
 Line 2 through 4 show the three \glspl{process} of the \gls{bbox} \gls{program} with different proccess ids and their respective arguments.
 
 \section{Preemptive Multitasking Concepts}
@@ -586,28 +586,28 @@ The instructions that use these registers and explicitly or implicitly work with
 Together they can be used to perform \gls{stack} based procedure calls, as demonstrated in the following \cref{context::os-dev-concepts::sf-handling-amd64::procedure-call-example}.
 
 \subsection{Direct Stack Data Management Instructions}
-\mintinline{nasm}{PUSH} a takes value operand which is to be pushed onto the stack.
+\code{push} a takes value operand which is to be pushed onto the stack.
-The address in RSP moves towards numerically lower addresses with every \mintinline{nasm}{PUSH} instruction, which stores a new data entry on top.
+The address in RSP moves towards numerically lower addresses with every \code{push} instruction, which stores a new data entry on top.
 The order is to first change the RSP and then copy the value at its new address.
 
-\mintinline{nasm}{POP} takes a storage reference operand - \gls{cpu} register or memory address.
+\code{pop} takes a storage reference operand - \gls{cpu} register or memory address.
-It works in the opposite direction to \mintinline{nasm}{PUSH}.
+It works in the opposite direction to \code{push}.
 First, consuming the top-most data entry and storing it on the operand location, then moving the RSP address towards the numerically higher RBP address.
 
 When RBP and RSP point to the same address, the stack is considered empty.
 
 \subsection{Procedure Calls Instructions}
-The \mintinline{nasm}{CALL} and \mintinline{nasm}{RET} instructions control the instruction flow by calling another instruction procedure\footnote{loosely synonymous with function}.
+The \code{call} and \code{ret} instructions control the instruction flow by calling another instruction procedure\footnote{loosely synonymous with function}.
 
 
-The \mintinline{nasm}{CALL} instruction takes the address of the instruction that is to be called.
+The \code{call} instruction takes the address of the instruction that is to be called.
-Before jumping to the instruction at the given address, it \mintinline{nasm}{PUSH}es the current RIP (instruction pointer) register onto the \gls{stack}.
+Before jumping to the instruction at the given address, it \code{push}es the current RIP (instruction pointer) register onto the \gls{stack}.
 
-\mintinline{nasm}{RET} takes no operand, but instead \mintinline{nasm}{POP}s the \gls{stack}'s top entry.
+\code{ret} takes no operand, but instead \code{pop}s the \gls{stack}'s top entry.
 The consumed value is used as a jump address.
 
-As \mintinline{nasm}{PUSH} and \mintinline{nasm}{POP} use the RSP register, the called procedure is responsible to finish with the RSP at the same position as when it was entered.
+As \code{push} and \code{pop} use the RSP register, the called procedure is responsible to finish with the RSP at the same position as when it was entered.
-For example, \mintinline{nasm}{PUSH}ing some value onto the stack before the end of the function would cause the \mintinline{nasm}{RET} to jump to that address instead of returning to the caller.
+For example, \code{push}ing some value onto the stack before the end of the function would cause the \code{ret} to jump to that address instead of returning to the caller.
 
 \subsection{Stack Frame Management Instructions}
 When a procedure is called, the stack is set up with the \gls{sf}, the four components listed in \cref{lst:amd64-stack-frame-components}.
@@ -620,8 +620,8 @@ When a procedure is called, the stack is set up with the \gls{sf}, the four comp
         \textit{Only if parameters don't fit the \gls{cpu} registers}
     }
     \item{%
-        Return address (created by the \mintinline{nasm}{CALL} instruction). \\
+        Return address (created by the \code{call} instruction). \\
-        \textit{Always used by \mintinline{nasm}{CALL}}
+        \textit{Always used by \code{call}}
     }
     \item{%
         Array of stack-frame pointers (pointers to stack frames of procedures with smaller nesting-level depth) which are used to access the local variables of such procedures. \\
@@ -636,10 +636,10 @@ When a procedure is called, the stack is set up with the \gls{sf}, the four comp
 \label{lst:amd64-stack-frame-components}
 \end{listing}
 
-The \gls{amd64} manual also lists \mintinline{nasm}{ENTER} and \mintinline{nasm}{LEAVE} as instructions to \textit{"provide support for procedure calls, and are mainly used in high-level languages."}\cite[p.~48]{AMD64Vol1}.
+The \gls{amd64} manual also lists \code{enter} and \code{leave} as instructions to \textit{"provide support for procedure calls, and are mainly used in high-level languages."}\cite[p.~48]{AMD64Vol1}.
 The latter claim could not be verified by inspecting binaries produced by the \gls{C} and \gls{Rust} \glspl{compiler}.
 
-Instead, these \glspl{compiler} generate a sequence of \mintinline{nasm}{PUSH}, \mintinline{nasm}{MOV} and \mintinline{nasm}{SUB} instructions to manage theset up the \gls{stack}.
+Instead, these \glspl{compiler} generate a sequence of \code{push}, \code{mov} and \code{sub} instructions to manage theset up the \gls{stack}.
 There are instructions before and after the procedure's logic, taking care of the technicalities of \gls{stack} management.
 These instruction groups within the called procedure are called prologue and epilogue.
 
@@ -648,7 +648,7 @@ These instruction groups within the called procedure are called prologue and epi
 This section combines the separate categories into one complete example that shows how the \gls{stack} is used by various \gls{cpu} instructions to perform procedure calls.
 The following code samples are extracted from a disassembled binary which was originally created using \gls{Rust}.
 The Assembler that's shown uses Intel Mnemonic, which generally operates from right to left.
-For example, \mintinline{nasm}{mov a, b} copies b to a.
+For example, \code{mov a, b} copies b to a.
 
 \cref{code::context::examples::func-callee-rust} shows the \gls{Rust} source code of the function \textit{sum}.
 
@@ -1208,23 +1208,54 @@ if (ptr == NULL) {
 \end{lstlisting}
 
 \subsection{The Stack Clash}
-A recent and high impact vulnerability named \textit{Stack Clash}\footnote{https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash}, is briefly described as \textit{"a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64.  It can be exploited by attackers to corrupt memory and execute arbitrary code."}
+\label{context::common-mem-safety-mistakes::manifestations::stack-clash}
-The \gls{LX} specific vulnerability is listed as CVE-2017-1000364\footnote{http://www.cvedetails.com/cve/CVE-2017-1000364/}, where \textit{"an issue was discovered in the size of the stack guard page on Linux, specifically a 4k stack guard page is not sufficiently large and can be "jumped" over (the stack guard page is bypassed)"}.
+A recent high severity vulnerability named \textit{Stack Clash}\cite{TheStackClash}, is briefly described as \textit{"a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64.  It can be exploited by attackers to corrupt memory and execute arbitrary code."}
-It is assigned to the \citetitle{MITRE-CWE-119}\autocite{MITRE-CWE-119} presented in \cref{context::common-mem-safety-mistakes::cwe::119}.
+The \gls{LX} specific vulnerability is listed as CVE-2017-1000364\footnote{\url{http://www.cvedetails.com/cve/CVE-2017-1000364/}}, where \textit{"an issue was discovered in the size of the stack guard page on Linux, specifically a 4k stack guard page is not sufficiently large and can be "jumped" over (the stack guard page is bypassed)"}.
+The vulnerability is assigned to the \citetitle{MITRE-CWE-119}\autocite{MITRE-CWE-119} presented in \cref{context::common-mem-safety-mistakes::cwe::119}.
 
-\cref{context::os-dev-concepts::hw-supported-mm::multilevel-paging-concept,context::os-dev-concepts::hw-supported-mm::multilevel-paging-amd64}
+\subsubsection{Affecting Multiple OSs}
+The vulnerability is extremely interesting for several reasons.
+The issue has been recognized in 2005 and partially fixed in \gls{LX} in 2010 by introducing a guard page, but it wasn't considered to be a high risk.
+Several years later, It has been found to affect the memory management of several \glspl{os} which don't share the same code base.
 
-\cref{context::os-dev-concepts::hw-supported-mm::page-fault}
+The two affected architectures are closely related and share the same memory-paging concepts, most of which are explained in \cref{context::os-dev-concepts::hw-supported-mm::multilevel-paging-concept,context::os-dev-concepts::hw-supported-mm::multilevel-paging-amd64,context::os-dev-concepts::hw-supported-mm::page-fault}.
+This simply answers the question how this vulnerability can be present on in multiple \glspl{os}; they all implemented the same concept when this vulnerability was not popular enough.
 
-% TODO explain that this CWE-119 vulnerability is also "Execute Code"
+\subsubsection{Unguarded Stack Growth}
-% TODO more references and deeper explanation of what happens: see introduction in https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
+The guard page concept has been introduced to prevent the stack from growing further than it should.\footnote{Related Linux CVE-2010-2240}
+
+If the stack grows contiguously and thus accesses virtual addresses that are not mapped to a page, the \gls{os}'s page-fault handler has the chance to inspect the situation.
+The \gls{os} simply allocates a new page for the unmapped virtual address and allows the process to grow its stack.
+When the virtual address accesses the defined guard page, the \gls{os} denies the operation and the process will be notified by a segmentation fault.
+This works as long one of these conditions is true: 
+\begin{itemize}
+    \item The guard page spans a virtual address range that is larger than the largest stack increment  
+    \item The area behind the stack page is unmapped and will also a page-fault
+\end{itemize}
+As the existence of vulnerability proves, these two conditions aren't always met.
+
+\subsubsection{The Stack and Heap Overlap}
+The reason why the existing guard page didn't work as expected are cases were the stack can indeed increment by a large enough amount to leap over the guard page.
+And somewhere beyond the guard page is the heap, and the stack can happen to grow large enough to reach it.
+This effectively overlaps the stack and the heap and makes it possible to use access one through variables of the other variables.
+
+The best case scenario is mere memory corruption and the crash of the application.
+In the worst case there's possible execution of arbitrary code, which can be by used by an attacker to gain control of the application and possibly the whole system.
+
+\subsubsection{Solutions}
+The researchers at \textit{qualys} suggest two solutions\cite[III]{TheStackClash}.
+
+The first proposed solution is to increase the guard page to 1MB or larger within the \gls{os}.
+This doesn't guarantee absolute protection as it still be possible to have a large enough stack growth that surpasses the 1MB guard.
+
+The second solution doesn't involve the \gls{os} at all.
+The suggestion is to compile all \glspl{app} on the system with the GCC \gls{compiler} option \mintinline{markdown}{`-fstack-check`}.
+This allegedly "prevents the stack-pointer from moving into another memory region without accessing the stack guard-page (it writes one word to every 4KB page allocated on the stack)."
+This features seems interesting to investigate further, as stack protection is also something procedures within the \gls{os} could make use of.
 
 \chapter{Weakness Mitigation}
 \label{context::weakness-mitigation}
                                                                                                                                                           
-
-                                                                                                                                                                                      
-
 \section{Detecting Memory-Safety Violations ASAP}
 \label{context::safe-os-dev::detecting-safety-violations-asap}
 Given that it can not be prevented for individuals to type erroneous code into their code editors.

src/docs/parts/research_and_development/research_and_development.tex

@@ -7,6 +7,7 @@
 % TLB needs to be reset on Task Change
 % ISR-Stack-Frame needs to be updated on context-switch
 
+
 \section{Software Fault Isolation}
 % TODO: content from \cite{Balasubramanian2017}
 
@@ -17,20 +18,22 @@
 % TODO * Control access to duplicates in page tables
 % TODO * Tasks can't access unallocated (physical) memory
 % TODO * Tasks can't access other tasks memory
-\subsection{Paging}
+
-Setting up and maintaining the paging-structure, as well as allocating physical memory for the virtual pages is a complex task in the \gls{os}.
-Developing this part of the \gls{os} is error-prone, and is not well-supported by mainstream \glspl{proglang}.
 
 \chapter{Porting \glsentrytext{C} Vulnerabilities}
 \label{rnd::porting-c-vulns}
 In this chapter, the weakness manifestations given in \cref{context::common-mem-safety-mistakes::manifestations} are rewritten in \gls{Rust} to examine if these are mitigated just by porting them.
 This is done incrementally by first porting the vulnerability to unsafe Rust, followed by a rewrite to drop all unsafe code but keeping the intended functionality.
-
-% TODO stack frame manipulation
 % TODO official CWE-119 examples
 
 \chapter{\glsentrytext{LX} Modules Written In \glsentrytext{Rust}}
 
+\chapter{Stack Protection}
+The goal of this chapter is to learn about \gls{Rust}'s stack protection mechanisms, and determine if it can help with the issue described in \cnameref{context::common-mem-safety-mistakes::manifestations::stack-clash}.
+
+% TODO stack frame manipulation example
+
+
 \chapter{Existing \glsentrytext{os}-Development Projects Based On Rust}
 \label{rnd::existing-os-dev-with-rust}
 
@@ -39,7 +42,6 @@ This is done incrementally by first porting the vulnerability to unsafe Rust, fo
 \subsection{Libfringe}
 % TODO: https://github.com/edef1c/libfringe
 
-
 \section{Systems}
 \subsection{intermezzOS}
 \subsection{Blog OS}

src/docs/thesis.bib

@@ -3,15 +3,11 @@ Any changes to this file will be lost if it is regenerated by Mendeley.
 
 BibTeX export options can be customized via Options -> BibTeX in Mendeley Desktop
 
-@article{Matz2009,
+@misc{TheStackClash,
-author = {Matz, M and Hubicka, J and Jaeger, a and Mitchell, M},
+author = {Advisory, Qualys Security},
-file = {:home/steveej/src/steveej/msc-thesis/docs/System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.7.pdf:pdf},
+file = {:home/steveej/src/steveej/msc-thesis/docs/stack-clash.txt:txt},
-isbn = {013877630X},
+title = {{The Stack Clash}},
-pages = {1--128},
+url = {https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt}
-pmid = {2477614},
-title = {{System V Application Binary Interface AMD64 Architecture Processor Supplement}},
-url = {papers2://publication/uuid/CD8D5668-B1F5-4FE3-BAD8-25F1E589A9E5},
-year = {2009}
 }
 @article{Lattner2005,
 abstract = {The LLVM Compiler Infrastructure (http://llvm.cs. uiuc.edu) is a$\backslash$nrobust system that is well suited for a wide variety of research$\backslash$nand development work. This brief paper introduces the LLVM system$\backslash$nand provides pointers to more extensive documentation, complementing$\backslash$nthe tutorial presented at LCPC.},
@@ -125,6 +121,16 @@ file = {:home/steveej/src/github/steveej/msc-thesis/docs/DRAFT$\backslash$: Syst
 title = {{DRAFT: System Programming in Rust: Beyond Safety}},
 year = {2017}
 }
+@article{Matz2009,
+author = {Matz, M and Hubicka, J and Jaeger, a and Mitchell, M},
+file = {:home/steveej/src/steveej/msc-thesis/docs/System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.7.pdf:pdf},
+isbn = {013877630X},
+pages = {1--128},
+pmid = {2477614},
+title = {{System V Application Binary Interface AMD64 Architecture Processor Supplement}},
+url = {papers2://publication/uuid/CD8D5668-B1F5-4FE3-BAD8-25F1E589A9E5},
+year = {2009}
+}
 @article{Chisnall2015,
 abstract = {We propose a new memory-safe interpretation of the C ab-stract machine that provides stronger protection to benefit security and debugging. Despite ambiguities in the specifi-cation intended to provide implementation flexibility, con-temporary implementations of C have converged on a mem-ory model similar to the PDP-11, the original target for C. This model lacks support for memory safety despite well-documented impacts on security and reliability. Attempts to change this model are often hampered by as-sumptions embedded in a large body of existing C code, dat-ing back to the memory model exposed by the original C compiler for the PDP-11. Our experience with attempting to implement a memory-safe variant of C on the CHERI ex-perimental microprocessor led us to identify a number of problematic idioms. We describe these as well as their in-teraction with existing memory safety schemes and the as-sumptions that they make beyond the requirements of the C specification. Finally, we refine the CHERI ISA and abstract model for C, by combining elements of the CHERI capabil-ity model and fat pointers, and present a softcore CPU that implements a C abstract machine that can run legacy C code with strong memory protection guarantees.},
 author = {Chisnall, David and Rothwell, Colin and Watson, Robert N M and Woodruff, Jonathan and Vadera, Munraj and Moore, Simon W and Roe, Michael and Davis, Brooks and Neumann, Peter G},

src/docs/thesis.tex

@@ -216,7 +216,8 @@
   \fi
   \next@mfu@cap#2\mfu@endcap
 }
-                                 
+\newcommand{\code}[2][md]{\mintinline{#1}{`#2`}}
+
 \makeatother
 \include{glossary}