Re: Grsec/PaX and Exec-shield

[Ingo Molnar <mingo@elte.hu>]

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