Re: [Test] exec-shield-2.6.0-test5-G2 vs. paxtest & libsafe

[Ingo Molnar]

On Sat, 27 Sep 2003, Gabor MICSKO wrote:

> >   redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-G3
> >   redhat.com/~mingo/exec-shield/exec-shield-2.6.0-test5-bk12-G3
> 
> Yes, this patch really better.

> Linux sunshine 2.6.0-test5-exec-shield-nptl #3 SMP 2003. sze. 27.,

> http://www.research.avayalabs.com/project/libsafe/src/libsafe-2.0-16.tgz

[all libsafe exploits fail - good.]

> http://pageexec.virtualave.net/paxtest-0.9.1.tar.gz

> sunshine:/home/trey/exec/paxtest-0.9.1# ./paxtest
> It may take a while for the tests to complete
> Test results:
> Executable anonymous mapping             : Killed
> Executable bss                           : Killed
> Executable data                          : Killed
> Executable heap                          : Killed
> Executable stack                         : Killed

ok.

> Executable anonymous mapping (mprotect)  : Killed

this is a testsuite bug i think - anonmap.c mprotanon.c differ in nothing 
but the name string of the test.

> 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

these are 'vulnerable' by design. There can be legitimate reasons to
mprotect() any of these regions. And if an attacker has enough control
over the target to execute mprotect() with precise arguments then the game
is mostly over anyway. Does anyone know the rationale of these mprotect()
tests?

> Return to function (strcpy)              : Vulnerable
> Return to function (memcpy)              : Vulnerable

it needs gcc level changes to change the stackframe layout - out of the
scope of exec-shield.

> Writable text segments                   : Vulnerable

this is a variant of the mprotect() tests too - so possible by design.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/