updated
authorChristian Urban <christian dot urban at kcl dot ac dot uk>
Tue, 11 Oct 2016 15:14:59 +0100
changeset 477 b2c5a721f360
parent 476 cd82c24373cd
child 478 6b7849a12d98
updated
handouts/ho03.pdf
handouts/ho03.tex
progs/README
slides/slides03.pdf
Binary file handouts/ho03.pdf has changed
--- a/handouts/ho03.tex	Tue Oct 11 14:22:37 2016 +0100
+++ b/handouts/ho03.tex	Tue Oct 11 15:14:59 2016 +0100
@@ -64,7 +64,7 @@
 (whereby the absolute numbers of attacks grow each year). So you can
 see buffer overflow attacks are very relevant today. For example, very
 recently (February 2016) a buffer overflow attack was discovered in the glibc
-library:\footnote{\url{http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/}}
+library:\footnote{See \url{goo.gl/De2mA8}}
 
 \begin{quote}\it
 ``Since 2008, vulnerability has left apps and hardware open to remote
@@ -143,9 +143,11 @@
 are 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.
- 
+
+\begin{minipage}{\textwidth}
 \lstinputlisting[language=C]{../progs/example1.c} 
- 
+\end{minipage}
+
 \noindent The \code{main} function calls in Line 7 the
 function \code{foo} with three arguments. \code{Foo} creates
 two (local) buffers, but does not do anything interesting with
@@ -571,7 +573,7 @@
   20 copies the (too large) string into the buffer.\label{C3}}
 \end{figure}
 
-By the way you might naw have the question how do attackers
+By the way you might now have the question how do attackers
 find out about vulnerable systems in the first place? Well,
 the automated version uses \emph{fuzzers}, which throw
 randomly generated user input at applications and observe the
@@ -631,7 +633,7 @@
 \lstinputlisting[language=C]{../progs/C5.c}
 
 \noindent Here the programmer actually tried to take extra
-care to not fall pray to a buffer overflow attack, but in the
+care to not fall prey to a buffer overflow attack, but in the
 process made the program susceptible to a format string
 attack. Clearly the \pcode{printf} function in Line 7 contains
 now an explicit format string, but because the commandline
@@ -843,7 +845,7 @@
 \begin{itemize}
 \item \texttt{(l)ist n} -- lists the source file from line 
 \texttt{n}, the number can be omitted 
-\item \texttt{disassemble fun-name} -- show the assembly code 
+\item \texttt{disassemble fun-name} -- shows the assembly code 
 of a function
 \item \texttt{info registers} -- prints out the current 
 content of all registers
--- a/progs/README	Tue Oct 11 14:22:37 2016 +0100
+++ b/progs/README	Tue Oct 11 15:14:59 2016 +0100
@@ -19,7 +19,11 @@
 
   emacs -nw ...file....     (is also an alias)
 
-  gcc -O file file.c
+Compiler
+
+  gcc -O0 -o file file.c
+
+Backtick is key §/±.
 
 C0.c
 ====
Binary file slides/slides03.pdf has changed