DragonFly BSD
DragonFly commits List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: David Rhodus <drhodus@xxxxxxxxx>
Date: Thu, 11 Dec 2003 09:54:41 -0500

Craig Dooley wrote:

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.


One thing that comes to mind is a lot of the games that have been ported to Unix
will jump and execute functions for entering the registration keys for the software
on the stack and other wired things that OpenBSD's W^X break.

People have been running different types of non-exec stack/heaps for years now
and about every six months a paper is released on how to by-pass the protection.
I personally think spending much time trying to "protect" the ia32 platform is
meaningless, until registers are added to the chip to mark pages as non-executable.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]