full-disclosure - no-NX paper announcement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1128585323.2960.21.camel@laptopd505.fenrus.org>
Date: Thu Oct  6 13:16:57 2005
From: arjan at infradead.org (Arjan van de Ven)
Subject: no-NX paper announcement

On Tue, 2005-10-04 at 13:43 +0200, Sebastian Krahmer wrote:
> Hi,
> 
> A new paper describing NX technology and its limitations can be
> found at http://www.suse.de/~krahmer/no-nx.pdf
> It contains in depth discussion and sample code for the Hammer/Linux 
> platform, analyzes the weaknesses and discusses countermeasures.

An interesting paper; however I'm sort of missing some "and how linux
prevents these/makes these harder, now and in the future".

Examples:
*) glibc nowadays has a lot of checks in the malloc/free code that make
the traditional double free exploit (and the heap exploits that use the
same technique) not feasible. This is present in at least Fedora Core 3
and 4 and Red Hat Enterprise Linux 4; I'd be surprised if it also isn't
in SLES9 since it has been in the upstream glibc for quite a while
*) glibc nowadays prevents format string exploits (assuming you pass
-D_FORTIFY_SOURCE=2 as preprocessor directive)
(again present in FC3/FC4/RHEL4)
*) The kernel.org kernel nowadays includes address space randomization
by default. While not perfect and fully complete, it's there and better
than nothing
(FC3/FC4/RHEL4 randomize more aggressive than this) 
*) the glibc/gcc/binutils toolchain has support for PIE binaries,
basically relocatable binaries so that the binary location can be
randomized by the previous feature as well; this in order to make it
harder to do ret2binary
*) glibc/binutils have a feature to mark the GOT/PLT read only after
linking (called "relro"), to make it harder for exploits to much with
these (eg they need to first re-mprotect them, which means they need
full code execution state first at which point the GOT/PLT are boring
anyway)
*) gcc cvs now has -fstack-protector; basically a gcc 4.x port of the
propolice technique that tries hard to protect the return address on the
stack
*) gcc/glibc allow cheap static buffer checking with -D_FORTIFY_SOURCE=2


Greetings,
   Arjan van de Ven