PAX installed, but OS still vulnerable...

[jeyRocs]

Hi!

I've two servers with Intel Xeon 3.2GHz (HT + EM64T) CPU each. I've recently set them up with AMD64 Hardened Gentoo (PIC+SSP enabled GCC, PAX+grsecurity kernel). The first one works as it ought to work - paxtest gives expected results. But the second one...:

Code: Select all

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)   : 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: bad luck, try different compiler options.
Return to function (memcpy)              : Killed
Return to function (strcpy, RANDEXEC)    : paxtest: bad luck, try different compiler options.
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Moreover, kernel configuration is almost the same on both servers! It differs only about SCSI controller and software raid support...

Code: Select all

adeliae ~ # diff kernel-cfgs/ad1 kernel-cfgs/an1
4c4
< # Tue Feb 21 15:06:54 2006
---
> # Mon Feb 20 22:11:55 2006
30c30
< CONFIG_LOCALVERSION="-ad1"
---
> CONFIG_LOCALVERSION="-an1"
484c484,490
< # CONFIG_SCSI_AIC79XX is not set
---
> CONFIG_SCSI_AIC79XX=y
> CONFIG_AIC79XX_CMDS_PER_DEVICE=32
> CONFIG_AIC79XX_RESET_DELAY_MS=15000
> CONFIG_AIC79XX_ENABLE_RD_STRM=y
> # CONFIG_AIC79XX_DEBUG_ENABLE is not set
> CONFIG_AIC79XX_DEBUG_MASK=0
> # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
516c522,532
< # CONFIG_MD is not set
---
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=y
> # CONFIG_MD_LINEAR is not set
> # CONFIG_MD_RAID0 is not set
> CONFIG_MD_RAID1=y
> # CONFIG_MD_RAID10 is not set
> # CONFIG_MD_RAID5 is not set
> # CONFIG_MD_RAID6 is not set
> # CONFIG_MD_MULTIPATH is not set
> # CONFIG_MD_FAULTY is not set
> # CONFIG_BLK_DEV_DM is not set
521,522c537,538
< CONFIG_FUSION=y
< CONFIG_FUSION_SPI=y
---
> # CONFIG_FUSION is not set
> # CONFIG_FUSION_SPI is not set
525,526d540
< CONFIG_FUSION_MAX_SGE=128
< # CONFIG_FUSION_CTL is not set
567,568c581
< CONFIG_E1000=y
< # CONFIG_E1000_NAPI is not set
---
> # CONFIG_E1000 is not set
adeliae ~ #

Pax is configured on both servers as follows:

Code: Select all

CONFIG_PAX=y

# CONFIG_PAX_SOFTMODE is not set
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

CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_NOELFRELOCS is not set

CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

Here's some chpax result (just for one server, 'cause both give the same results):

Code: Select all

antarctica linux # chpax -v /usr/lib64/paxtest/mprotdata

----[ chpax 0.7 : Current flags for /usr/lib64/paxtest/mprotdata (PeMRxS) ]----

 * Paging based PAGE_EXEC       : enabled (overridden)
 * Trampolines                  : not emulated
 * mprotect()                   : restricted
 * mmap() base                  : randomized
 * ET_EXEC base                 : not randomized
 * Segmentation based PAGE_EXEC : enabled

antarctica linux #

Everything seems to be ok, but paxtest shows it isn't... I really have no idea. Can anyone help me? I would be very grateful .[/code]

[PaX Team]

Here's some chpax result (just for one server, 'cause both give the same results):

on gentoo you use paxctl, not chpax, gentoo's been patching their binutils with PT_PAX_FLAGS support for a long time. also, what does cat /proc/self/status | grep PaX say? other than that, i have no idea what could be wrong, it's either the wrong kernel (but then the ASLR numbers look good) or some ELF marking problem (you can check other processes' status to see what PaX did to them).

[jeyRocs]

Code: Select all

antarctica ~ # paxctl -v /usr/lib64/paxtest/mprotdata
PaX control v0.3
Copyright 2004,2005 PaX Team <pageexec@freemail.hu>

- PaX flags: -------xE--- [/usr/lib64/paxtest/mprotdata]
        RANDEXEC is disabled
        EMUTRAMP is enabled
antarctica ~ # cat /proc/self/status |grep PaX
PaX:    PeMRs
antarctica ~ #

Again, these results are the same for both servers...

There is one thing I haven't mention yet, but IMHO it may has some connection to the problem. When emerging linux-headers-2.6.11-r2 on adeliae (the server which I have no problems with) everything went all right. But emerging the same on antarctica (the vulnerable one) ended with:

Code: Select all

(...)
CRC-CCITT functions (CRC_CCITT) [N/m/y/?] n
CRC32 functions (CRC32) [Y/?] y
CRC32c (Castagnoli, et al) Cyclic Redundancy-Check (LIBCRC32C) [N/m/y/?] n
SPLIT include/linux/autoconf.h -> include/config/*
CC scripts/mod/empty.o
scripts/mod/empty.c:1: sorry, unimplemented: code model kernel not supported in PIC mode
scripts/mod/empty.c:1: error: code model `kernel' not supported in the 64 bit mode
distcc[22126] ERROR: compile scripts/mod/empty.c on 83.19.45.3 failed
make[2]: *** [scripts/mod/empty.o] Error 1
make[1]: *** [scripts/mod] Eror 2
make: *** [scripts] Error 2

Then I tried to emerge linux-headers-2.6.11-r3 (marked as unstable and so masked with ~amd64) and it merged successfully. Recenlty I've also noticed some glibc problems...

I'm not sure what the linux-headers error means, so I still have no idea what's the situation going about. It would be kind if someone could explain it to me. Maybe I should try to re-emerge toolchain and then a whole system?

Thanks for your help.

[PaX Team]

Code: Select all

(...)
scripts/mod/empty.c:1: sorry, unimplemented: code model kernel not supported in PIC mode
scripts/mod/empty.c:1: error: code model `kernel' not supported in the 64 bit mode
distcc[22126] ERROR: compile scripts/mod/empty.c on 83.19.45.3 failed

well, i see two potential (possibly related) issues here. one is that apparently kernel compilation (or the simulation that -headers does) produces PIC, which makes me think that the hardened-gcc profile does/did bad things for you. for the paxtest, the test version on the PaX homepage should handle it better, you should give it a try. the second issue is the use of distcc, you probably know that you have to be very careful to not mix different gcc versions *and* profiles among the machines, can you verify that? (stale objects in the distcc cache could have caused the above error too)

[jeyRocs]

Yeah! I've just disabled ccache and distcc and so linux-headers-2.6.11-r2 compiled cleanly! I've started rebuilding whole system without those features, just to be sure everything'll be all right . Then I'll post here some results.

It seems strange to me, as both servers have the same hardened gccs. But nevermind . See you in few hours.

[jeyRocs]

No way...

Although the strange glibc and linux-headers problems have gone, PAX vulnerabilities are still here...

I've tried compiling kernel on adeliae and moving it to antarctica, but it also doesn't solve the problem...

I'm completely confused... :/

[PaX Team]

I've tried compiling kernel on adeliae and moving it to antarctica, but it also doesn't solve the problem...

ok, so at least the kernel is out of the loop. what happens if you run say anonmap by hand? could you grab the maps file and the PaX line from status (if you strace it you can suspend it)?

[jeyRocs]

what happens if you run say anonmap by hand? could you grab the maps file and the PaX line from status (if you strace it you can suspend it)?

I don't know exactly what do you mean, I haven't been debugging yet . Here's what I have done:

Code: Select all

antarctica ~ # /usr/lib64/paxtest/anonmap
Executable anonymous mapping             : Vulnerable
antarctica ~ # strace -o anonmap.log /usr/lib64/paxtest/anonmap
Executable anonymous mapping             : Vulnerable
antarctica ~ # cat anonmap.log
execve("/usr/lib64/paxtest/anonmap", ["/usr/lib64/paxtest/anonmap"], [/* 28 vars */]) = 0
uname({sys="Linux", node="antarctica", ...}) = 0
brk(0)                                  = 0x67655cd0348
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x329f2e847000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=15117, ...}) = 0
mmap(NULL, 15117, PROT_READ, MAP_PRIVATE, 3, 0) = 0x329f2e848000
close(3)                                = 0
open("/lib/libpthread.so.0", O_RDONLY)  = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\324V\0\0"..., 640) = 640
lseek(3, 624, SEEK_SET)                 = 624
read(3, "\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0"..., 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=117094, ...}) = 0
mmap(NULL, 1130856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x329f2e84c000
mprotect(0x329f2e85b000, 1069416, PROT_NONE) = 0
mmap(0x329f2e95b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x329f2e95b000
mmap(0x329f2e95d000, 12648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x329f2e95d000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\372\306"..., 640) = 640
lseek(3, 64, SEEK_SET)                  = 64
read(3, "\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0"..., 616) = 616
lseek(3, 680, SEEK_SET)                 = 680
read(3, "\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0"..., 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=1265392, ...}) = 0
lseek(3, 64, SEEK_SET)                  = 64
read(3, "\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0"..., 616) = 616
mmap(NULL, 2248584, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x329f2e961000
mprotect(0x329f2ea7d000, 1085320, PROT_NONE) = 0
mmap(0x329f2eb7c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11b000) = 0x329f2eb7c000
mmap(0x329f2eb82000, 16264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x329f2eb82000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x329f2eb86000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x329f2eb87000
mprotect(0x329f2eb7c000, 12288, PROT_READ) = 0
mprotect(0x329f2e95b000, 4096, PROT_READ) = 0
mprotect(0x67655cc4000, 4096, PROT_READ) = 0
mprotect(0x329f2e845000, 4096, PROT_READ) = 0
arch_prctl(ARCH_SET_FS, 0x329f2eb86db0) = 0
munmap(0x329f2e848000, 15117)           = 0
set_tid_address(0x329f2eb86e40)         = 25916
rt_sigaction(SIGRTMIN, {0x329f2e851278, [], SA_RESTORER|SA_SIGINFO, 0x329f2e857f10}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x329f2e8512f4, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x329f2e857f10}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0x7f1e08bc27c0, 35, (nil), 0}) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\304Pc\344Y2g\331", 8)         = 8
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x329f2e848000
write(1, "Executable anonymous mapping    "..., 43) = 43
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x329f2eb86e40) = 25560
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 25560
--- SIGCHLD (Child exited) @ 0 (0) ---
munmap(0x329f2e848000, 4096)            = 0
exit_group(0)                           = ?
antarctica ~ #

If it is going about something different than I've done above, just get me know. Big THANKS for trying to help me .

[PaX Team]

what happens if you run say anonmap by hand? could you grab the maps file and the PaX line from status (if you strace it you can suspend it)?

I don't know exactly what do you mean, I haven't been debugging yet .

what i need is the /proc/pid/maps and /proc/pid/status files of the anonmap process. the quickest way to get it is to run it via strace (without switches so that strace generates output on the screen and slows down the target) and suspend them with ctrl-z, then you can look up the pid of anonmap and get the two files.

[jeyRocs]

what i need is the /proc/pid/maps and /proc/pid/status files of the anonmap process. the quickest way to get it is to run it via strace (without switches so that strace generates output on the screen and slows down the target) and suspend them with ctrl-z, then you can look up the pid of anonmap and get the two files.

I'm afraid I'm not so quick to do it (it's Intel Xeon 3.2 GHz machine...) . I've even tried to write some short script, which was invoking "strace anonmap" in the background, then trying to get it's pid by simple ps aux & grep & gawk and in the end showing /proc/$PID/maps and /proc/$PID/status... But anonmap (and so some other paxtests I've tried) is also too quick for that script.

Maybe any other idea?

[PaX Team]

Maybe any other idea?

sure, a bit of programming then: add a

Code: Select all

sleep(100);

line somewhere in the doit() function in anonmap.c and recompile it, that should give you enough time.

[jeyRocs]

Okay, I did something like that:

Code: Select all

(...)
/* Call the code in the buffer */
func();
sleep(100);
/* It worked when the function returns */
itworked();
(...)

And here it is.

Code: Select all

antarctica ~ # cat /proc/5468/maps
00000000-00000000 r-xp 00000000 09:05 744908                             /usr/lib64/paxtest/anonmap
00000000-00000000 r--p 00000000 09:05 744908                             /usr/lib64/paxtest/anonmap
00000000-00000000 rw-p 00000000 09:05 744908                             /usr/lib64/paxtest/anonmap
00000000-00000000 rw-p 00000000 00:00 0                                  [heap]
00000000-00000000 r-xp 00000000 09:02 62468                              /lib64/ld-2.3.5.so
00000000-00000000 r--p 00000000 09:02 62468                              /lib64/ld-2.3.5.so
00000000-00000000 rw-p 00000000 09:02 62468                              /lib64/ld-2.3.5.so
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 r-xp 00000000 09:02 62457                              /lib64/libpthread-2.3.5.so
00000000-00000000 ---p 00000000 09:02 62457                              /lib64/libpthread-2.3.5.so
00000000-00000000 r--p 00000000 09:02 62457                              /lib64/libpthread-2.3.5.so
00000000-00000000 rw-p 00000000 09:02 62457                              /lib64/libpthread-2.3.5.so
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 r-xp 00000000 09:02 62456                              /lib64/libc-2.3.5.so
00000000-00000000 ---p 00000000 09:02 62456                              /lib64/libc-2.3.5.so
00000000-00000000 r--p 00000000 09:02 62456                              /lib64/libc-2.3.5.so
00000000-00000000 rw-p 00000000 09:02 62456                              /lib64/libc-2.3.5.so
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:00 0                                  [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0                  [vdso]
antarctica ~ # cat /proc/5468/status
Name:   anonmap
State:  T (stopped)
SleepAVG:       88%
Tgid:   5468
Pid:    5468
PPid:   17107
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 256
Groups: 0 1 2 3 4 6 11 20 26 27
VmSize:     3536 kB
VmLck:         0 kB
VmRSS:       440 kB
VmData:       72 kB
VmStk:        84 kB
VmExe:         8 kB
VmLib:      1280 kB
VmPTE:        28 kB
Threads:        1
SigQ:   0/8185
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000000
CapInh: 00000000fffffeff
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
PaX:    PeMRs
antarctica 5468 #

[PaX Team]

thanks for the data, but unfortunately i'm none the wiser. as far as PaX is concerned, everything looks fine but still the non-exec pages are apparently not enforced. could you post /proc/cpuinfo and readelf -l /usr/lib64/paxtest/anonmap?

[jeyRocs]

So here it is:

Code: Select all

antarctica ~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
stepping        : 3
cpu MHz         : 3200.253
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips        : 6409.52
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
stepping        : 3
cpu MHz         : 3200.253
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips        : 6400.64
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

Code: Select all

antarctica ~ # readelf -l /usr/lib64/paxtest/anonmap

Elf file type is DYN (Shared object file)
Entry point 0xeb0
There are 10 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x0000000000000230 0x0000000000000230  R E    8
  INTERP         0x0000000000000270 0x0000000000000270 0x0000000000000270
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001454 0x0000000000001454  R E    100000
  LOAD           0x0000000000001d20 0x0000000000101d20 0x0000000000101d20
                 0x0000000000000300 0x0000000000000308  RW     100000
  DYNAMIC        0x0000000000001d48 0x0000000000101d48 0x0000000000101d48
                 0x00000000000001c0 0x00000000000001c0  RW     8
  NOTE           0x000000000000028c 0x000000000000028c 0x000000000000028c
                 0x0000000000000020 0x0000000000000020  R      4
  GNU_EH_FRAME   0x00000000000012f0 0x00000000000012f0 0x00000000000012f0
                 0x0000000000000054 0x0000000000000054  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RWE    8
  GNU_RELRO      0x0000000000001d20 0x0000000000101d20 0x0000000000101d20
                 0x00000000000002e0 0x00000000000002e0  R      1
  PAX_FLAGS      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000         8

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .ctors .dtors .jcr .dynamic .got .data .bss
   04     .dynamic
   05     .note.ABI-tag
   06     .eh_frame_hdr
   07
   08     .ctors .dtors .jcr .dynamic .got
   09

[PaX Team]

ok, now we're getting somewhere.

Code: Select all

antarctica ~ # cat /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl cid cx16 xtpr

notice how 'nx' is missing in that line above. this CPU doesn't support the hardware non-exec bit, which is what PaX relies on on amd64 (x86_64), so that explains the paxtest results (except for the executable heap/bss in shared libs tests, but i guess it's more likely a bug in paxtest). in theory it's possible to reimplement the old i386 PAGEEXEC method on amd64 as well but due to the lack of segmentation on amd64, we can't have the speed-up logic that we have on i386/2.6, so i guess you wouldn't be that happy in the end. the best option is to buy a better CPU, i'm afraid.