PaX () The Guaranteed End of Arbitrary Code Execution

PaXPaX(http://(http://

pageexec.virtualave.net)pageexec.virtualave.net)

The Guaranteed End of The Guaranteed End of Arbitrary Code ExecutionArbitrary Code Execution

Who am I?Who am I?

Brad SpenglerBrad Spengler The only grsecurity developerThe only grsecurity developer NOT a PaX developerNOT a PaX developer Computer Engineering major, Computer Engineering major,

Mathematics minorMathematics minor

What is PaX?What is PaX?

Quite simply: the greatest advance in Quite simply: the greatest advance in system security in over a decade system security in over a decade that you’ve never heard ofthat you’ve never heard of

Less simply: It provides non-Less simply: It provides non-executable memory pages and full executable memory pages and full address space layout randomization address space layout randomization (ASLR) for a wide variety of (ASLR) for a wide variety of architectures.architectures.

OutlineOutline

PaX “lecture”PaX “lecture” SEGMEXECSEGMEXEC PAGEEXECPAGEEXEC KERNEXECKERNEXEC ASLRASLR

RANDMMAPRANDMMAP RANDEXECRANDEXEC ET_DYNET_DYN RANDKSTACKRANDKSTACK

Outline (cont.)Outline (cont.)

How grsecurity is involved in PaX’s How grsecurity is involved in PaX’s strategystrategy

Factual comparison with OpenBSD’s W^XFactual comparison with OpenBSD’s W^X ASLR comparisonASLR comparison Any guarantees?Any guarantees? The “subtle concept” of mprotectThe “subtle concept” of mprotect

Factual comparison with Exec ShieldFactual comparison with Exec Shield ASLR comparisonASLR comparison Any guarantees?Any guarantees? MprotectMprotect

PaX - SEGMEXECPaX - SEGMEXEC

SEGMEXEC is PaX’s implementation SEGMEXEC is PaX’s implementation of per-page non-executable user of per-page non-executable user pages using the segmentation logic pages using the segmentation logic of IA-32 (Intel x86 architecture) and of IA-32 (Intel x86 architecture) and virtual memory area mirroring virtual memory area mirroring (developed by PaX).(developed by PaX).

PaX – SEGMEXEC (cont.)PaX – SEGMEXEC (cont.)

The segmentation logic is fairly The segmentation logic is fairly straightforward:straightforward: Data Segment (DS)Data Segment (DS) Code Segment (CS)Code Segment (CS)

There exist these two segments for user pages There exist these two segments for user pages as well as kernel pages.as well as kernel pages.

PaX splits the address space down the middle: PaX splits the address space down the middle: the bottom half for data, the top for code.the bottom half for data, the top for code.

Segmentation is a “window” into the address Segmentation is a “window” into the address spacespace

No performance hitNo performance hit


UserCode & Data

Segments

3GB

Without SEGMEXEC

UserCode

Segment

1.5GB

UserData

Segment

1.5GB

With SEGMEXEC


PaX’s VMA mirroring involves duplicating PaX’s VMA mirroring involves duplicating every executable page in the lower half every executable page in the lower half of the address space into the upper half.of the address space into the upper half.

Instruction fetch attempts at addresses Instruction fetch attempts at addresses located in the data segment that don’t located in the data segment that don’t have any code located at its mirrored have any code located at its mirrored address will cause a page fault. PaX address will cause a page fault. PaX handles this page fault and kills the task.handles this page fault and kills the task.


08048000-0804c000 r-xp /home/spender/cat0804c000-0804d000 rw-p /home/spender/cat0804d000-08079000 rw-p 20000000-20014000 r-xp /lib/ld-2.3.2.so20014000-20015000 rw-p /lib/ld-2.3.2.so20015000-20016000 rw-p 2001e000-20145000 r-xp /lib/libc-2.3.2.so20145000-2014a000 rw-p /lib/libc-2.3.2.so2014a000-2014c000 rw-p 2014c000-202d1000 r--p /usr/lib/locale/locale-archive5ffff000-60000000 rw-p 68048000-6804c000 r-xp /home/spender/cat80000000-80014000 r-xp /lib/ld-2.3.2.so8001e000-80145000 r-xp /lib/libc-2.3.2.so

08048000-0804c000 r-xp /home/spender/cat0804c000-0804d000 rw-p /home/spender/cat0804d000-08073000 rw-p 40000000-40014000 r-xp /lib/ld-2.3.2.so40014000-40015000 rw-p /lib/ld-2.3.2.so40015000-40016000 rw-p 4001e000-40145000 r-xp /lib/libc-2.3.2.so40145000-4014a000 rw-p /lib/libc-2.3.2.so4014a000-4014c000 rw-p 4014c000-402d1000 r--p /usr/lib/locale/locale-archivebfffe000-c0000000 rw-p

Without SEGMEXEC

With SEGMEXEC


Instruction fetch attempt at 0x08049000

Segmentation logic translates 0x08049000 into 0x68049000

Does 0x68049000 belong to any mapping?

Success

Violation, process is terminated

YES

NO

PaX - PAGEEXECPaX - PAGEEXEC

PAGEEXEC was PaX’s first implementation PAGEEXEC was PaX’s first implementation of non-executable pages.of non-executable pages.

Because of SEGMEXEC, it’s not used Because of SEGMEXEC, it’s not used anymore on x86 (so I won’t discuss the anymore on x86 (so I won’t discuss the implementation).implementation).

Platforms which support the executable bit Platforms which support the executable bit in hardware are implemented under in hardware are implemented under PAGEEXEC (currently alpha, ppc, parisc, PAGEEXEC (currently alpha, ppc, parisc, sparc, sparc64, amd64, and ia64)sparc, sparc64, amd64, and ia64)

PaX - KERNEXECPaX - KERNEXEC

KERNEXEC is PaX’s implementation of KERNEXEC is PaX’s implementation of proper page protection in the kernelproper page protection in the kernel ‘‘const’ finally means read only in the kernelconst’ finally means read only in the kernel Read-only system call tableRead-only system call table Read-only interrupt descriptor table (IDT)Read-only interrupt descriptor table (IDT) Read-only global descriptor table (GDT)Read-only global descriptor table (GDT) Data is non-executableData is non-executable Uses the same concept of segmentation as Uses the same concept of segmentation as

SEGMEXEC SEGMEXEC Cannot co-exist with module support (currently)Cannot co-exist with module support (currently)

PaX - ASLRPaX - ASLR

Full ASLR randomizes the locations of Full ASLR randomizes the locations of the following memory objects:the following memory objects: Executable imageExecutable image Brk-managed heapBrk-managed heap Library imagesLibrary images Mmap-managed heapMmap-managed heap User space stackUser space stack Kernel space stackKernel space stack

PaX – ASLR (cont.)PaX – ASLR (cont.)

Notes on amount of randomization:Notes on amount of randomization: The following values are for 32bit architectures. The following values are for 32bit architectures.

They are larger on 64bit architectures, though They are larger on 64bit architectures, though not twice as large (since they generally don’t not twice as large (since they generally don’t use 64 bits for the address space).use 64 bits for the address space).

Stack – 24 bits (28 bits for argument/environment Stack – 24 bits (28 bits for argument/environment pages)pages)

Mmap – 16 bitsMmap – 16 bits Executable – 16 bitsExecutable – 16 bits Heap – 12 bits (or 24 bits if executable is randomized Heap – 12 bits (or 24 bits if executable is randomized

also)also)


The randomizations applied to each memory The randomizations applied to each memory region are independent of each otherregion are independent of each other Because PaX guarantees no arbitrary code Because PaX guarantees no arbitrary code

execution, exploits will most likely need to execution, exploits will most likely need to access different memory regions.access different memory regions.

So, if the exploit needs access to libraries and So, if the exploit needs access to libraries and the stack, the bits that must be guessed are the the stack, the bits that must be guessed are the sum of the two regions: 40 bits (or 44). The sum of the two regions: 40 bits (or 44). The chance of such an attack succeeding while chance of such an attack succeeding while depending on hard coded addresses is depending on hard coded addresses is effectively zero.effectively zero.

PaX – ASLR (cont.)PaX – ASLR (cont.)08048000-0804c000 r-xp /home/spender/cat0804c000-0804d000 rw-p /home/spender/cat0804d000-08078000 rw-p 4edaa000-4edbe000 r-xp /lib/ld-2.3.2.so4edbe000-4edbf000 rw-p /lib/ld-2.3.2.so4edbf000-4edc0000 rw-p 4edc8000-4eeef000 r-xp /lib/libc-2.3.2.so4eeef000-4eef4000 rw-p /lib/libc-2.3.2.so4eef4000-4eef6000 rw-p4eef6000-4f07b000 r--p /usr/lib/locale/locale-archivebf3dc000-bf3dd000 rw-p

08048000-0804c000 r-xp /home/spender/cat0804c000-0804d000 rw-p /home/spender/cat0804d000-08070000 rw-p43d8c000-43da0000 r-xp /lib/ld-2.3.2.so43da0000-43da1000 rw-p /lib/ld-2.3.2.so43da1000-43da2000 rw-p43daa000-43ed1000 r-xp /lib/libc-2.3.2.so43ed1000-43ed6000 rw-p /lib/libc-2.3.2.so43ed6000-43ed8000 rw-p43ed8000-4405d000 r--p /usr/lib/locale/locale-archiveb54f9000-b54fa000 rw-p

Two runs of a binary with stack, mmap, and heap randomization


RANDKSTACKRANDKSTACK Randomizes the kernel’s stackRandomizes the kernel’s stack Randomized on each system call, so Randomized on each system call, so

info-leaking the randomization is uselessinfo-leaking the randomization is useless Randomizes 5 bits of the stack. Brute Randomizes 5 bits of the stack. Brute

forcing generally shouldn’t be possible, forcing generally shouldn’t be possible, as each attempt will most likely crash as each attempt will most likely crash the kernel.the kernel.


ET_DYNET_DYN Special type of ELF binary (the same used for Special type of ELF binary (the same used for

shared libraries)shared libraries) Position independent code (PIC)Position independent code (PIC) Allows for relocation of the binary at a random Allows for relocation of the binary at a random

locationlocation Needed to achieve Full ASLRNeeded to achieve Full ASLR Requires a recompile and re-link of applicationsRequires a recompile and re-link of applications Adamantix and Hardened Gentoo have Adamantix and Hardened Gentoo have

adopted these changes.adopted these changes.


RANDEXECRANDEXEC Randomizes the placement of code in ET_EXEC binaries.Randomizes the placement of code in ET_EXEC binaries. Uses the same segmentation feature as SEGMEXEC.Uses the same segmentation feature as SEGMEXEC. Code in an ET_EXEC binary is mirrored at a random location. Code in an ET_EXEC binary is mirrored at a random location.

The code still exists as data in the data segment.The code still exists as data in the data segment. When execution of the program enters the binary image, a When execution of the program enters the binary image, a

page fault is raised and analyzed.page fault is raised and analyzed. The analysis checks to see if the entry into the binary image The analysis checks to see if the entry into the binary image

was legitimate or caused by a ret-to-libc style attack. If it was was legitimate or caused by a ret-to-libc style attack. If it was legitimate, execution is redirected into the randomized mirror; legitimate, execution is redirected into the randomized mirror; otherwise, the application is killed.otherwise, the application is killed.

RANDEXEC can cause false positives in certain applications. RANDEXEC can cause false positives in certain applications. Also since it does not randomize data in the binary, it is not a Also since it does not randomize data in the binary, it is not a replacement for ET_DYN. RANDEXEC was developed merely as replacement for ET_DYN. RANDEXEC was developed merely as a proof of concept.a proof of concept.

How grsecurity is involved in How grsecurity is involved in PaX’s strategyPaX’s strategy

To truly achieve the guarantee of no execution of To truly achieve the guarantee of no execution of arbitrary code, grsecurity must be used. The arbitrary code, grsecurity must be used. The ACL/RBAC system or TPE can be used to ensure ACL/RBAC system or TPE can be used to ensure that an attacker can’t create a file with his that an attacker can’t create a file with his payload in it, and mmap that executable via a payload in it, and mmap that executable via a ret-to-libc attack on the process.ret-to-libc attack on the process.

Protection against brute-forcing attacks is also Protection against brute-forcing attacks is also part of PaX’s strategy. This is handled within part of PaX’s strategy. This is handled within grsecurity’s ACL/RBAC system by either denying grsecurity’s ACL/RBAC system by either denying execution of the app for a single user or for execution of the app for a single user or for everyone (depending on whether the process was everyone (depending on whether the process was a network daemon or not).a network daemon or not).

Factual Comparison of PaX and Factual Comparison of PaX and W^XW^X

PaXPaX Guaranteed no execution Guaranteed no execution

of arbitrary codeof arbitrary code 24/28 bit stack 24/28 bit stack

randomizationrandomization 16 bit mmap 16 bit mmap

randomizationrandomization Completely implemented Completely implemented

in the kernel. Can be in the kernel. Can be implemented implemented transparently and retain transparently and retain binary compatibility with binary compatibility with all distributions.all distributions.

W^XW^X No guarantees about No guarantees about

arbitrary code executionarbitrary code execution 14 bit stack 14 bit stack

randomizationrandomization 16 bit mmap 16 bit mmap

randomizationrandomization Required a complete Required a complete

recompilation/re-linking recompilation/re-linking of user space. Broke of user space. Broke binary compatibility with binary compatibility with all previous OpenBSD all previous OpenBSD releases.releases.

Factual Comparison of PaX and Factual Comparison of PaX and W^X (cont.)W^X (cont.)

PaXPaX Cuts usable address Cuts usable address

space in half (though this space in half (though this can be changed if it can be changed if it becomes a problem)becomes a problem)

Two methods for Two methods for randomizing the randomizing the executable base (though executable base (though ET_DYN is the correct ET_DYN is the correct method)method)

Support for non-Support for non-executable and read-only executable and read-only kernel pages on i386kernel pages on i386

W^XW^X More usable address More usable address

space, but fragmentedspace, but fragmented As of the latest release, As of the latest release,

no method for no method for randomizing the randomizing the executable baseexecutable base

No support for non-No support for non-executable or read-only executable or read-only kernel pages on i386kernel pages on i386


PaXPaX Per-system call kernel Per-system call kernel

stack randomizationstack randomization Brk-managed heap Brk-managed heap

randomizationrandomization Ability to enable/disable Ability to enable/disable

all features on a per all features on a per binary basisbinary basis

No read-only No read-only GOT/PLT/.ctors/.dtors GOT/PLT/.ctors/.dtors (yet)(yet)

W^XW^X No kernel stack No kernel stack

randomizationrandomization No brk-managed No brk-managed

heap randomizationheap randomization No method of No method of

toggling features on toggling features on a per binary basisa per binary basis

Read-only Read-only GOT/PLT/.ctors/.dtorGOT/PLT/.ctors/.dtorss


PaXPaX Supports the same user Supports the same user

space features on i386, space features on i386, alpha, ppc, parisc, alpha, ppc, parisc, sparc, sparc64, amd64, sparc, sparc64, amd64, and ia64.and ia64.

Supports a per-page Supports a per-page implementation of non-implementation of non-executable pages on executable pages on ppcppc

W^XW^X Supports the same user Supports the same user

space features on i386, space features on i386, alpha, ppc, parisc, alpha, ppc, parisc, sparc, and sparc64. sparc, and sparc64. (giving benefit of the (giving benefit of the doubt here as some doubt here as some work is yet to be done work is yet to be done on ppc, possibly others)on ppc, possibly others)

Supports a Supports a segmentation-based segmentation-based implementation of non-implementation of non-executable pages on executable pages on ppc that cannot ppc that cannot guarantee W^X on guarantee W^X on large memory loads.large memory loads.

Functional Comparison of PaX Functional Comparison of PaX and W^Xand W^X

As noted, there are many differences between As noted, there are many differences between PaX and W^X, but what do these technical PaX and W^X, but what do these technical differences mean in terms of effectiveness differences mean in terms of effectiveness against real-life exploit scenarios?against real-life exploit scenarios? W^X will not prevent exploitation of the kernelW^X will not prevent exploitation of the kernel The .bss and heap can be used in exploits to store data The .bss and heap can be used in exploits to store data

for the payload at a known location on OpenBSDfor the payload at a known location on OpenBSD OpenBSD’s mmap randomization is somewhat useless at OpenBSD’s mmap randomization is somewhat useless at

preventing ret-to-libc style attacks since the PLT in the preventing ret-to-libc style attacks since the PLT in the executable image is not at a randomized location and executable image is not at a randomized location and will allow for a similar attack.will allow for a similar attack.

On OpenBSD, attackers are not limited to the code that On OpenBSD, attackers are not limited to the code that resides in a task to complete their exploit.resides in a task to complete their exploit.

Rebuttal of arguments for Rebuttal of arguments for W^XW^X

Claim: Claim: ““randomizing load order indirectly leads to randomizing load order indirectly leads to

random addresses. sshd loads 8 libraries. 8! is random addresses. sshd loads 8 libraries. 8! is 40000, meaning if you have some return to libc 40000, meaning if you have some return to libc attack, libc could be at one of many many attack, libc could be at one of many many different locations.different locations.in short:in short:attack type: return to libc.attack type: return to libc.solution: move libc.”solution: move libc.”

[email protected] : [email protected] : http://www.deadly.org/article.php3?http://www.deadly.org/article.php3?sid=20031009110855&mode=flatsid=20031009110855&mode=flat

Rebuttal of arguments for W^X Rebuttal of arguments for W^X (cont.)(cont.)

Rebuttal:Rebuttal: The statement that random load order of 8 The statement that random load order of 8

libraries results in 40,000 possible orders does libraries results in 40,000 possible orders does not have a direct relation to security. The not have a direct relation to security. The assumption is made that for a successful attack, assumption is made that for a successful attack, one would need data/code from each of the 8 one would need data/code from each of the 8 libraries, when in reality, only one is needed. So libraries, when in reality, only one is needed. So in the presence of only random load order, in the presence of only random load order, focusing the attack on the first library will give focusing the attack on the first library will give you a 1 in 8 chance of success. This is hardly you a 1 in 8 chance of success. This is hardly anything that can be called security.anything that can be called security.


Claim: OpenBSD cannot protect against attacks Claim: OpenBSD cannot protect against attacks using mprotect because it would violate POSIX, using mprotect because it would violate POSIX, and OpenBSD does not violate POSIX.and OpenBSD does not violate POSIX. > > We don't break anything that standards or > > We don't break anything that standards or

defacto standards require. (Theo de Raadt)defacto standards require. (Theo de Raadt)> You do break POSIX as pointed out above. (PaX > You do break POSIX as pointed out above. (PaX Team)Team)False. Now go away. (Theo de Raadt)False. Now go away. (Theo de Raadt)

http://groups.google.com/groups?http://groups.google.com/groups?selm=200304171509.h3HF9N5t023465%40cvs.opeselm=200304171509.h3HF9N5t023465%40cvs.openbsd.org.lucky.openbsd.misc&oe=UTF-nbsd.org.lucky.openbsd.misc&oe=UTF-8&output=gplain8&output=gplain

Rebuttal of arguments for W^X Rebuttal of arguments for W^X (cont.) (cont.)

Rebuttal:Rebuttal: OpenBSD violates POSIXOpenBSD violates POSIX

““Indeed. None of the *BSD systems currently checks for Indeed. None of the *BSD systems currently checks for PROT_EXEC in this case.”PROT_EXEC in this case.”

[email protected] agreeing to POSIX violation in mmap()[email protected] agreeing to POSIX violation in mmap()

http://www.deadly.org/article.php3?http://www.deadly.org/article.php3?sid=20031009110855&mode=flatsid=20031009110855&mode=flat

OpenBSD’s POSIX compliance has not been OpenBSD’s POSIX compliance has not been verified formally or informally by any third party. verified formally or informally by any third party. Thus their claims of compliance are opinions and Thus their claims of compliance are opinions and not fact.not fact.


PaX does not violate POSIX by restricting PaX does not violate POSIX by restricting mprotect()mprotect()

““If an implementation cannot support the If an implementation cannot support the combination of access types specified by combination of access types specified by protprot, the call to , the call to mprotectmprotect() shall fail.”() shall fail.”

http://www.opengroup.org/onlinepubs/http://www.opengroup.org/onlinepubs/007904975/functions/mprotect.html007904975/functions/mprotect.html


Claim: PaX “goes too far” and breaks Claim: PaX “goes too far” and breaks applications. W^X does not break anything.applications. W^X does not break anything. > That's when you modify non-compliant software to > That's when you modify non-compliant software to

bring it in line bring it in line > with what the standard says. (PaX Team)> with what the standard says. (PaX Team)False. You go too far. (Theo de Raadt)False. You go too far. (Theo de Raadt)

“ “Our W^X changes break nothing.” (Theo de Raadt)Our W^X changes break nothing.” (Theo de Raadt)

http://groups.google.com/groups?http://groups.google.com/groups?selm=200304171509.h3HF9N5t023465%40cvs.openbsdselm=200304171509.h3HF9N5t023465%40cvs.openbsd.org.lucky.openbsd.misc&oe=UTF-8&output=gplain.org.lucky.openbsd.misc&oe=UTF-8&output=gplain

http://groups.google.com/groups?http://groups.google.com/groups?selm=200304170012.h3H0C45t025999%40cvs.openbsdselm=200304170012.h3H0C45t025999%40cvs.openbsd.org.lucky.openbsd.misc&oe=UTF-8&output=gplain.org.lucky.openbsd.misc&oe=UTF-8&output=gplain


Rebuttal:Rebuttal: OpenBSD breaks binary compatibility, PaX does not.OpenBSD breaks binary compatibility, PaX does not.

Binaries for OpenBSD that were incorrect to begin with (such Binaries for OpenBSD that were incorrect to begin with (such as assuming malloc() returns executable memory) will be as assuming malloc() returns executable memory) will be broken under W^X and have no way to be corrected, since broken under W^X and have no way to be corrected, since they do not support per-binary disabling of features. In PaX, they do not support per-binary disabling of features. In PaX, a single command can correct the problem. This is a secure-a single command can correct the problem. This is a secure-by-default design.by-default design.

The upstream release of XFree86 < 4.3 assumed malloc() The upstream release of XFree86 < 4.3 assumed malloc() returns executable memory for its module loader. Some returns executable memory for its module loader. Some point to this as PaX breaking XFree86, when it was a bug point to this as PaX breaking XFree86, when it was a bug in XFree86 that simply was not important before. There in XFree86 that simply was not important before. There are other similar bugs involving libGL and various drivers. are other similar bugs involving libGL and various drivers. Redhat fixed these bugs in XFree86 when Exec Shield was Redhat fixed these bugs in XFree86 when Exec Shield was developed.developed.

Additional comments on PaX Additional comments on PaX and W^Xand W^X

OpenBSD has yet to release any sort of formal OpenBSD has yet to release any sort of formal documentation on the design and implementation of W^X. documentation on the design and implementation of W^X. PaX’s has been available at PaX’s has been available at http://pageexec.virtualave.net/docs/http://pageexec.virtualave.net/docs/

There has been no public discussion of any kind of attack There has been no public discussion of any kind of attack model for W^X, while PaX’s is very well defined. PaX was model for W^X, while PaX’s is very well defined. PaX was developed to defeat entire classes of exploits. W^X developed to defeat entire classes of exploits. W^X provides no guarantees and seemingly attempts only at provides no guarantees and seemingly attempts only at picking away at several kinds of bugs (such as linear stack picking away at several kinds of bugs (such as linear stack overflows) through the use of many assorted features. As overflows) through the use of many assorted features. As shown earlier, the merits of some of these features are shown earlier, the merits of some of these features are debatable, and it makes it increasingly difficult for debatable, and it makes it increasingly difficult for OpenBSD to ever have any kind of toggling feature. Such a OpenBSD to ever have any kind of toggling feature. Such a toggling feature is important not only to keep binary toggling feature is important not only to keep binary compatibility but also for easier debugging.compatibility but also for easier debugging.

Factual comparison of PaX and Factual comparison of PaX and Exec ShieldExec Shield

For the most part, Exec Shield and W^X are similar (in that they For the most part, Exec Shield and W^X are similar (in that they both provide a subset of the features of PaX), so I will not give a both provide a subset of the features of PaX), so I will not give a point-by-point analysis. However, some differences between PaX point-by-point analysis. However, some differences between PaX and Exec Shield are:and Exec Shield are:

Exec Shield uses less randomization than PaX in every region, though it Exec Shield uses less randomization than PaX in every region, though it randomizes the same areas.randomizes the same areas.

To randomize the executable image, Exec Shield makes use of To randomize the executable image, Exec Shield makes use of Redhat’s PIE (Position Independent Executable).Redhat’s PIE (Position Independent Executable).

Exec Shield cannot even guarantee that when a task is fully loaded in Exec Shield cannot even guarantee that when a task is fully loaded in memory, that there do not exist memory regions that are both writable memory, that there do not exist memory regions that are both writable and executable, even if an application did not request such mappings.and executable, even if an application did not request such mappings.

Exec Shield recently discovered a bug (an off-by-one page), due to Exec Shield recently discovered a bug (an off-by-one page), due to someone running paxtest on an Exec Shield machine, that resulted in a someone running paxtest on an Exec Shield machine, that resulted in a page of memory being writable and executable that was assumed page of memory being writable and executable that was assumed otherwise. This bug was present ever since the first release of Exec otherwise. This bug was present ever since the first release of Exec Shield.Shield.

Exec Shield does nothing against kernel exploitationExec Shield does nothing against kernel exploitation

ReferencesReferences

OpenBSD OpenBSD http://www.openbsd.orghttp://www.openbsd.org PaX PaX http://pageexec.virtualave.nethttp://pageexec.virtualave.net Exec Shield Exec Shield

http://people.redhat.com/mingo/exec-shield/http://people.redhat.com/mingo/exec-shield/

Hardened Gentoo Hardened Gentoo http://www.gentoo.org/proj/en/hardened/http://www.gentoo.org/proj/en/hardened/

Adamantix Adamantix http://www.adamantix.orghttp://www.adamantix.org

http://www.openbsd.org/

http://pageexec.virtualave.net/

http://people.redhat.com/mingo/exec-shield/

http://www.gentoo.org/proj/en/hardened/

http://www.adamantix.org/

Questions?Questions?

Thanks for attending and your Thanks for attending and your interest in PaX. With whatever time interest in PaX. With whatever time remaining, I’d be glad to answer any remaining, I’d be glad to answer any questions about PaX or grsecurity.questions about PaX or grsecurity.

Documents

PaX () The Guaranteed End of Arbitrary Code Execution