New Patch Lacks Non executable stacks!!!!!!!!!

[letrout]

I was wondering about that too, though perhaps a bit less ... emphatically. Did this new PaX thing replace the nonexecutable pages stuff somehow (don't laugh, I'm still very new to this and trying to get the concepts figured out)? Or did something get missed in 1.9.14?

[personman]

Likewise -- perhaps my issue is related.

I'm just trying grsec for the first time, and was wondering if there's some setting I need to enable somewhere to get the PAX stuff to work. Right now it doesn't seem to be enabled? Non-PAX features seem to be working, but paxtest 0.9.5 says:

Code: Select all

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

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

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 shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect)              : Vulnerable
Anonymous mapping randomisation test     : No randomisation
Heap randomisation test (ET_EXEC)        : No randomisation
Heap randomisation test (ET_DYN)         : No randomisation
Main executable randomisation (ET_EXEC)  : No randomisation
Main executable randomisation (ET_DYN)   : No randomisation
Shared library randomisation test        : No randomisation
Stack randomisation test (SEGMEXEC)      : 9 bits (guessed)
Stack randomisation test (PAGEEXEC)      : 9 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            : Vulnerable
Executable shared library data           : Vulnerable
Writable text segments                   : Vulnerable
---------------------------------------------------------------------------------


In case it heps, I'm using the current grsec-1.9.14-2.4.25.patch on an AMD Athlon XP 2700+ with 512MB RAM. I did not enable soft mode -- do I need to do that?

Thanks in advance for any help or insight offered.

[PaX Team]

guys, did you bother reading the announcement at http://www.grsecurity.net/news.php at all? it quite clearly explains what to watch out for. alternatively there's the configure help which explains what the new PaX control system is, choose as it is appropriate for your system (most likely you want CONFIG_PAX_EI_PAX as a minimum).

[PaX Team]

Can we have the old way back. This new stuff is a failure.

you can have your old way back, just enable the proper options, in your case that would probably be CONFIG_PAX_EI_PAX. as for who needs softmode: anyone who wants everything to work by default (including 3rd party binary only apps) but still wants a few important/sensitive apps to run with full protection. think of the average desktop user who doesn't want to get owned nor delve into the fine details of computer security.

[jappyfr]

Newbie with grsecurity and french poster (poor english !)

guys, did you bother reading the announcement at http://www.grsecurity.net/news.php at all? it quite clearly explains what to watch out for. alternatively there's the configure help which explains what the new PaX control system is, choose as it is appropriate for your system (most likely you want CONFIG_PAX_EI_PAX as a minimum).

Thanks, it's work, but can someone explain why i obtain
vulnerable results in return to function test (stcpy, memcpy).



Test results:
PaXtest - Copyright(c) 2003 by Peter Busser <peter@adamantix.org>
Released under the GNU Public Licence version 2 or later

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 : 16 bits (guessed)
Heap randomisation test (ET_EXEC) : 13 bits (guessed)
Heap randomisation test (ET_DYN) : 25 bits (guessed)
Main executable randomisation (ET_EXEC) : 16 bits (guessed)
Main executable randomisation (ET_DYN) : 17 bits (guessed)
Shared library randomisation test : 16 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) : Killed
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Killed
Executable shared library bss : Killed
Executable shared library data : Killed
Writable text segments : Killed

[PaX Team]

Thanks, it's work, but can someone explain why i obtain
vulnerable results in return to function test (stcpy, memcpy).

Return to function (strcpy) : Vulnerable
Return to function (strcpy, RANDEXEC) : Killed
Return to function (memcpy) : Vulnerable
Return to function (memcpy, RANDEXEC) : Killed

to understand the above results consider that paxtest is a regression test suite, that is, it tests what doesn't work, not what does. in our case 'what' refers to 'exploit techniques', so paxtest tries to simulate a few of them and shows you how many work under a given system. the four attacks above test so called return-to-libc attacks, that happens when an exploit writer tries to execute already existing code in the attacked program (vs. introducing his own payload). it is a known weakness of PaX (or more generally, kernel based approaches) that return-to-libc attacks are quite possible provided the attacker can learn the randomization in the attacked process - this is exactly the situation that the above tests run under. the two successful tests show that the technology behind RANDEXEC can detect such attacks, but it also has other drawbacks, so it's generally not useful - it's a proof of concept. for more information feel free to check out the main PaX document that explains all possible attack categories: http://pax.grsecurity.net/docs/pax.txt. also, if you're concerned about these kinds of attacks, consider using ssp (propolice) which is available in distributions such as Adamantix or Hardened Gentoo (URLs are on the PaX site).

[personman]

Thanks a lot. Paxtest is now giving better results. In case any other grsec newbies find themselved in my situation and read this... apparently, with PT_PAX_FLAGS enabled, but not the legacy EI_PAX marks, PaX is completely disabled (at least for me). The news posting does sort of hint at this:

To retain the same functionality as before, enable the "legacy ELF header marking" and "ELF program header marking"

However, I did not realize this applied to me since (1) I'm not upgrading from a previous version and thus not concerned about retaining same functionality as before, and (2), the Configure.help text says that if you enable both, PAX_FLAGS overrides EI_PAX.

BTW: So far, grsec looks truly great!

Cheers.

[PaX Team]

To retain the same functionality as before, enable the "legacy ELF header marking" and "ELF program header marking"

However, I did not realize this applied to me since (1) I'm not upgrading from a previous version and thus not concerned about retaining same functionality as before, and (2), the Configure.help text says that if you enable both, PAX_FLAGS overrides EI_PAX.

the override is about the markings, not the kernel support per se. the two are independent things, you can have a userland and kernel having/supporting any combination of the markings, at most not everything will result in the secure system you hoped to get - as usual, careful reading the help should answer the question:

You should enable this option only if your toolchain does not yet
support the new control flag location (PT_PAX_FLAGS) or you still
have applications not marked by PT_PAX_FLAGS.

[cmouse]

Funny how people managed to start instantly shouting how TERRIBLE AND BAD this is. I think this is brilliant change, it gives more control over HOW you want to implement grsecurity. You can still get the good old grsecurity by _reading_ instructions (which should be done first before starting to critizise new solutions).