grsecurity forums

Hi

I've noticed that NX bit support for i386 architectures has been recently implemented in PAX. I recompiled 2.6.23.16 with grsec grsecurity-2.1.11-2.6.23.14-200801231800.patch (with rejected mmap.c taken from 2.6.24.2 patch), CONFIG_PAX_PAGEEXEC enabled and CONFIG_PAX_SEGMEXEC disabled. On old Xeon CPU (CONFIG_MPENTIUM4=y) it works fine (I checked in cpuinfo that the CPU is NX-capable) and paxtest result is satisfactory. However, on the same kernel compiled for Opteron (CONFIG_MK8=y) run on a "Dual-Core AMD Opteron(tm) Processor 2214 HE" paxtest indicates that the system is less secure:

Mode: blackhat
Linux xxx 2.6.23.16-grsec #1 SMP Thu Feb 21 00:46:10 CET 2008 i686 GNU/Linux

Executable anonymous mapping : Vulnerable
Executable bss : Killed
Executable data : Killed
Executable heap : Vulnerable
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Killed
Executable data (mprotect) : Killed
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Executable stack (mprotect) : Killed
Anonymous mapping randomisation test : 18 bits (guessed)
Heap randomisation test (ET_EXEC) : 5 bits (guessed)
Heap randomisation test (ET_DYN) : 16 bits (guessed)
Main executable randomisation (ET_EXEC) : 15 bits (guessed)
Main executable randomisation (ET_DYN) : 14 bits (guessed)
Shared library randomisation test : 15 bits (guessed)
Stack randomisation test (SEGMEXEC) : 24 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

According to /proc/cpuinfo the Opteron mentioned is also NX-capable. The same kernel compiled with CONFIG_PAX_SEGMEXEC=y passes paxtest on both CPUs (only strcpy/memcpy are vulnerable which I guess is normal).

By the way, is there any advantage or point in enabling both CONFIG_PAX_PAGEEXEC and CONFIG_PAX_SEGMEXEC for a NX-capable i386 CPU?

Mind you, I've just found out that the problem does not exist on "Intel(R) Xeon(R) CPU 5130" processors. The same kernel compiled with CONFIG_PAX_PAGEEXEC=y and CONFIG_PAX_SEGMEXEC unset passes all PAX tests (apart from the ones it's not supposed to pass anyway).
It seems that for Opterons CONFIG_PAX_PAGEEXEC is not enough to provide decent protection.

jorgus wrote:According to /proc/cpuinfo the Opteron mentioned is also NX-capable. The same kernel compiled with CONFIG_PAX_SEGMEXEC=y passes paxtest on both CPUs (only strcpy/memcpy are vulnerable which I guess is normal).

does dmesg report that the NX bit has been enabled? also does 2.6.24.2 behave the same way?

By the way, is there any advantage or point in enabling both CONFIG_PAX_PAGEEXEC and CONFIG_PAX_SEGMEXEC for a NX-capable i386 CPU?

if you don't need to share the same kernel image on potentially different CPUs, there's no real advantage, just stick with PAGEEXEC.

PaX Team wrote:does dmesg report that the NX bit has been enabled? also does 2.6.24.2 behave the same way?

I don't think my kernel announces non-execute capability in dmesg. I checked it in /proc/cpuinfo.

processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 2212
stepping : 2
cpu MHz : 2000.223
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips : 4002.92
clflush size : 64

The problem affects both 2212 and 2214 Opterons. I'm afraid can't check it on 2.6.24.x at the moment. As soon as I will, I'll let you know.

look at bios if you dont have option to enable/disable No Execute bit

jorgus wrote:I don't think my kernel announces non-execute capability in dmesg.

dmesg | grep NX should give you NX (Execute Disable) protection: active

I checked it in /proc/cpuinfo.

flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc

so you do have NX as expected from an opteron and dmesg should tell you the same. as for the actual problem, i don't get it, it seems that only some of the anon mappings are forced to be executable which makes little sense based on the code... when you run paxtest, do you get the proper PaX kernel logs for each of the 'killed' tests and nothing for the rest?

PaX, I don't see anything about NX in my dmesg either, athlon x2 4200+.

But it does show in /proc/cpuinfo:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy

Do you have enabled PAE or 64G in your kernel???

I'm running a 64bit kernel so no PAE and no 64G either.

forsaken wrote:I'm running a 64bit kernel so no PAE and no 64G either.

64 bit mode always enables PAE and obviously it doesn't need any special config setting to access 64GB or more memory .