Computer Security
Coursework Exercise CW3
Software Security
The goal of this coursework is to gain practical experience with attacks that
exploit software vulnerabilities, in particular buffer overflows. A buffer overflow
occurs when a program attempts to write data beyond the bound of a fixed-
length buffer – this can be exploited to alter the flow of the program, and even
execute arbitrary code.
You are given five exploitable programs, which are installed with in the
virtual machines provided for this coursework. These may be found in the
/task{1-5}/ directories on the virtual machine, with setuid for a respective
user set. In each case, a secret should be extracted by exploiting the program
in some way, by supplying it maliciously crafted inputs, either to spawn a shell,
or extract the secret directly.
1 Virtual Machine Layout
In this coursework, you have three virtual machine scripts available to you:
lestrade, watson, and sherlock. Each of these scripts can be found in
/afs/inf.ed.ac.uk/group/teaching/compsec/cw3/, and each serves a differ-
ent purpose:
• lestrade: This is a graphical virtual machine for working in, similar to
coursework 2. It provides a basic GNOME environment for doing the
coursework in.
• watson: This is a terminal-only virtual machine, designed primarily for
remote use. As this coursework has no requirement for UI-driven pro-
grams, you may find it easier to work this, potentially more responsive
environment.
• sherlock: Sherlock doesn’t like doing as he’s told, but is quick to judge
and critique the works of others. Sherlock is an automarker for
this coursework. If your submission is consistently accepted by this
automarker, it will be marked correct. On the flip side, as the automarker
is available, solutions not satisfying it will at best considered partially
correct. Note that only one VM can access your files at a time –
to run sherlock, you need to first shut down your work VM!
Both lestrade and watson optionally take a port as an argument – the
VMs ssh port is forwarded to this port on localhost, allowing you to access it
1
via ssh, including copying files from and to the VM.
In order to allow these attacks to be practically and reproducibly executed,
address space layout randomisation (ASLR) has been disabled in the VMs,
ensuring that in each execution, the same parts of a program get assigned to a
consistent memory location.
For lestrade and watson, your username and password are both student, and
you have root access via sudo. Be cautious with how you use it, however, as you
will not have root access on sherlock, and we take care that it is not directly
exploitable, and for testing purposes only! All work in your home directory is
saved in the disk image cshome-cw3.qcow2, which you will be asked to submit
at the end of the coursework. Anything outside of your home will reset with
the VM.
Templates On first starting the VM, templates for each of the exercise sub-
missions should be found in your home directory. Each task has it’s own sub-
directory for you to work in, and contains a script attack.sh. This script will
be executed by the automarker, and should output the secret to its stdout.
Beyond this, you are free to use what you want – provided the tools are prein-
stalled on the VM. This includes using your own compiled binaries if you wish,
although you will not get partial marks if we can’t see the source! Notable tools
installed include netcat (nc), and gdb.
Some of the template scripts include a part using the env command to clear
the environment. This is to ensure the environment the automarker runs the
attack in, and the environment you test it in are the same. Take care to also
make this consistent with your gdb environment! If you remove this part, you
do so at your own peril, and you may experience an attack that works fine for
you being turned down by the automarker.
2 Shellcode
In task 3 you will have to deploy some shellcode, and while we do not ask you to
come up with this yourself, we will briefly elaborate what this code does. These
are x86 instructions, that, when executed, have the same affect as executing the
following C function:
i n t main ( ) {
char ∗name [ 2 ] ;
name [ 0 ] = "/ bin / sh " ;
name [ 1 ] = NULL;
s e t r e u i d ( ge teu id ( ) , ge t eu id ( ) ) ;
execve (name [ 0 ] , name , NULL) ;
}
This program does two things: First, it sets the current user id the the
effective user ID. This ensures that the shell does not drop privileges when it
is started, i.e. reverting to an unprivileged user. In particular bash does this,
which supplies /bin/sh in our VM. Second, it executes /bin/sh directly.
Good shellcode does not contain NULL bytes, as these will not typically be
copied by C programs – for this reason just compiling the above is usually not
2
sufficient. We provide the below shellcode, and in task 3, this is already available
in the task template.
/∗ geteu id ( ) ∗/
"\ x6a\x31 " // push $0x31 ;
"\ x58 " // pop %eax ;
"\ x99 " // c l t d ;
"\ xcd\x80 " // i n t $0x80 ;
/∗ s e t r e u i d ( ) ∗/
"\ x89\xc3 " // mov %eax , %ebx ;
"\ x89\xc1 " // mov %eax , %ecx ;
"\ x6a\x46 " // push $0x46 ;
"\ x58 " // pop %eax ;
"\ xcd\x80 " // i n t $0x80 ;
/∗ execve ( "/ bin / sh " , 0 , 0) ∗/
"\ xb0\x0b " // mov $0x0b , %a l ;
"\ x52 " // push %edx ;
"\ x68n/sh " // push $0x68732f6e ;
"\ x68// b i " // push $0x69622 f2 f ;
"\ x89\xe3 " // mov %esp , %ebx ;
"\ x89\xd1 " // mov %edx , %ecx
"\ xcd\x80 " // i n t $0x80 ;
3 The Vulnerable Programs
Task 1 This is just for warming up. This program is fund in /task1/vuln,
and waits for a password (stored in /task1/password.txt), and if the correct
password is entered by the user, it prints the secret. The program has a buffer
overflow vulnerability, making it possible – without knowing the password – to
allow it to log in. Important: the real password will be changed for marking!
The pidgeon and rooster various will not.
Task 2 This program takes the user’s name as a command line argument,
copies it to a buffer, and then welcomes the user. This program is vulnerable
to a buffer overflow attack. Your attack script should call this program with
a carefully crafted argument, such that it overwrites the return address on the
stack, and returns to the read_secret function, instead of back to main. Stack
canaries are not enabled in this task.
Task 3 For this program, there is no helpful function for extracting informa-
tion, meaning you must inject your own shellcode, jump to this on-stack instead
of a pre-existing function. Furthermore, from this task on, the program is com-
piled with GCC’s stack protection enabled, which inserts stack canaries after
the return address on stack. Your attack script will input a malicious argument,
such that the program loads and jumps into your shellcode, while avoiding these
canaries. The template provided already contains some boilerplate code to then
read the secret from this shell.
3
Task 4 This program functions similarly to the previous script, however ex-
ecution of code on the stack has been disabled! Instead, you should perform a
return-to-libc attack. In particular, you should overwrite the stack such that
execution returns into the libc function system(), and make this function be-
lieve it received "/bin/sh" as an argument. For this purpose, you’ll need to
find the locations of these in memory, and analyse how calls to system() would
ordinarily function. Your program should use this return technique to spawn a
shell – in this case the program itself forces that the real uid is set, ensuring the
shell will be as the task4 user.
Task 5 This task does not have a binary to directly exploit, but instead runs
a small TCP server on the local port 4040. This program accepts requests the
read sections of a secret file, but denies requests to some parts. It is however
vulnerable to an attack allowing you to read this part too! Your attack script
should connect to the server using netcat, and submit a malicious request, ex-
tracting the secret string.
4 Submission Instructions
Once you have completed your exploits, you should first test them against the
automarker! Run /afs/inf.ed.ac.uk/group/teaching/compsec/cw3/sherlock,
which will give you a list of whether you passed each respective task. If you are
satisfied, and want to submit, run
submit cs 3 ~/cshome-cw3.qcow2
The submission deadline is 27th March, at 16:00. Please be aware: The
actual marking will generate new random secrets. Your secrets must therefore
come from executing the attack, and not, for instance, reading them with root
and simply echoing them!
A Running on non DICE Machines
While we do not provide any support for non-DICE machines, the setup given
is in theory usable, with minor tweaks, on any Linux distro. We list here what
is necessary to get the coursework running on a standard Ubuntu installation,
other operating systems may be similar.
1. Copy the /afs/inf.ed.ac.uk/group/teaching/compsec/cw3 directory
to your local machine.
2. Install the qemu-kvm and vinagre packages.
3. Add your user to the kvm group: sudo usermod -aG kvm $(whoami)
4. Modify cw3/qemu.env, setting QEMU=qemu-system-x86_64.
Note: For other environments, this may differ. It should point to the
QEMU executable.
5. Reboot to have permission changes on /dev/kvm, and group changes take
effect.
4
6. Run the VM scripts locally.
5