grsecurity forums

Hi,

i am new to gr-security....I have experience with LIDS and openwall and want to move to grsecurity because of greater flexibilty with acl's and the advantage of a package of rule based system and stack protection.

I build grsecurity with pax on a 2.4.22 kernel without LKM on a redhat 8.0 test system. Regarding acl's everything is fine but the problem comes with pax

I have three kernel's

1. unproteced 2.4.18
2. openwall proteceted 2.4.21
3. gr protected 2.4.22

the ptrace exploit gives me root shell on 1. and 3. so i somehow missed something in my pax configuration ?

[weeny@obelix weeny]$ id
uid=501(weeny) gid=501(weeny) groups=501(weeny)
[weeny@obelix weeny]$ ptrace
sh-2.05b# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
sh-2.05b#


This is what my pax test gives me:

[root@obelix paxtest-0.9.5]# ./paxtest
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 : 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

Because openwall can prevent the ptrace exploit i gues that pax could do the same as well !?

Maybe i made a mistake with my (missing some flags?) acl...on the documentation i found that pax is enabled by default.

Any advice?

regards,

weeny

weeny wrote:I build grsecurity with pax on a 2.4.22 kernel without LKM on a redhat 8.0 test system. Regarding acl's everything is fine but the problem comes with pax

I have three kernel's

1. unproteced 2.4.18
2. openwall proteceted 2.4.21
3. gr protected 2.4.22

the ptrace exploit gives me root shell on 1. and 3. so i somehow missed something in my pax configuration ?

[weeny@obelix weeny]$ id
uid=501(weeny) gid=501(weeny) groups=501(weeny)
[weeny@obelix weeny]$ ptrace
sh-2.05b# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
sh-2.05b#

Because openwall can prevent the ptrace exploit i gues that pax could do the same as well !?

that ptrace bug was fixed in vanilla 2.4.21 itself, so both 2. and 3. should have made the exploit fail (and PaX has nothing to do with it as the ptrace bug is not about memory corruption). if you're using the exploit that leaves a suid root bash behind, did you remove it before running the exploit on 2.4.22/grsec?

Ok ... that's strange, the ptrace exploit should fail anyhow on a 2.4.21 or 2.4.22 kernel (...so possibly not because i was using openewall...)

What exactly do you mean with

if you're using the exploit that leaves a suid root bash behind, did you remove it before running the exploit on 2.4.22/grsec?

I tried to remove

- CAP_SYS_PTRACE

for the default /

but it did not stop the exploit

If you need more information about what i set up please give me information

regards,

weeny

The first time you run the ptrace exploit on a kernel it works on, it'll make itself setuid root. ls -l ptrace to see this. Executing it every time after that is essentially just executing a root shell, and of course will work on any other kernel.

-Brad

well of course youre are right!!

i was so focused on checking whether i made a mistake with grsecurity that i did not check the normal permissions...and like you said they are setuid for root once you launched the exploit for the first time

This is what i did:

1. installed standard redhat

2. launched ptrace and found the system to be vulnerable

3. -> now the ptrace is setuid

4. rebuild kernel with gr on 2.4.22

5. tested ptrace but this time with new permissions so of course ptrace just launched a new shell

6. After i read youre reply i changed the permissions back to 755 and now
i have proper denies from the gr system!

Sorry for bothering you all with my stupid posting

regards,

weeny