Posted by: Subreption LLC 10 months, 2 weeks ago (0 comments)
They say a picture is worth a thousand words, or so the saying goes. Therefore, the output from the now classic paxtest tool (which exposed the practical differences of ExecShield and PaX, among an array of other interesting tidbits) follows:
PaXtest - Copyright(c) 2003,2004 by Peter Busser Released under the GNU Public Licence version 2 or later Mode: blackhat Darwin foobar.local 11.0.0 Darwin Kernel Version 11.0.0: Fri May 6 22:16:19 PDT 2011; root:xnu-1699.22.53~1/RELEASE_X86_64 x86_64 Executable anonymous mapping : Killed Executable bss : Killed Executable data : Killed Executable heap : Killed Executable stack : Killed Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect) : Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Executable stack (mprotect) : Vulnerable Anonymous mapping randomisation test : No randomisation Heap randomisation test (ET_EXEC) : No randomisation Main executable randomisation (ET_EXEC) : No randomisation Shared library randomisation test : No randomisation Stack randomisation test (SEGMEXEC) : No randomisation Stack randomisation test (PAGEEXEC) : No randomisation Return to function (strcpy) : paxtest: return address contains a NULL byte. Return to function (strcpy, RANDEXEC) : paxtest: return address contains a NULL byte. Return to function (memcpy) : Killed Return to function (memcpy, RANDEXEC) : Killed Executable shared library bss : Killed Executable shared library data : Killed Writable text segments : Vulnerable
Now a very short interpretation of the information above: Essentially nothing has changed (at first glance) from Snow Leopard. 64-bit setups benefit from non-executable heap, and all setups benefit from non-executable stack.There is no image base randomization, therefore the program text stays at the same place every time. The most common instances of stack-based buffer overflows will be caught by GCC's SSP/ProPolice implementation, save few corner cases. There is no enforcement of page permission semantics. Formerly writable pages can become executable through mprotect & co.
It might be farfetched to draw conclusions before Lion's definitive release, but as of today, and if nothing changes dramatically, what's not to love? Before all the hype begins... the buck stops here.
Comments