# HG changeset patch # User Christian Urban # Date 1414017482 -3600 # Node ID 9bc912fcedb61f604cdc2d0bf94e77901a208b38 # Parent e272713e34ffb31cf1eb52cb2852e68ec1079eb2 updated diff -r e272713e34ff -r 9bc912fcedb6 handouts/ho03.tex --- a/handouts/ho03.tex Tue Oct 21 12:42:19 2014 +0100 +++ b/handouts/ho03.tex Wed Oct 22 23:38:02 2014 +0100 @@ -7,6 +7,29 @@ \section*{Handout 3 (Buffer Overflow Attacks)} +\begin{center} +\begin{tikzpicture} +\begin{axis}[xlabel={\pcode{a}s},ylabel={time in secs}, + enlargelimits=false, + xtick={0,5,...,30}, + xmax=30, + ymax=35, + ytick={0,5,...,30}, + scaled ticks=false, + axis lines=left, + width=5cm, + height=5cm, + legend entries={Python,Ruby}, + legend pos=north west, + legend cell align=left] +\addplot[blue,mark=*, mark options={fill=white}] + table {re-python.data}; +\addplot[brown,mark=pentagon*, mark options={fill=white}] + table {re-ruby.data}; +\end{axis} +\end{tikzpicture} +\end{center} + By far the most popular attack method on computers are buffer overflow attacks or variations thereof. The first Internet worm (Morris) exploited exactly such an attack. The popularity diff -r e272713e34ff -r 9bc912fcedb6 handouts/ho04.pdf Binary file handouts/ho04.pdf has changed diff -r e272713e34ff -r 9bc912fcedb6 handouts/ho04.tex --- a/handouts/ho04.tex Tue Oct 21 12:42:19 2014 +0100 +++ b/handouts/ho04.tex Wed Oct 22 23:38:02 2014 +0100 @@ -51,14 +51,15 @@ There are already some special rules for directories and links. If the execute attribute of a directory is \emph{not} set, then one cannot change into the directory and one cannot -access any file inside it. If the write attribute is not set, -then one can change existing files (provide they are -changeable), but one cannot create new files. If the read -attribute is not set, one cannot search inside the directory -(\pcode{ls -la} does not work) but one can access an existing -file, provided one knows its name. Links to files never depend -on the permission of the link, but the file they are pointing -to. +access any file inside it. If the write attribute is +\emph{not} set, then one can change existing files (provide +they are changeable), but one cannot create new files. If the +read attribute is \emph{not} set, one cannot search inside the +directory (\pcode{ls -la} does not work) but one can access an +existing file, provided one knows its name. Links to files +never depend on the permission of the link, but the file they +are pointing to. Otherwise one could easily change access +rights to files. While the above might sound already moderately complicated, the real complications with Unix-style file permissions @@ -95,12 +96,12 @@ attribute set on my bog-standard Mac OSX system (including the program \pcode{/usr/bin/login} for example). The problem is that if there is a security problem with only one of them, be -it a buffer overflow for example, then malicious users -can gain root access (and for outside attackers it is much -easier to take over a system). Unfortunately it is rather easy -to make errors since the handling of elevating and dropping -access rights in such programs rests entirely with the -programmer. +it a buffer overflow for example, then malicious users can +gain root access (and for outside attackers it is much easier +to take over a system). Unfortunately it is rather easy to +cause a security problem since the handling of elevating and +dropping access rights in such programs rests entirely with +the programmer. The fundamental idea behind the setuid attribute is that a file will be able to run not with the callers access rights, @@ -158,18 +159,82 @@ identity should go back to the real identity. -Despite these complicated semantics, Unix-style access control +Despite this complicated semantics, Unix-style access control is of no use in a number of situations. For example it cannot be used to exclude some subset of people, but otherwise have files readable by everybody else (say you want to restrict access to a file such that your office mates cannot access a file). You could try setting the group of the file to this subset and then restrict access accordingly. But this does not -help, because users can drop membership in groups. +help, because users can drop membership in groups. If one +needs such fine-grained control over who can access a file, +one needs more powerful \emph{mandatory access controls} +as described next. + \subsubsection*{Secrecy and Integrity} +Often you need to keep information secret within a system or +organisation, or secret to the ``outside world''. An example +would be to keep information secret such that insiders cannot +leak information to competitors. A very good instance of such +an access control system is the secrecy levels used in the +military. There you distinguish four secrecy levels: +\begin{itemize} +\item top secret +\item secret +\item confidential +\item unclassified +\end{itemize} + +The idea is that the secrets classified as top-secret are most +closely guarded and only accessible to people who have a +special clearance. The unclassified category is the lowest +level not needing any clearance. While the idea behind these +security levels is quite straightforward, there are some +interesting implications for when you want to realise such a +system. To begin the access control needs to be +\emph{mandatory} as opposed to \emph{discretionary}. With +discretionary access control, the users can decide how to +restrict or grant access to resources. With mandatory access +control, the access to resources is enforced ``system-wide'' +and cannot be controlled by the user. There are also some +interesting rules for reading and writing an object that +need to be enforced: + + +\begin{itemize} +\item {\bf Read Rule}: a principal $P$ can read an object $O$ +provided $P$'s security level is at least as high as $O$'s + +\item {\bf Write Rule}: a principal $P$ can write an object $O$ +provided $O$'s security level is at least as high as $P$'s +\end{itemize} + +\noindent The first rule says that a principal with secret +clearance can read secret documents or lower, but not +documents classified top-secret. The second rule for writing +needs to be the other way around: someone with secret +clearance can write secret or top-secret documents---no +information is leaked. In contrast it cannot write +confidential documents, because then information can be leaked +to lower levels. These rules about enforcing secrecy with +mult-level clearances is often called \emph{Bell/LaPudela} +model, named after two people who studied such systems. + +A problem with this access control system is when two people +want to talk to each other but having different security +clearances, say secret and confidential. In these situations, +the people with the higher clearance have to lower their +security level and are not allowed to take any document +from the higher level with them (otherwise again information +could be leaked). In actual systems this might mean that +people need to log out and log into the system again---this +time with credentials for the lower level. + +While secrecy is one property you often want to enforce, +integrity is another. This property ensures that no \subsubsection*{Further Information} diff -r e272713e34ff -r 9bc912fcedb6 hws/hw03.pdf Binary file hws/hw03.pdf has changed diff -r e272713e34ff -r 9bc912fcedb6 hws/hw03.tex --- a/hws/hw03.tex Tue Oct 21 12:42:19 2014 +0100 +++ b/hws/hw03.tex Wed Oct 22 23:38:02 2014 +0100 @@ -19,6 +19,9 @@ \item Why is it crucuial for a buffer overflow attack that the stack grows from higher addresses to lower ones? +\item If the attacker uses a buffer overflow attack in order to +inject code, why can this code not contain any zero bytes? + \item How does a stack canary help with preventing a buffer-overflow attack? diff -r e272713e34ff -r 9bc912fcedb6 slides/slides05.pdf Binary file slides/slides05.pdf has changed diff -r e272713e34ff -r 9bc912fcedb6 slides/slides05.tex --- a/slides/slides05.tex Tue Oct 21 12:42:19 2014 +0100 +++ b/slides/slides05.tex Wed Oct 22 23:38:02 2014 +0100 @@ -565,6 +565,13 @@ \end{frame} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\begin{frame}[c] + + +\end{frame} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + \end{document}