Help to get started!

[dprotti at flowgate.net (Duilio Protti)]

Reading my previous post, I was thinking that probably on a quick view
on it, somebody without knowledge of the way SSP works, cannot
understand why the exploit could work with my version, where the
overflow is made whithin mystrcpy() instead of read().

That guy could argue "anyway, the overflow occurs on main's local buf,
so the exploit take control on main's return. Doesn't matter if buf was
overflowed from mystrcpy() or from read() or whatever".

SSP not just protects local buffers, but also function arguments. It
does this copying them to local variables on function entry, and these
local variables are used on the function's body instead of the passed
buffers. In short, SSP make the compiler pass buffers by value, not by
reference.

With this in mind, you can see why read()'s version doesn't work when
SSP is present. Because Gentoo libc is SSP-enabled, read() function
doesn't overflow main's buf, but his local copy of main's buf, and the
overflow is detected on read()'s return.


Bye,
Duilio Protti.

SSP on Gentoo: http://www.gentoo.org/proj/en/hardened/propolice.xml
How to bypass SSP:
http://www.coresecurity.com/files/files/11/StackguardPaper.pdf


> In fact, I have tried vuln1_2 on Gentoo Linux, and it fails to exploit
> vuln1.c from tutorial. The problem arises because of the Smash Stack
> Protector with which libc is compiled in Gentoo. Changing the code of
> vuln1.c:
>
> char buf[64];
> ....
> if(read(peersock, buf, 4096) == -1) {
>     perror("read");
>     return(1);
> }
>
> to another one which does not overflow inside of the libc's read()
> function:
>
> char buf[64];
> char largebuf[4096];
> ....
> if(read(peersock, largebuf, 4096) == -1) {
>     perror("read");
>     return(1);
> }
> mystrcpy(buf, largebuf);
>
> where mystrcpy() is defined by us on the same file (say vuln2.c). Then,
> when running vuln2 (compiled of course without ssp) the overflow occurs
> on mystrcpy(), which doesn't check the stack on return. This way, I have
> successfully exploited vuln2 using vuln1_2 from the tutorial, defining a
> 'Gentoo Linux' target with ESP adjusted to 0xbffff220.
>
> Probably would be good to change vuln1.c on tutorial this way, to evade
> compiled protections found on many systems.
>
>
> Bye,
> Duilio Protti.