Re: cvs commit: src/contrib/gcc protector.c protector.h Makefile.in calls.c combine.c cse.c explow.c expr.c flags.h function.c gcse.c integrate.c libgcc2.c loop.c optabs.c reload1.c toplev.c src/gnu/usr.bin/cc/cc_int Makefile

[Craig Dooley <cd5697@xxxxxxxxxx>]

Yes, you can still put stuff on the heap and jump there, and you can
still smash the stack if you're lucky.  OpenBSD W^X just plays games
with Intel segmentation, but can still be used to do wierd things, such
as change the stack, and the return address to libc exec if you could
figure it out.  AMD64 has non-executable page protections, and this
should help, but a canary still provided more protection than nothing.

-Craig

On Thu, Dec 11, 2003 at 11:53:06AM +0100, Jeroen Ruigrok/asmodai wrote:
> -On [20031211 09:52], Matthew Dillon (dillon@xxxxxxxxxxxxxxxxxxxx) wrote:
> >    huh?  I don't think I understood a single word of this posting (!) :-)
> 
> As far as I understand it:
> 
> With Propolice you only disable smashing the stack.  What Propolice and
> StackGuard and similar protections do is add a 'canary' (informer/decoy)
> value just before the return addresses on the run-time stack.  Propolice
> and StackGuard add additional code in your binary which then checks if
> the canary value is present or not.  If it is not a buffer overflow has
> occured.
> 
> Thing is that SEBP or SEIP still is available before or after the canary
> value.  You can place shellcode on the heap and just jump there.
> 
> Hence OpenBSD also implemented W^X (Write XOR eXecutable).  This also
> makes sure that memory get fine-grained permissions.  Which thus limits
> executing in the stack and heap.
> 
> This is at least my understanding, I could of course be way off with my
> interpretation.
> 
> -- 
> Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
> PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
> http://www.tendra.org/   | http://diary.in-nomine.org/
> Yet each man kills the thing he loves...

-- 
------------------------------------------------------------------------
Craig Dooley                                            craig@xxxxxxxxxx
------------------------------------------------------------------------