On Tue, 4 Nov 2003, Peter Busser wrote: > - Running paxtest shows the differences between PaX and exec-shield. > Everyone is invited to run paxtest to see for yourself.
the reply below mostly a re-sent of a mail i sent to you privately - but you repeat this argument again without any apparent answer to my counter-arguments. Summary: i can see no significant differences between the paxtest output - all the differences seem to be bogus, see the details below. Here's the output of paxtest-0.9.4 under an exec-shield-G4 kernel: Executable anonymous mapping : Killed Executable bss : Killed Executable data : Killed Executable heap : Killed Executable stack : Killed the above ones are important, exec-shield catches these exploit categories. 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 i do believe the above checks are bogus, please explain to me why this case is important to handle. the test checks whether it's possible to execute an area after mprotect(PROT_EXEC) has been called over it. The answer: of course it's executable, the application asked the kernel for this! Any exploit that can call mprotect() has free reign anyway. The ability to execute a library call or a system-call is End Of Story. Why is it such a big issue to inhibit mprotect() calls? Especially since not honoring mprotect() calls breaks existing apps and specifications. if you can call mprotect() then you can very well call munmap() and mmap(MAP_FIXED,PROT_EXEC) as well, which is equivalent to the mprotect() call. From whatever angle i look at this test, it's bogus. in any case, the above restriction is trivial to add to the kernel but still i didnt want to add it because it's simply pointless. Anonymous mapping randomisation test : 8 bits (guessed) Heap randomisation test (ET_EXEC) : 14 bits (guessed) Heap randomisation test (ET_DYN) : 13 bits (guessed) Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : 12 bits (guessed) Shared library randomisation test : 12 bits (guessed) Stack randomisation test (SEGMEXEC) : 17 bits (guessed) Stack randomisation test (PAGEEXEC) : 17 bits (guessed) these are acceptable levels or randomization against remote attacks, except the ET_EXEC one, but ET_DYN is used for PIE binaries so this is not an issue. Return to function (strcpy) : Vulnerable Return to function (strcpy, RANDEXEC) : Vulnerable Return to function (memcpy) : Vulnerable Return to function (memcpy, RANDEXEC) : Vulnerable (these can only be caught via compiler changes, clearly not a target for PaX or exec-shield.) Executable shared library bss : Killed Executable shared library data : Killed these are caught by exec-shield too, and are quite important categories to catch. Writable text segments : Vulnerable again, i think this is a bogus restriction too. Why deny writable text segments? Control over the application at such a level is Game Over in virtually every case. summary: exec-shield catches all the non-bogus categories and tries to raise the bar of exploitation, without breaking binary compatibility arbitrarily. Ingo