Page 1 of 1

Pax seems to have no effect

PostPosted: Sat Oct 06, 2007 3:01 pm
by tgc
I've compiled the latest stable kernel (2.6.22.9) with the latest pax-patch (2.6.22.9-test31) + reiser4 support, but when I run paxtest it tells me the system is still vulnerable:
Code: Select all
Mode: blackhat
Linux odin 2.6.22-tgc #1 SMP PREEMPT Sat Oct 6 20:19:39 CEST 2007 x86_64 Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz GenuineIntel GNU/Linux

Executable anonymous mapping             : Vulnerable
Executable bss                           : Vulnerable
Executable data                          : Vulnerable
Executable heap                          : Vulnerable
Executable stack                         : Vulnerable
Executable anonymous mapping (mprotect)  : Vulnerable
Executable bss (mprotect)                : Vulnerable
Executable data (mprotect)               : Vulnerable
Executable heap (mprotect)               : Vulnerable
Executable stack (mprotect)              : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 33 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 40 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : 32 bits (guessed)
Shared library randomisation test        : 33 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 40 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 40 bits (guessed)
Return to function (strcpy)              : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : paxtest: return address contains a NULL byte.
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Vulnerable
Executable shared library data           : Vulnerable


My PAX kernel config option options is:
Code: Select all
#
# PaX
#
CONFIG_PAX=y

#
# PaX Control
#
CONFIG_PAX_SOFTMODE=y
CONFIG_PAX_EI_PAX=y
CONFIG_PAX_PT_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y
# CONFIG_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_PAX_HOOK_ACL_FLAGS is not set

#
# Non-executable pages
#
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_NOELFRELOCS is not set

#
# Address Space Layout Randomization
#
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

#
# Miscellaneous hardening features
#
CONFIG_PAX_MEMORY_SANITIZE=y


But even though paxtest doesn't seem to be impressed, I do feel a difference, since stuff depending on libcrypto (and some other things) doesn't work anymore.
I've searched the forum but can't seem to find a solution that works for me, so I hope someone has a sharper eye than me :)
If you need more info just let me know.

Re: Pax seems to have no effect

PostPosted: Sun Oct 07, 2007 6:45 am
by PaX Team
tgc wrote:I've compiled the latest stable kernel (2.6.22.9) with the latest pax-patch (2.6.22.9-test31) + reiser4 support, but when I run paxtest it tells me the system is still vulnerable:
what do the PaX lines in various /proc/pid/status say? also, which paxtest was this (if not the test version in my test dir, then try that please)?
But even though paxtest doesn't seem to be impressed, I do feel a difference, since stuff depending on libcrypto (and some other things) doesn't work anymore.
what is the issue with libcrypto? if it's the GNU_STACK problem then i don't see how that could trigger without MPROTECT being enabled on the process and that's easy to fix as explained in the forum... weird. do you mix 32/64 bit userland? if so, do both have the same symptoms?

Re: Pax seems to have no effect

PostPosted: Sun Oct 07, 2007 8:15 am
by tgc
PaX Team wrote:
tgc wrote:I've compiled the latest stable kernel (2.6.22.9) with the latest pax-patch (2.6.22.9-test31) + reiser4 support, but when I run paxtest it tells me the system is still vulnerable:

what do the PaX lines in various /proc/pid/status say? also, which paxtest was this (if not the test version in my test dir, then try that please)?

The only PaX line I can find in the /proc/<pid>/status files was:
Code: Select all
PaX:    PeMRs

And it seems to apear in them all. My paxtest version is 0.9.7-pre5, compiled using Makefile.psm (the only one the worked).
PaX Team wrote:
tgc wrote:But even though paxtest doesn't seem to be impressed, I do feel a difference, since stuff depending on libcrypto (and some other things) doesn't work anymore.
what is the issue with libcrypto? if it's the GNU_STACK problem then i don't see how that could trigger without MPROTECT being enabled on the process and that's easy to fix as explained in the forum... weird. do you mix 32/64 bit userland? if so, do both have the same symptoms?

The problem with libcrypto was/is that I get this error:
Code: Select all
error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied

I fixed it using the execstack utillity.
I have a 32-bit libs and applications running, but i couldn't find any that were affected when running with PaX.

Re: Pax seems to have no effect

PostPosted: Sun Oct 07, 2007 8:32 am
by PaX Team
tgc wrote:The only PaX line I can find in the /proc/<pid>/status files was:
Code: Select all
PaX:    PeMRs
ok, so PaX thinks it's active but in reality the NX bit doesn't seem to be. this will need some debugging, would be nice if you could hop on irc (OFTC, #pax or #grsecurity) to make this faster.

PostPosted: Sun Oct 07, 2007 9:02 am
by tgc
It turns out that the NX-bit feature was turned of in my bios. Enabling it fixed the issue :)