Lab: Stack Overflow

Short Description

Full code for the entire lab is located in the Buffer directory.

Goals

• Gain first-hand experience with buffer-overflow.

The Lab

1. Setup
   • Download the Seed-Base.ova image.
   • Login as seed, password dees.
     • This account has sudo privileges.
   • The files you need are in the directory BufferLab.
     • Open at least one terminal and change to that directory.
   • Turn off kernel address space randomization
     • This will allow us an easier time with this exploit.
     • When we do this the address of the buffer will not change each time we run the program.
     • After we finish the lab, you can turn this back on and try to guess the base address.
     • Run

     • $ sudo sysctl -w kernel.randomize_va_space=0
               

   • Note, in the lab you also replace /bin/sh with /bin/zsh. This is a less secure version of a shell.
2. Malicious Code
   • Remember, the attack involves adding some malicious code to the stack.
     • We need this code to be in assembly language.
     • The lab provides this code for you.
   • Look at call_shellcode.c.
     • We are working in the 32 bit environment for this lab.
     • This contains the assembly code to start a shell in both 32 bit and 64 bit environments.
     • Note in the c preprocessor
       • #if is an if statement.
       • It check to see if the compiler is working in 32 or 64 bit mode.
       • The code in the else clause is the 32 bit code. (You will need this later).
       • Line 26 makes a copy of the "string" or code on the stack
       • Line 27 casts the code on the stack to an executable function, which line 29 calls.
     • Note, when this code was compiled the following flags were used
       • -z execstack
         • This allows code on the stack to be executed.
         • By default this is not the case on modern linux machines.
       • -m32
         • This compiles the code for 32 bit execution.
   • run a32.out.
     • Note, this gives you a shell.
     • Exit the shell.
     • Change this so it is setuid
       • sudo chown root a32.out
       • sudo chmod u+s a32.out
     • Now run the code again and convince yourself you have a root shell.
   • From this section, you need the assembly code that will run a shell, and you need to convince yourself that this code can be run.
3. Exploitable Code
   • Look at stack.c
     • The function bof contains the buffer overflow.
       • buffer is declared to be 100 characters.
       • the strcpy copies whatever is passed into it into this buffer.
     • Looking in main, we see the argument is up to 517 characters.
       • This is input from the file badfile
     • This was compiled
       • All versions with permission to execute on the stack.
       • One version L1-dbg with symbolic debugging information in the code. This allows us to use gdb.
       • One version L1-dbg with the buffer size at 100
       • Another version L2-dbg with a buffer size somewhere between 10 and 200.
     • Not all three versions are setuid.
   • Our goal is to place a string in badfile that will allow us to overflow the buffer.
   • Make badfile
     • echo "Hello world!" > badfile
   • Now explore memory locations inside of the debuggable version.
   • gdb
     • gdb is the gnu debugger
     • When code is compiled with -g, you can examine the code while it runs using the debugger.
     • Our goal is to find the base address of the array
     • And the location of the frame pointer.
       • Intel assembly, $ebp is the frame pointer.
       • It holds the address of where the frame begins.
       • And the return address is either $ebp+4 (32 bit) or $ebp+8 (64 bit)
     • gdb stack-L1-dbg
       • Will start the debugger.
     • b bof
       • Will set a breakpoint so the debugger will stop in the function bof
     • run will run the program.
       • Notice it stops on line 16, just before the function starts.
       • Type next to move to the next instruction.
       • Notice we are now on line 20.
       • Type list to see the actual code.
       • where will let you see the state.
       • p or print is the command to print.
       • p str will print the argument
       • p buffer will print the contents of the buffer.
       • Step once to get to line 20 and print again.
       collect the data we need.
       • p &buffer will print the base address of the buffer.
       • p $ebp will print the value of the frame pointer, (top of the frame)
       • In my case I got

         • # gdb-peda p &buffer
           #8 = (char (*)[100]) 0xffffcb1c
           # gdb-peda p $ebp
           #9 = (void *) 0xffffcb88
                    

         • Notice the address of the character array is 100 less than the frame pointer (this is good)
       • So I asked gdb to compute the offset

         • # gdb-peda p /d 0xffffcb88 - 0xffffcb1c
           #10 = 108
                    

         • So the frame pointer is 108 bytes away from the base address of the array
         • This is because other information is stuck at the top of the frame.
       • Record the two pieces addresses and the size from above.
       • Use quit to exit gdb.
       • Remember, we might not have a debuggable version of the code. Try this with stack-L1.
4. editors, we need one now.
   • joe, nano, vi/vim are the text editors on this system.
   • kate and gedit are the gui editors.
5. Some Python
   • The lab provides a tool for creating badfile
   • But this is written in Python.
   • And we need just a little background.
   • Edit the file play.py
     • Since this is a script, we need to tell the kernel how to run the script.
     • This is done by placing a structured comment as the first line of the file.
     • It is in the form
       • the pound sign #
       • An explanation mark !
       • The path to the interpreter /usr/bin/python3
     • Place #!/usr/bin/python3 as the first line in your file.
     • put the following in the file

       #!/usr/bin/python3
       ary = ['H','e','l','l','o',' ','W','o','r','l','d','!']
       
       print(ary)
       print(ary[:3])
       print(ary[2:4])
       print(ary[4:]) 

     • Save this.
     • Make it executable by typing chmod u+x play.py
     • run it play.py
     • Note the use of indexing in python.
     • Add the following

       ary[2:4] = "ven"
       print(ary) 

     • Save it an run it again.
     • Add the following

       i = 0
       while i < len(ary) :
           print (i, ary[i]);
           i += 1 

     • Note the while loop in python.
6. Build the input string.
   • The lab provides a python program to build the string exploit.
   • Start by making a working copy: cp exploit.py step1.py
   • Edit step1.py and add the malicious code
     • In place of the shellcode value give, copy the 32 bit code from call_shellcode.c
   • Note on line 13, this builds an array and fills it with 0x90 (nop).
   • On line 17, put

     517-len(shellcode)

     why?
   • Remember, we decided that the return address was stored at 0xffffcb88+4
     • Let's set ret to be 0xffffcb88 plus 100 more plus some small multiple of 4, say 120
       • We need to make sure this address doesn't contain 00 on a byte boundary, or this will kill the strcpy.
       • You may need to play with this value some.
     • This gives us a little room for error.
     • And that should be filled with nop anyway, so that is good.
   • Remember the offset from the beginning of the array to the frame pointer was 108, so the return address will be at 112 (108+4), put that in offset
   • Run step1.py
   • Look at the file by typing od -x badfile
7. You should now be able to run stack-L1 and get a root shell.
8. stack-L2
   • has a different buffer size. (but less than 200)
   • And has no debugging information.
   • Can you break it?
   • Hint: Flood with 0 - some size with a return address and try it again.