grsecurity forums

Good evening,

Been playing with grsec for years on baremetal and just spun up a new VM using proxmox/kvm.

Fresh copy of debian 7.8 and downloaded/compiled:
Kernel 3.2.66 (vanilla from kernel.org)
grsecurity-3.0-3.2.66-201502021851.patch

enabled grsec:
config method (automatic)
usage type (server)
Virtualization Type (guest)
Virtualization Software(KVM)
Required Priorities (Security)

when I run paxtest (0.9.13) after rebooting with new grsec kernel. most tests show vulnerable:
Mode: kiddie
Linux box01 3.2.66-grsec #1 SMP Tue Feb 3 15:15:14 CST 2015 x86_64 GNU/Linux

Executable anonymous mapping : Vulnerable
Executable bss : Vulnerable
Executable data : Vulnerable
Executable heap : Vulnerable
Executable stack : Killed
Executable shared library bss : Vulnerable
Executable shared library data : 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 : 29 quality bits (guessed)
Heap randomisation test (ET_EXEC) : 22 quality bits (guessed)
Heap randomisation test (PIE) : 35 quality bits (guessed)
Main executable randomisation (ET_EXEC) : No randomisation
Main executable randomisation (PIE) : 27 quality bits (guessed)
Shared library randomisation test : 29 quality bits (guessed)
VDSO randomisation test : 29 quality bits (guessed)
Stack randomisation test (SEGMEXEC) : 35 quality bits (guessed)
Stack randomisation test (PAGEEXEC) : 35 quality bits (guessed)
Arg/env randomisation test (SEGMEXEC) : 39 quality bits (guessed)
Arg/env randomisation test (PAGEEXEC) : 39 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)
Return to function (strcpy) : paxtest: return address contains a NULL byte.
Return to function (memcpy) : Return to function (strcpy, PIE) : paxtest: return address contains a NULL byte.
Return to function (memcpy, PIE) :

I can see that dmesg is restricted and sysctl -a | grep grsecurity dumping alot of variables.

Am I missing something?
eric

can you post your .config please?

Can you also provide the contents of /proc/cpuinfo on the guest?

-Brad

Here you go:

root@box01:/usr/src/linux-3.2.66# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 3333.332
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm constant_tsc nopl pni cx16 x2apic hypervisor lahf_lm
bogomips : 6666.66
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 3333.332
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm constant_tsc nopl pni cx16 x2apic hypervisor lahf_lm
bogomips : 6666.66
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

Here's a copy of the .config:
http://pastebin.com/8pnzeb1e

You're probably using -cpu kvm64 which lacks NX support (for what reason, who knows, even though to our knowledge the only real 64-bit processor lacking NX was some rare Celeron D). Ideally you should use -cpu host, or failing that, a minimum of -cpu kvm64,+nx.

-Brad

hello,

You're right; it was set to default(kvm64). I set it to host and it still is failing on paxtest, then i tried with (cpu: kvm64,+nx) (/etc/pve/nodes/virt01/qemu-server/100.conf) and it's still failing on paxtest.

below is the local for /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU X5470 @ 3.33GHz
stepping : 10
microcode : 0x1
cpu MHz : 3333.332
cache size : 6144 KB
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall lm constant_tsc arch_perfmon rep_good nopl pni ssse3 cx16 sse4_1 x2apic xsave hypervisor lahf_lm
bogomips : 6666.66
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

below is the kvm64,+nx for /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Common KVM processor
stepping : 1
microcode : 0x1
cpu MHz : 3333.332
cache size : 4096 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall lm constant_tsc nopl pni cx16 x2apic hypervisor
bogomips : 6666.66
clflush size : 64
cache_alignment : 128
address sizes : 40 bits physical, 48 bits virtual
power management:

any other step to try?

thank you!

is the nx feature present in the host cpuinfo at all? also can you check dmesg (both host and guest) for "NX (Execute Disable) protection: active"?

You're right; the host doesn't have NX in the cpuinfo and under the dmesg dump (it's complete); it has no NX flags anywhere.

Intel X5470 (Harpertown)?

cpuflags:
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority

I guess that's the problem; no true NX cpu flag on the host level =\

Thank you guys for your help on this; I'll use something more newer to play with!
eric

that cpu has NX support according to http://ark.intel.com/products/35430/Int ... 33-MHz-FSB, so maybe it's just disabled in the BIOS?

Thank you for the note.

I just checked a quick howto from vmware where the NX is missing for the DL380 G5:
http://blog.vmpros.nl/2012/09/17/vmware ... e-enabled/

going to try in the morning.

Thank you again
eric

What was your host kernel version?

-Brad

What boot loader is the host using? (Legacy BIOS, UEFI, shim, grub, etc?) It's possible a boot entirely through 64-bit entry points would skip the XD-fixup code in the kernel, since it's only present on the 32-bit startup paths at the moment.

can you test this quick hack on your box (without enabling NX in the BIOS):

Code: Select all

--- a/arch/x86/kernel/head_64.S       2015-01-04 02:06:23.316996871 +0100
+++ b/arch/x86/kernel/head_64.S   2015-02-05 00:40:20.273012360 +0100
@@ -213,6 +213,13 @@
 1:

        /* Check if nx is implemented */
+       movl    $MSR_IA32_MISC_ENABLE, %ecx
+       rdmsr
+       btrl    $2, %edx                # clear MSR_IA32_MISC_ENABLE_XD_DISABLE
+       jnc     verify_cpu_check        # only write MSR if bit was changed
+       wrmsr
+
+verify_cpu_check:
        movl    $0x80000001, %eax
        cpuid
        movl    %edx,%edi

update: i tried the hack myself (needs nosmp if you still want to try it) and it works fine, so i'll leave it up to Kees to produce a proper patch for upstream .