Bugtraq mailing list archives
some PaX Q&A
From: PaX <pageexec () FREEMAIL HU>
Date: Thu, 2 Nov 2000 11:19:11 +0100
firts of all, thanks for the feedback, and excuse us for not addressing everyone personally, but we'll try to answer some questions you have raised in general. 1. before anything, please take a look at the following URL, it already clarifies some points: http://securitygeeks.shmoo.com/article.php?story=20001031052646219#comments 2. 'unique solution' thread: PaX is *NOT* the ultimate solution against buffer overflow based exploits (sorry if we made it sound like that), what it does (implementing the PAGE_EXEC feature) however reduces the ways such an overflow can be (ab)used by an attacker. namely, only already existing executable code (in the given tasks's address space) can be executed, but *NEVER* the payload (as long as no read/write/exec pages exist in the task, which is normally the case, except that in the current implementation shared memory pages are created read/write/exec, as soon as someone ensures us that exec is indeed unnecessary, we'll remove it). it does not matter how the attacker sets up the overflowed stack to get his payload copied all around in the tasks' address space, he will never get to execute it. this in our opinion is a significant progress already. so, let's address the remaining way for exploits (of which the 'return to libc' method is one example) next. 3. 'return to libc' thread: now that our attacker has left no choice but to try issue calls to existing code in the tasks's address space, our next goal will have to be to reduce his chances at doing this. the idea we've come up with is a very simple authentication mechanism, which - much like stackguard, propolice and the like - requires recompilation of applications. without further ado, let's take an assembly level example (where everything ends up eventually). hopefully the intel/nasm syntax will cause no problems (remember that args are in dest/src order). segment .data libc_func_flag: dd 0 segment .text some_user_app_func: mov dword [libc_func_flag],1 ... push args on the stack for call... call libc_func mov dword [libc_func_flag],0 .... libc_func: ... move args from stack to registers for int 0x80... cmp dword [libc_func_flag], 1 jz .1 ... refuse call, crash/exit//log/etc... .1: int 0x80 ... do the rest ... retn with this flag system the attacker can still attempt to execute existing code, but he will either fail (when directly attempts to call libc_func) or succeed, but args will be taken from the app instead of from his payload (when returning to some_user_app_func). if you combine this method with propolice/stackguard and the like (plus PaX), you will end up with a system in which finding *exploitable* buffer overflows will become very hard (if you have reverse engineering experience, you will know why). it won't become impossible, but very special circumstances will be required. 4. 'relation to openwall' thread: PaX implements more than what solar designer's non-executable stack does (PaX protects any and all pages that are created without the PAGE_EXEC flag). therefore it is our hope that even if PaX does not make it into the mainstream kernel (there are arguments indeed that 'regular' users would not need such a feature), openwall and similar initiatives will embrace it.
Current thread:
- some PaX Q&A PaX (Nov 03)
- <Possible follow-ups>
- Re: some PaX Q&A der Mouse (Nov 04)