Paul Starzetz wrote:
Crispin Cowan wrote:
It is not very hard to mmap the libc code as non-executable are into
main memory. After the regular programm code jumps into some libc
function, we can check in the gp() handler if the gp fault resulted from
jumping into the libc area by a
Crispin Cowan wrote:
I presume that what you're doing here is to mark the library pages
non-executable, and then make them executable when you get a page fault due to
some code trying to make a library call. If so, how do you distinguish between
legitmate calls into the library, and bogus
Crispin Cowan wrote:
It is not very hard to mmap the libc code as non-executable are into
main memory. After the regular programm code jumps into some libc
function, we can check in the gp() handler if the gp fault resulted from
jumping into the libc area by a ret (the target address
Thomas Dullien wrote:
It would appearat first glance that RSX uses the same technique as PAX.
Naturally, the PAX and RSX teams should confer to make a definitive
statement on similarities and differences.
Just for the record, the technique bears no similarity. PAX provides
real,
Paul Starzetz wrote:
One don't even need code in the libc. There may also be code in regular
code 'segments' mmapped from the binary valuable for jumping into them.
True. libc is just the common point of reference, because nearly all programs
link to it, so it's assured to be there.
Paul Starzetz wrote:
Hi folks,
I´m announcing a novell Linux kernel security module implementing
non-exec stack and non-exec heap. I think this is the first Linux module
providing non-exec heap areas.
It's not the first. This Oct. 28/2000 Bugtraq post
