diff --git a/work/01paper.pdf b/work/01paper.pdf index d7e9bfa..77a6872 100644 Binary files a/work/01paper.pdf and b/work/01paper.pdf differ diff --git a/work/01paper.tex b/work/01paper.tex index ba53603..173c693 100644 --- a/work/01paper.tex +++ b/work/01paper.tex @@ -1,6 +1,7 @@ \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. +% 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} @@ -30,7 +31,8 @@ %%fuer abkuerzungen begin \usepackage[acronym,hyperfirst = false]{glossaries} \glsdisablehyper{} -%\usepackage[acronym,acronymlists={main, abbreviationlist},shortcuts,toc,description,footnote]{glossaries} +%\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}} @@ -149,9 +151,18 @@ attacker controlled code. This is only one of several types and exploitation techniques but the general idea stays the same: ovewrite the return address or some kind of function -pointer (e.g. in vtables or the \ac{plt}) and once that function is called, the +pointer (e.g.\ in vtables or the \ac{plt}) and once that function is called, the execution flow is hijacked and the attacker can execute arbitiary code. +The most trivial kinds of exploits is known as a \mintinline{ASM}{NOP} sled. +Here the attacker appends as many \mintinline{ASM}{NOP} instructions before any +shellcode (e.g.\ to invoke \mintinline{shell}{/bin/sh}) and points the +overwritten \ac{ip} somewhere inside the \mintinline{ASM}{NOP}s. The execution +\enquote{slides} through the \mintinline{ASM}{NOP}s until it reaches the +shellcode. Most of the migration techniques described in this paper protect +against this kind of exploit but there are different and more complex ways of +exploiting \acp{bof} that are not that easily migrated. + \subsection{Implications} \section{Concept and Methods}\label{ref:concept} @@ -171,7 +182,9 @@ 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. +that comes with a runtime, uses runtime checking. For this technique to be +effective effective in general, writes to a raw pointer must be disallowed. +Otherwise the security checks can be circumvented. \subsection{Prevent/Detect Overriding Return Address} @@ -224,11 +237,16 @@ 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. +system. \ac{rop} (a superset of ret-to-libc exploits) uses so called \ac{rop} +gadgets, combinations of memory modifying instructions followed by the +\mintinline{ASM}{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. These combinations of memory modification followed by +\mintinline{ASM}{RET} instructions are called \ac{rop} chains and are turing +complete~\cite{Rop2007}, so in theory it is possible to implement any imaginable +payload, as long as the exploited program contains enough gadgets and the +overflowing buffer has enough space. \section{Discussion}\label{ref:discussion} @@ -238,10 +256,11 @@ stack and reuses the existing code to circumvent the w\^{}x protection. \subsubsection{\ac{aslr}} \Ac{aslr} has been really effective and wildly used in production. It is -included in most major operating systems~\cite{FBSDaslr}. Some -even use kernel \ac{aslr}~\cite{Linuxaslr}. 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}. +included in most major operating systems~\cite{FBSDaslr}. Some even use kernel +\ac{aslr}~\cite{Linuxaslr}. Since this mechanism is active at runtime, it does +not require any changes in the code itself, the programm only has to be compiled +as a \ac{pie}. On 32-bit CPUs, only 16-bit of the address are randomized. These +16-bit can be brute forced in a few minutes or seconds~\cite{AslrEffective2004}. \subsubsection{w\^{}x} diff --git a/work/bibliography.bib b/work/bibliography.bib index afc0c58..f87c9bd 100644 --- a/work/bibliography.bib +++ b/work/bibliography.bib @@ -8,6 +8,13 @@ own: year = {2002} } +@inproceedings{Rop2007, + author = {{Shacham, Hovav}}, + booktitle = {{Proceedings of the 14th ACM conference on Computer and communications security (CCS)}}, + title = {{The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86)}}, + year = {2007} +} + @inproceedings{Detection2018, author = {{Chaim, Marcos and Santos, Daniel and Cruzes, Daniela}}, booktitle = {{International Journal of Systems and Software Security and Protection (IJSSSP)}}, @@ -46,6 +53,13 @@ year = {2001} year = {1998} } +@inproceedings{AslrEffective2004, + year = {2004}, + booktitle = {{11\textsuperscript{th} ACM conference on Computer and communications security (CCS)}}, + title = {{On the Effectiveness of Address-Space Randomization}}, + author = {{Shacham, Hovav and Page, Matthew and Pfaff, Ben and Goh, Eu-Jin and Modadugu, Nagendra and Boneh, Dan}} +} + @ARTICLE{Smashing2004, author={J. {Pincus} and B. {Baker}}, journal={{IEEE Security \& Privacy}},