\documentclass{article}+
−
\usepackage{../style}+
−
\usepackage{../langs}+
−
+
−
\begin{document}+
−
+
−
\section*{Handout 3 (Buffer Overflow Attacks)}+
−
+
−
By far the most popular attack method on computers are buffer+
−
overflow attacks or simple variations thereof. The popularity is+
−
unfortunate because we nowadays have technology in place to prevent them+
−
effectively. But these kind of attacks are still very relevant+
−
even today since there are many legacy systems out there and+
−
also many modern embedded systems do not take any precautions+
−
to prevent such attacks.+
−
+
−
To understand how buffer overflow attacks work, we have to have+
−
a look at how computers work ``under the hood'' (on the+
−
machine level) and also understand some aspects of the C/C+++
−
programming language. This might not be everyday fare for+
−
computer science students, but who said that criminal hackers+
−
restrict themselves to everyday fare? Not to mention the+
−
free-riding script-kiddies who use this technology without+
−
even knowing what the underlying ideas are. If you want to be+
−
a good security engineer who needs to defend such attacks, +
−
then better you know the details.+
−
 +
−
For buffer overflow attacks to work, a number of innocent+
−
design decisions, which are really benign on their own, need+
−
to conspire against you. All these decisions were pretty much+
−
taken at a time when there was no Internet: C was introduced+
−
around 1973; the Internet TCP/IP protocol was standardised in+
−
1982 by which time there were maybe 500 servers connected (and+
−
all users were well-behaved, mostly academics); Intel's first+
−
8086 CPUs arrived around 1977. So nobody of the+
−
``forefathers'' can really be blamed, but as mentioned above+
−
we should already be way beyond the point that buffer overflow+
−
attacks are worth a thought. Unfortunately, this is far from+
−
the truth. I let you ponder why?+
−
+
−
One such ``benign'' design decision is how the memory is laid+
−
out into different regions for each process. +
−
 +
−
\begin{center}+
−
  \begin{tikzpicture}[scale=0.7]+
−
  %\draw[step=1cm] (-3,-3) grid (3,3);+
−
  \draw[line width=1mm] (-2, -3) rectangle (2,3);+
−
  \draw[line width=1mm] (-2,1) -- (2,1);+
−
  \draw[line width=1mm] (-2,-1) -- (2,-1);+
−
  \draw (0,2) node {\large\tt text};+
−
  \draw (0,0) node {\large\tt heap};+
−
  \draw (0,-2) node {\large\tt stack};+
−
+
−
  \draw (-2.7,3) node[anchor=north east] {\tt\begin{tabular}{@{}l@{}}lower\\ address\end{tabular}};+
−
  \draw (-2.7,-3) node[anchor=south east] {\tt\begin{tabular}{@{}l@{}}higher\\ address\end{tabular}};+
−
  \draw[->, line width=1mm] (-2.5,3) -- (-2.5,-3);+
−
+
−
  \draw (2.7,-2) node[anchor=west] {\tt grows};+
−
  \draw (2.7,-3) node[anchor=south west] {\tt\footnotesize older};+
−
  \draw (2.7,-1) node[anchor=north west] {\tt\footnotesize newer};+
−
  \draw[|->, line width=1mm] (2.5,-3) -- (2.5,-1);+
−
  \end{tikzpicture}+
−
\end{center}+
−
+
−
\noindent The text region contains the program code (usually+
−
this region is read-only). The heap stores all data the+
−
programmer explicitly allocates. For us the most interesting+
−
region is the stack, which contains data mostly associated+
−
with the control flow of the program. Notice that the stack+
−
grows from a higher addresses to lower addresses. That means+
−
that older items on the stack will be stored behind, or after,+
−
newer items. Let's look a bit closer what happens with the+
−
stack when a program is running. Consider the following simple+
−
C program.+
−
 +
−
\lstinputlisting[language=C]{../progs/example1.c} +
−
 +
−
\noindent The \code{main} function calls \code{foo} with three+
−
arguments. \code{Foo} contains two (local) buffers. The+
−
interesting point for us will be what will the stack loke+
−
like after Line 3 has been executed? The answer is as follows:+
−
 +
−
\begin{center} +
−
 \begin{tikzpicture}[scale=0.65]+
−
  \draw[gray!20,fill=gray!20] (-5, 0) rectangle (-3,-1);+
−
  \draw[line width=1mm] (-5,-1.2) -- (-5,0.2);+
−
  \draw[line width=1mm] (-3,-1.2) -- (-3,0.2);+
−
  \draw (-4,-1) node[anchor=south] {\tt main};+
−
  \draw[line width=1mm] (-5,0) -- (-3,0);+
−
+
−
  \draw[gray!20,fill=gray!20] (3, 0) rectangle (5,-1);+
−
  \draw[line width=1mm] (3,-1.2) -- (3,0.2);+
−
  \draw[line width=1mm] (5,-1.2) -- (5,0.2);+
−
  \draw (4,-1) node[anchor=south] {\tt main};+
−
  \draw[line width=1mm] (3,0) -- (5,0);+
−
 +
−
   %\draw[step=1cm] (-3,-1) grid (3,8);+
−
  \draw[gray!20,fill=gray!20] (-1, 0) rectangle (1,-1);+
−
  \draw[line width=1mm] (-1,-1.2) -- (-1,7.4);+
−
  \draw[line width=1mm] ( 1,-1.2) -- ( 1,7.4);+
−
  \draw (0,-1) node[anchor=south] {\tt main};+
−
  \draw[line width=1mm] (-1,0) -- (1,0);+
−
  \draw (0,0) node[anchor=south] {\tt arg$_3$=3};+
−
  \draw[line width=1mm] (-1,1) -- (1,1);+
−
  \draw (0,1) node[anchor=south] {\tt arg$_2$=2};+
−
  \draw[line width=1mm] (-1,2) -- (1,2);+
−
  \draw (0,2) node[anchor=south] {\tt arg$_1$=1};+
−
  \draw[line width=1mm] (-1,3) -- (1,3);+
−
  \draw (0,3.1) node[anchor=south] {\tt ret};+
−
  \draw[line width=1mm] (-1,4) -- (1,4);+
−
  \draw (0,4) node[anchor=south] {\small\tt last sp};+
−
  \draw[line width=1mm] (-1,5) -- (1,5);+
−
  \draw (0,5) node[anchor=south] {\tt buf$_1$};+
−
  \draw[line width=1mm] (-1,6) -- (1,6);+
−
  \draw (0,6) node[anchor=south] {\tt buf$_2$};+
−
  \draw[line width=1mm] (-1,7) -- (1,7);+
−
+
−
  \draw[->,line width=0.5mm] (1,4.5) -- (1.8,4.5) -- (1.8, 0) -- (1.1,0); +
−
  \draw[->,line width=0.5mm] (1,3.5) -- (2.5,3.5);+
−
  \draw (2.6,3.1) node[anchor=south west] {\tt back to main()};+
−
\end{tikzpicture}+
−
\end{center} +
−
+
−
\noindent On the left is the stack before \code{foo} is+
−
called; on the right is the stack after \code{foo} finishes.+
−
The function call to \code{foo} in Line 7 pushes the arguments+
−
onto the stack in reverse order---shown in the middle.+
−
Therefore first 3 then 2 and finally 1. Then it pushes the+
−
return address to the stack where execution should resume once+
−
\code{foo} has finished. The last stack pointer (\code{sp}) is+
−
needed in order to clean up the stack to the last level---in+
−
fact there is no cleaning involved, but just the top of the+
−
stack will be set back. The two buffers are also on the stack,+
−
because they are local data within \code{foo}. So in the+
−
middle is a snapshot of the stack after Line 3 has been +
−
executed. In case you are familiar with assembly instructions+
−
you can also read off this behaviour from the machine+
−
code that the \code{gcc} compiler generates for the program+
−
above:\footnote{You can make \pcode{gcc} generate assembly +
−
instructions if you call it with the \pcode{-S} option, +
−
for example \pcode{gcc -S out in.c}\;. Or you can look+
−
at this code by using the debugger. This will be explained+
−
later.}.+
−
+
−
\begin{center}\small+
−
\begin{tabular}[t]{@{}c@{\hspace{8mm}}c@{}}+
−
{\lstinputlisting[language={[x86masm]Assembler},+
−
  morekeywords={movl},xleftmargin=5mm]+
−
  {../progs/example1a.s}} &+
−
{\lstinputlisting[language={[x86masm]Assembler},+
−
  morekeywords={movl,movw},xleftmargin=5mm]+
−
  {../progs/example1b.s}}  +
−
\end{tabular}+
−
\end{center}+
−
+
−
\noindent On the left you can see how the function+
−
\pcode{main} prepares in Lines 2 to 7 the stack, before+
−
calling the function \pcode{foo}. You can see that the+
−
numbers 3, 2, 1 are stored on the stack (the register+
−
\code{$esp} refers to the top of the stack). On the right+
−
you can see how the function \pcode{foo} stores the two local+
−
buffers onto the stack and initialises them with the given+
−
data (Lines 2 to 9). Since there is no real computation+
−
going on inside \pcode{foo} the function then just restores+
−
the stack to its old state and crucially sets the return+
−
address where the computation should resume (Line 9 in the+
−
code on the left hand side). The instruction \code{ret} then+
−
transfers control back to the function \pcode{main} to the+
−
teh instruction just after the call, namely Line 9.+
−
 +
−
Another part of the ``conspiracy'' is that library functions+
−
in C look typically as follows:+
−
 +
−
\begin{center}+
−
\lstinputlisting[language=C,numbers=none]{../progs/app5.c}+
−
\end{center} +
−
+
−
\noindent This function copies data from a source \pcode{src}+
−
to a destination \pcode{dst}. The important point is that it+
−
copies the data until it reaches a zero-byte (\code{"\\0"}). +
−
+
−
The central idea of the buffer overflow attack is to overwrite+
−
the return address on the stack which states where the control+
−
flow of the program should resume once the function at hand+
−
has finished its computation. So if we have somewhere in a +
−
function a local a buffer, say+
−
+
−
\begin{center}+
−
\code{char buf[8];}+
−
\end{center}+
−
+
−
\noindent+
−
then the corresponding stack will look as follows+
−
+
−
\begin{center}+
−
 \begin{tikzpicture}[scale=0.65]+
−
  %\draw[step=1cm] (-3,-1) grid (3,8);+
−
  \draw[gray!20,fill=gray!20] (-1, 0) rectangle (1,-1);+
−
  \draw[line width=1mm] (-1,-1.2) -- (-1,6.4);+
−
  \draw[line width=1mm] ( 1,-1.2) -- ( 1,6.4);+
−
  \draw (0,-1) node[anchor=south] {\tt main};+
−
  \draw[line width=1mm] (-1,0) -- (1,0);+
−
  \draw (0,0) node[anchor=south] {\tt arg$_3$=3};+
−
  \draw[line width=1mm] (-1,1) -- (1,1);+
−
  \draw (0,1) node[anchor=south] {\tt arg$_2$=2};+
−
  \draw[line width=1mm] (-1,2) -- (1,2);+
−
  \draw (0,2) node[anchor=south] {\tt arg$_1$=1};+
−
  \draw[line width=1mm] (-1,3) -- (1,3);+
−
  \draw (0,3.1) node[anchor=south] {\tt ret};+
−
  \draw[line width=1mm] (-1,4) -- (1,4);+
−
  \draw (0,4) node[anchor=south] {\small\tt last sp};+
−
  \draw[line width=1mm] (-1,5) -- (1,5);+
−
  \draw (0,5) node[anchor=south] {\tt buf};+
−
  \draw[line width=1mm] (-1,6) -- (1,6);+
−
  \draw (2,5.1) node[anchor=south] {\code{$esp}};+
−
  \draw[<-,line width=0.5mm] (1.1,6) -- (2.5,6);+
−
+
−
  \draw[->,line width=0.5mm] (1,4.5) -- (2.5,4.5);+
−
  \draw (2.6,4.1) node[anchor=south west] {\code{??}};+
−
  +
−
  \draw[->,line width=0.5mm] (1,3.5) -- (2.5,3.5);+
−
  \draw (2.6,3.1) node[anchor=south west] {\tt jump to \code{\\x080483f4}};+
−
\end{tikzpicture}+
−
\end{center}+
−
+
−
\noindent We need to fill this over its limit of+
−
8 characters so that it overwrites the stack pointer+
−
and then overwrites the return address. If, for example, +
−
we want to jump to a specific address in memory, say,+
−
\pcode{\\x080483f4} then we need to fill the +
−
buffer for example as follows+
−
+
−
\begin{center}+
−
\code{char buf[8] = "AAAAAAAABBBB\\xf4\\x83\\x04\\x08";}+
−
\end{center}+
−
 +
−
\noindent The first 8 \pcode{A}s fill the buffer to the rim;+
−
the next four \pcode{B}s overwrite the stack pointer (with+
−
what data we overwrite this part is usually not important);+
−
then comes the address we want to jump to. Notice that we have+
−
to give the address in the reverse order. All addresses on+
−
Intel CPUs need to be given in this way. Since the string is+
−
enclosed in double quotes, the C convention is that the string+
−
internally will automatically be terminated by a zero-byte. If+
−
the programmer uses functions like \pcode{strcpy} for filling+
−
the buffer \pcode{buf}, then we can be sure it will overwrite+
−
the stack in this manner---since it will copy everything up+
−
to the zero-byte.+
−
+
−
What the outcome of such an attack is can be illustrated with+
−
the code shown in Figure~\ref{C2}. Under ``normal operation''+
−
this program ask for a login-name and a password (both are+
−
represented as strings). Both of which are stored in buffers+
−
of length 8. The function \pcode{match} tests whether two such +
−
strings are equal. If yes, then the function lets you in+
−
(by printing \pcode{Welcome}). If not, it denies access+
−
(by printing \pcode{Wrong identity}). The vulnerable function+
−
is \code{get_line} in Lines 11 to 19. This function does not+
−
take any precautions about the buffer of 8 characters being+
−
filled beyond this 8-character-limit. The buffer overflow+
−
can be triggered by inputing something, like \pcode{foo}, for +
−
the login name and then the specially crafted string as +
−
password:+
−
+
−
\begin{center}+
−
\code{AAAAAAAABBBB\\x2c\\x85\\x04\\x08\\n}+
−
\end{center}+
−
+
−
\noindent The address happens to be the one for the function+
−
\pcode{welcome()}. This means even with this input (where the+
−
login name and password clearly do not match) the program will+
−
still print out \pcode{Welcome}. The only information we need+
−
for this attack is to know where the function+
−
\pcode{welcome()} starts in memory. This information can be+
−
easily obtained by starting the program inside the debugger+
−
and disassembling this function. +
−
+
−
\begin{lstlisting}[numbers=none,language={[x86masm]Assembler},+
−
  morekeywords={movl,movw}]+
−
$ gdb C2+
−
GNU gdb (GDB) 7.2-ubuntu+
−
(gdb) disassemble welcome+
−
\end{lstlisting}+
−
+
−
\noindent +
−
The output will be something like this+
−
+
−
\begin{lstlisting}[numbers=none,language={[x86masm]Assembler},+
−
  morekeywords={movl,movw}]+
−
0x0804852c <+0>:     push   %ebp+
−
0x0804852d <+1>:     mov    %esp,%ebp+
−
0x0804852f <+3>:     sub    $0x4,%esp+
−
0x08048532 <+6>:     movl   $0x8048690,(%esp)+
−
0x08048539 <+13>:    call   0x80483a4 <puts@plt>+
−
0x0804853e <+18>:    movl   $0x0,(%esp)+
−
0x08048545 <+25>:    call   0x80483b4 <exit@plt>+
−
\end{lstlisting}+
−
+
−
\noindent indicating that the function \pcode{welcome()}+
−
starts at address \pcode{0x0804852c}.+
−
+
−
\begin{figure}[p]+
−
\lstinputlisting[language=C]{../progs/C2.c}+
−
\caption{A suspicious login implementation.\label{C2}}+
−
\end{figure}+
−
+
−
This kind of attack was very popular with commercial programs+
−
that needed a key to be unlocked. Historically, hackers first +
−
broke the rather weak encryption of these locking mechanisms.+
−
After the encryption had been made stronger, hackers used+
−
buffer overflow attacks as shown above to jump directly to+
−
the part of the program that was intended to be only available+
−
after the correct key was typed in by the user. +
−
+
−
\subsection*{Paylods}+
−
+
−
Unfortunately, much more harm can be caused by buffer overflow+
−
attacks. This is achieved by injecting code that will be run+
−
once the return address is appropriately modified. Typically+
−
the code that will be injected is for running a shell. In+
−
order to be send as part of the string that is overflowing the+
−
buffer, we need the code to be encoded as a sequence of +
−
characters+
−
+
−
\lstinputlisting[language=C,numbers=none]{../progs/o1.c}+
−
+
−
\noindent These characters represent the machine code+
−
for opening a shell. It seems obtaining such a string+
−
requires higher-education in the architecture of the+
−
target system. But it is actually relatively simple: First+
−
there are many ready-made strings available---just a quick+
−
Google query away. Second, tools like the debugger can help +
−
us again. We can just write the code we want in C, for +
−
example this would be the program to start a shell+
−
+
−
\lstinputlisting[language=C,numbers=none]{../progs/shell.c} +
−
+
−
\noindent Once compiled, we can use the debugger to obtain +
−
the machine code, or even the ready made encoding as character+
−
sequence. +
−
+
−
While easy, obtaining this string is not entirely trivial.+
−
Remember the functions in C that copy or fill buffers work+
−
such that they copy everything until the zero byte is reached.+
−
Unfortunately the ``vanilla'' output from the debugger for the+
−
shell-program will contain such zero bytes. So a+
−
post-processing phase is needed to rewrite the machine code+
−
such that it does not contain any zero bytes. This is like+
−
some works of literature that have been rewritten so that the+
−
letter 'i', for example, is avoided. For rewriting the machine+
−
code you might need to use clever tricks like+
−
+
−
\begin{lstlisting}[numbers=none,language={[x86masm]Assembler}]+
−
xor %eax, %eax+
−
\end{lstlisting}+
−
+
−
\noindent This instruction does not contain any zero byte when+
−
encoded, but produces a zero byte on the stack. +
−
+
−
Having removed the zero bytes we can craft the string that +
−
will be send to our target computer. It is typically of the +
−
form+
−
+
−
\begin{center}+
−
  \begin{tikzpicture}[scale=0.7]+
−
  \draw[line width=1mm] (-2, -1) rectangle (2,3);+
−
  \draw[line width=1mm] (-2,1.9) -- (2,1.9);+
−
  \draw (0,2.5) node {\large\tt shell code};+
−
  \draw[line width=1mm,fill=black] (0.3, -1) rectangle (2,-0.7);+
−
  \draw[->,line width=0.3mm] (1.05, -1) -- (1.05,-1.7) --+
−
  (-3,-1.7) -- (-3, 3.7) -- (-1.9, 3.7) -- (-1.9, 3.1);+
−
  \draw (-2, 3) node[anchor=north east] {\LARGE\tt "};+
−
  \draw ( 2,-0.9) node[anchor=west] {\LARGE\tt "};+
−
  \end{tikzpicture}+
−
\end{center}+
−
+
−
+
−
\bigskip\bigskip+
−
\subsubsection*{A Crash-Course for GDB}+
−
+
−
\begin{itemize}+
−
\item \texttt{(l)ist n} -- listing the source file from line +
−
\texttt{n}+
−
\item \texttt{disassemble fun-name}+
−
\item \texttt{run args} -- starts the program, potential +
−
arguments can be given+
−
\item \texttt{(b)reak line-number} -- set break point+
−
\item \texttt{(c)ontinue} -- continue execution until next +
−
breakpoint in a line number+
−
+
−
\item \texttt{x/nxw addr} -- print out \texttt{n} words starting +
−
from address \pcode{addr}, the address could be \code{$esp} +
−
for looking at the content of the stack+
−
\item \texttt{x/nxb addr} -- print out \texttt{n} bytes +
−
\end{itemize}+
−
+
−
 +
−
\bigskip\bigskip \noindent If you want to know more about+
−
buffer overflow attacks, the original Phrack article+
−
``Smashing The Stack For Fun And Profit'' by Elias Levy (also+
−
known as Aleph One) is an engaging read:+
−
+
−
\begin{center}+
−
\url{http://phrack.org/issues/49/14.html}+
−
\end{center} +
−
+
−
\noindent This is an article from 1996 and some parts are+
−
not up-to-date anymore. The article called+
−
``Smashing the Stack in 2010''+
−
+
−
\begin{center}+
−
\url{http://www.mgraziano.info/docs/stsi2010.pdf}+
−
\end{center}+
−
+
−
\noindent updates, as the name says, most information to 2010.+
−
 +
−
\end{document}+
−
+
−
%%% Local Variables: +
−
%%% mode: latex+
−
%%% TeX-master: t+
−
%%% End: +
−