Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Announcing RSX - non exec stack/heap module
From: Paul Starzetz <paul () starzetz de>
Date: Thu, 07 Jun 2001 19:37:16 +0200

Crispin Cowan wrote:

It's not the first.  This Oct. 28/2000 Bugtraq post
http://www.securityfocus.com/archive/1/141901 announces "PAX"
http://pageexec.virtualave.net/ which also provides a non-executable heap
segment.

I must have missed article. Thx for the information.

Summary of my personal view only:

   * non-executable segments do add some security value
   * non-executable segments is argualy an obscurity defense, because
     attacks exploiting overflow vulnerabilities that are stopped by
     non-executable segments can always be re-worked to be "return into
     libc" style attacks that bypass the non-executable segment by pointing
     directly at code in the code segment
   * this obscurity defense arguably has value, because writing
     return-into-libc exploits is hard, and hard to make scriptable,
     because the offsets are fussy

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.
However it is possible to develop a defense agains jumping into libc
code if the performance is not the most important thing.

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 should still be
on the stack) or by a regular call/jmp instruction. Of course this again
doesn't protect against function-pointer overflows but on the other hand
eliminates again 90% of the potential vulnerabilities.

But can there be a 100% protection at all?

sincerely,

Paul Starzetz


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault