grsecurity forums

hi, does the kernels with grsecurity patch 2.1.5 be vulnerable to the Linux kernel ELF core dump privilege elevation ?

Some vuln details:

Kernel Vuln Version:
2.2 up to and including 2.2.27-rc2
2.4 up to and including 2.4.31-pre1
2.6 up to and including 2.6.12-rc4

( so at this moment there aren't any kernel bug free )

Url: http://www.isec.pl/vulnerabilities/isec ... redump.txt

Thanks

NeedSecurity wrote:hi, does the kernels with grsecurity patch 2.1.5 be vulnerable to the Linux kernel ELF core dump privilege elevation ?

if you enforce SEGMEXEC on all your executables (and users) then the integer overflow cannot occur hence you're safe (who would have thought that the halved address space could be a security feature itself , otherwise you're vulnerable. so if you're a chpax/paxctl user then you're vulnerable, if you use the ACL hook then it depends on your policy.

Code: Select all

[andreas@maskros ~]$ ./elfcd.sh
[+] Compiling...elfcd1.c: In function `main':
elfcd1.c:48: warning: implicit declaration of function `strlen'
elfcd1.c:54: warning: implicit declaration of function `memset'
elfcd1.c:60: warning: implicit declaration of function `strcmp'

[+] ./elfcd1 argv_start=0x5b3f6bce argv_end=0x5b3f6bd6  ESP: 0x5b3f6a20
setrlimit: Operation not permitted
[andreas@maskros ~]$


2.6.11.7 with grsec + SEGMEXEC enabled

OK, so not to sound like a total n00b, but my 2.6.11.7 kernel has SEGMEXEC also enabled in the .config:

CONFIG_PAX_SEGMEXEC=y
CONFIG_PAX_DEFAULT_SEGMEXEC=y

So is there anything else that needs to be done to enable this system wide? (ie, does an RBAC ACL need to be created to do this, or will the default disabled gradm ACL's do this?)

On my box, I see this:

./elf.sh
[+] Compiling...elfcd1.c: In function `main':
elfcd1.c:48: warning: implicit declaration of function `strlen'
elfcd1.c:54: warning: implicit declaration of function `memset'
elfcd1.c:60: warning: implicit declaration of function `strcmp'

[+] ./elfcd1 argv_start=0x5b2e53cb argv_end=0x5b2e53d3 ESP: 0x5b2e5260
[+] phase 1
[+] AAAA argv_start=0x5fa2a856 argv_end=0x5fa2a85a ESP: 0x5fa2a720
[+] phase 2, <RET> to crash ./elf.sh: line 183: 1089 Killed ./elfcd1

But, if I run the exploit itself, it seems to work...

./elfcd1

[+] ./elfcd1 argv_start=0x5f515feb argv_end=0x5f515ff3 ESP: 0x5f515e80
[+] phase 1
[+] AAAA argv_start=0x5f0d2f5a argv_end=0x5f0d2f5e ESP: 0x5f0d2e30
[+] phase 2, <RET> to crash Killed

linuxuser wrote:OK, so not to sound like a total n00b, but my 2.6.11.7 kernel has SEGMEXEC also enabled in the .config:

CONFIG_PAX_SEGMEXEC=y
CONFIG_PAX_DEFAULT_SEGMEXEC=y

So is there anything else that needs to be done to enable this system wide? (ie, does an RBAC ACL need to be created to do this, or will the default disabled gradm ACL's do this?)

it is enabled systemwide but what matters more is whether it's mandatory or not. if you're using the ELF marking only then it's discretionary control and any local user can simply turn it off on his exploit whereas through the ACL system you can enforce it on everything.

But, if I run the exploit itself, it seems to work...

./elfcd1

[+] ./elfcd1 argv_start=0x5f515feb argv_end=0x5f515ff3 ESP: 0x5f515e80
[+] phase 1
[+] AAAA argv_start=0x5f0d2f5a argv_end=0x5f0d2f5e ESP: 0x5f0d2e30
[+] phase 2, <RET> to crash Killed

if the 'exploit' had worked then you wouldn't be copy/pasting this as your box would be hosed for good. as i explained it in the previous comment, under the SEGMEXEC address space layout it's impossible to create a > 2GB environment (or any mapping for that matter) hence the integer overflow cannot occur.

Again, please excuse my ignorance, but how withregard to this statement:

it is enabled systemwide but what matters more is whether it's mandatory or not.

So how do you make it mandatory?

linuxuser wrote:So how do you make it mandatory?

doh, i spoke too fast, apparently grsec can still only disable PaX flags, not set them, which is what you'd need for mandatory control. i'll bug spender about it, in the meantime you can use RSBAC or SElinux (to the dismay of all grsec fans, no doubt .

2.6.11.9 fixes these problems, correct ?

Has anyone tried the limits.conf workaround?

Hi,

im running Systems with IA64 and NX .... i enabled Pagebased Memory Protection and i have TWO Questions ...

1. Am i safe of this Bug
2. Is KERNEL Memory also marked as non exec, as this bug seems to rely on kernel stack memory, or am i wrong in this point ?

Thanks for help !

Simon

so that means , PAGEBASED NONEXEC doesnt protect ?

mikeeusa wrote:The way to disable this yet-another MASSSIVE linux exploit is to disable coredumps:
ulimit -H -c 0

(perhaps add to /etc/profile)

also edit /etc/security/limits.conf

# prevent core dumps
* hard core 0

make sure /etc/security/limits.conf is readable by all users.. LEST IT NOT WORK!

mikeeusa, my #man ulimit doesn't mention -H or -c0 .. I am guessing it is "-Hard" and "-core0" like in limits.conf.

Isn't it true that most users don't need this capability anyway? Am I right that core dumps are really only needed to test and debug software?

Excuse my ignorance.

mikeeusa wrote:

Dodger wrote:so that means , PAGEBASED NONEXEC doesnt protect ?

Correct, TMK.
DTwR.

Kernel Adress Space ISNT Overflow Protected ?????

Can anyone of the developers say something here to these details ?? AFAIK relies this exploit on an overflow in kernelspace ..... right ?

So , is Kernel Address Space NOT PROTECTED against overflows ??

thanks for reply mike , but if you donbt know , what you are talking about, let someone else answer my question.