Grsec kills Glibc 2.3.4

[bens]

I'm running kernel 2.6.10 with grsec patches (gentoo's 2.6.10-hardened-r3). I have deactivated all PaX protections on /lib/ld-linux.so.2 (a symlink to ld-2.3.4.so), but when I try to run it, it gets killed instantly. If I reboot into vanilla 2.6.10, ld-linux.so.2 runs normally, and is not killed. How can I make grsec/pax stop killing ld-linux.so.2?

Here's what happens when I try to run it:

Code: Select all

plan9 root # /lib/ld-linux.so.2
Killed

And here's the output of paxctl as proof that I've deactivated all the PaX restrictions.

Code: Select all

- PaX flags: -p-s-m-xE--r [/lib/ld-linux.so.2]
        PAGEEXEC is disabled
        SEGMEXEC is disabled
        MPROTECT is disabled
        RANDEXEC is disabled
        EMUTRAMP is enabled
        RANDMMAP is disabled


Also, I tried changing the execstack setting, but this has not had any effect:

Code: Select all

bash-2.05b$ execstack -q /lib/ld-linux.so.2
X /lib/ld-linux.so.2

Why is grsec killing ld-2.3.4.so?

[PaX Team]

I'm running kernel 2.6.10 with grsec patches (gentoo's 2.6.10-hardened-r3). I have deactivated all PaX protections on /lib/ld-linux.so.2 (a symlink to ld-2.3.4.so), but when I try to run it, it gets killed instantly.

what's your glibc version? glibc-2.3.4.20041102 works as expected (on 2.6.11-rc5).

And here's the output of paxctl as proof that I've deactivated all the PaX restrictions.

Code: Select all

- PaX flags: -p-s-m-xE--r [/lib/ld-linux.so.2]

well, emutramp is still enabled, but in any case, that should not play a role. what does strace tell you?

Code: Select all

bash-2.05b$ execstack -q /lib/ld-linux.so.2
X /lib/ld-linux.so.2

it's weird, on my system ld.so doesn't have an executable PT_GNU_STACK, something must be wrong on your side, ld.so most definitely doesn't need an executable stack (i also suggest that you open a gentoo bugzilla entry about it).

[bens]

from "emerge info": glibc-2.3.4.20040808-r1

Unfortunately, I get no joy from strace:

Code: Select all

bash-2.05b$ strace /lib/ld-linux.so.2
execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2"], [/* 56 vars */]) = 0
+++ killed by SIGKILL +++

Also, ld-linux.so.1 and ld-linux.so.1.9.11 both segfault, but I haven't compared this behavior against a non-hardened kernel.

Code: Select all

bash-2.05b$ strace /lib/ld-linux.so.1
execve("/lib/ld-linux.so.1", ["/lib/ld-linux.so.1"], [/* 56 vars */]) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fff000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

I'll fiddle around a bit more with glibc, then file a gentoo bug report. Thanks.

[bens]

Fixed by a recompile+reinstall of Glibc, same version, same compiler, same compiler options. Very odd indeed, but almost certainly not your problem.

[PaX Team]

from "emerge info": glibc-2.3.4.20040808-r1

Unfortunately, I get no joy from strace:

Code: Select all

bash-2.05b$ strace /lib/ld-linux.so.2
execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2"], [/* 56 vars */]) = 0
+++ killed by SIGKILL +++

ok, so it's one of the checks during execve() that doesn't like this ld.so. could you try 2.6.11-rc5-pax (which works for me)?

Also, ld-linux.so.1 and ld-linux.so.1.9.11 both segfault, but I haven't compared this behavior against a non-hardened kernel.

same here, i guess this old version wasn't meant to run standalone (or got screwed up over the years).

[bens]

Unfortunately, I didn't have the foresight to save the borked ld-2.3.4.so. If it happens again, I'll be sure to keep it for closer inspection.

Good luck with a great project,
Ben