paxtest-0.9.7-pre5 on an AMD64

[specs]

I tried running paxtest on an AMD64 (Debian) to see what paxtest could find.
First I need to point out that I could only get a working paxtest using "make adamantix".

I haven't started looking how to install paxtest yet or how to turn it into a package.
Paxtest can only run in the src-directory for now.

Code: Select all

$ pushd paxtest-0.9.7-pre5/;paxtest kiddie ;popd
~/paxtest-0.9.7-pre5 ~
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: kiddie
Linux lina 2.6.24.2-grsec-200802192340-1 #1 SMP Sat Feb 23 12:53:30 CET 2008 x86_64 GNU/Linux

Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect)              : Killed
Anonymous mapping randomisation test     : 33 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 13 bits (guessed)
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : No randomisation
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 (strcpy, RANDEXEC)    : paxtest: return address contains a NULL byte.
Return to function (memcpy)              : Vulnerable
Return to function (memcpy, RANDEXEC)    : Vulnerable
Executable shared library bss            : Killed
Executable shared library data           : Killed
Writable text segments                   : Killed

~
$ grep RAND linux-2.6.24.2/.config
..
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

I hope the results found above are representive for the system.
At least the PAX_RANDMMAP does not work. This also shown with "ps ax".
This was one of the reasons to try to run paxtest in the first place.

Has anyone gotten paxtest to work on an AMD64?
Has anyone gotten RANDMMAP to work on an AMD64?

[PaX Team]

I hope the results found above are representive for the system.
At least the PAX_RANDMMAP does not work. This also shown with "ps ax".

i don't see where you see RANDMMAP not working here. maybe you meant RANDEXEC (an obsolete feature) or PIE?

[specs]

I was looking for the option CONFIG_GRKERNSEC_RANDPID. It is not present anymore, probably since grsecurity 2.1.10.

As for the null byte, it looks to me like the paxtest program needs to be ported to AMD64. For comparison, the x86_64 output mentioned in the Xen thread gives more normal output. That was an Intel-based server. Frankly I hoped there would be a pointer to a patch but it points to the latest version in the ~paxguy area.

I also saw differences between paxtest 0.9.7-pre4-2 (debian) and the 0.9.7-pre5 (tarball grsecurity) on an i386 (C3). The part with the ET_DYN and ET_EXEC differ in the tests. From the tests on the AMD64 I suspected it to be something like the RANDPID option missing. But why would different versions of the same program yield different results on the same architecture?

Perhaps these are also tests based on obsolete functions?
Since I saw the difference I a played a little, but the results are consistent with each version of the program.

$ paxtest kiddie
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: kiddie
Linux navi 2.6.24.2-grsec-200802192340-1 #1 PREEMPT Sat Feb 23 14:25:05 CET 2008 i686 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 17 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 23 bits (guessed)
Main executable randomisation (ET_EXEC) : 17 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 17 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 23 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed

$ ./paxtest kiddie
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Writing output to paxtest.log
It may take a while for the tests to complete
Test results:
PaXtest - Copyright(c) 2003,2004 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

Mode: kiddie
Linux navi 2.6.24.2-grsec-200802192340-1 #1 PREEMPT Sat Feb 23 14:25:05 CET 2008 i686 GNU/Linux

Executable anonymous mapping : Killed
Executable bss : Killed
Executable data : Killed
Executable heap : Killed
Executable stack : Killed
Executable anonymous mapping (mprotect) : Killed
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 17 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 13 bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (ET_DYN) : No randomisation
Shared library randomisation test : 17 bits (guessed)
Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Vulnerable
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Vulnerable
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed

[PaX Team]

I was looking for the option CONFIG_GRKERNSEC_RANDPID. It is not present anymore, probably since grsecurity 2.1.10.

it was removed a while ago, for reasons i forget but i think it was because changes in the kernel made it very difficult to maintain this part of the code for little (if any) real-life gain.

As for the null byte, it looks to me like the paxtest program needs to be ported to AMD64.

paxtest needs a proper port to anything . the null byte on amd64 is the result of 64 bit addresses and the default executable base address having one, we cannot change it (well, with a custom linker script we could, but it wouldn't reflect the state of real life executables then).

For comparison, the x86_64 output mentioned in the Xen thread gives more normal output.

that wasn't that normal either because the ret2libc simulations are supposed to fail by design as PaX doesn't protect against them directly. so if there's a success report, it must be due to some artifact on the given system (say, forcefully enabled SSP) and not because PaX did anything.

I also saw differences between paxtest 0.9.7-pre4-2 (debian) and the 0.9.7-pre5 (tarball grsecurity) on an i386 (C3). The part with the ET_DYN and ET_EXEC differ in the tests.

probably due to bugfixes in paxtest itself, also building ET_DYN executables hasn't been easy/standardized back in the day, it can very well happen that neither Makefile produces the correct format on your system (the whole paxtest Makefile system needs a rewrite, but our free time, as usual, is short for this).

From the tests on the AMD64 I suspected it to be something like the RANDPID option missing.

PID randomization has never had anything to do with paxtest, you must be mixing up something here...

Perhaps these are also tests based on obsolete functions?

i think i said elsewhere already that RANDEXEC has been obsoleted for example, tests for that will show no difference from non-randomized ET_EXEC executables.