kernel 2.6.17-2.6.24.1 vmsplice localroot exploit

[law]

Hey all, just thought I'd let you all know that the localroot exploit that broke on Slashdot here: http://it.slashdot.org/it/08/02/10/2011257.shtml
"sort of" affects our boxes with grsec on them. We have a whole bunch of Debian (Etch and Sarge) servers running kernel 2.6.23.something with grsec 2.1.11 on them, the published code *does* give a root terminal, however (at least with our configuration) it does not grant access to /sbin/gradm and the grsec permissions seem to hold (at least, with the 10 minutes of poking around on it I was able to do). One side effect is that the "rooted" grsec machine will lock up ~5-10 minutes after the exploit is run, which does leave us a bit open for a DoS attack I guess. Anyway, just thought I'd let you folks know our experience with this fairly well-publicized 'sploit, hope it helps someone!

--law
p.s. dear dev team: any word on when "testing" grsec is gonna roll over to "stable" any time soon? Just curious!

[law]

Actually, scratch that "does not allow access to /sbin/gradm" bit. I've found that I can run "su" after successfully running the exploit, get a "proper" root terminal, and then gradm -a admin will prompt me for a password. I still need the correct password, which helps, but it's just one more level of isolation that ne'erdowells can get past. Again, hope this helps!

--law

[erikd]

Baaah.. where is grsec for 2.6.24

[Friend]

There is a bugfix in the new kernel http://kernel.org/pub/linux/kernel/v2.6 ... g-2.6.24.2 for that exploit so we all wait for the new grsecurity patch

[erikd]

Ok, I found a patch that i could use on my 2.6.22.9-grsec kernel to stop the exploit *phew*
The patch is found in this thread: http://www.gossamer-threads.com/lists/linux/kernel/877554

(Just hope it dont break anything before a grsec release is out for 2.6.24 that i planned to upgrade to anyway because of a bug in quicklist.c )

[hanno]

This might be interesting for others as well:
I just updated our production kernels to 2.6.23.14 + grsecurity-2.1.11-2.6.23.14-200801231800.patch + patches for splice-issues (splice1 and splice2 from http://files.hboeck.de).
splice1 and splice2 are split-out from the .14-to-.15 and .15-to.16 patch. Tested and it stops the exploit from working.

This gives you a working grsecurity + exploit-fix kernel.

I've blogged this in my companies weblog (only in german):

http://www.schokokeks.org/blog/local_ro ... nux_kernel

[specs]

Am I the only one who gets errors using grsecurity without additional patches?
Or did I make an error during patching?

$ ./vmsplice_exploit
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x4fff6000 .. 0x50028000

Message from syslogd@navi at Tue Feb 12 19:22:43 2008 ...
navi kernel: PAX: suspicious general protection fault: 0000 [#6]
navi kernel: PREEMPT
navi kernel: EIP: 0060:[<00065ffe>] Tainted: G D VLI
navi kernel: eax: 00001000 ebx: 00000004 ecx: 00000000 edx: f1b75d6c
navi kernel: esi: f1b75f1c edi: ffffffe0 ebp: 00000001 esp: f1b75da8
navi kernel: Call Trace:
navi kernel: ds: 0068 es: 0068 fs: 0000 gs: 0033 ss: 0068
navi kernel: Process vmsplice_exploit (pid: 3048, ti=f1b74000 task=f6a69000 task.ti=f1b74000)
navi kernel: Stack: 00000003 f49a1c28 00000030 00000000 fffcffff 58f3b0fc 00000030 00000000
navi kernel: 00066341 ffffffd0 00000000 00000000 f1b75ec4 00000000 00000397 00000003
navi kernel: f6df85c0 f49a1c00 00000000 00000001 00000000 00000030 0000014c 00000000
navi kernel: [<00066341>] <0> [<00032bf2>] <0> =======================
navi kernel: Code: 00 00 00 e8 e1 b6 fa ff 8d 43 28 b9 01 00 02 00 ba 1d 00 00 00 e8 4c 04 ff ff 8d 1c ad 00 00 00 00 eb 0f 8b 06 45 01 d8 83 c3 04 <8b> 00 e8 c8
0a fd ff 3b 6c 24 08 72 eb 83 c4 10 89 f8 5b 5e 5f
navi kernel: EFLAGS: 00010202 (2.6.23.15-grsec-200801231800-1 #1)
navi kernel: CPU: 0
navi kernel: EIP: [<00065ffe>] SS:ESP 0068:f1b75da8
Segmentation fault

[favoretti]

I tried applying 2.6.23.14 patch onto 2.4.24.1 kernel this morning, but apparently the guys hacked way too much for the patch to apply without major hassle. Mostly it has to do with the split of certain things under arch/ into _32 and _64 parts.

So, what I wanted to ask is - is there any chance we'll see grsec patch for 24.2 in the near future?

Would be greately appreciated.

Vladimir

[spender]

A test patch for 2.6.24.2 has been uploaded to the server.

-Brad

[erikd]

Compiled 2.6.24.2 + grsecurity-2.1.11-2.6.24.2-200802131959.patch ok.
But during bootup this shows up in the logs(for diffrent /kernel/grsecurity/things, just an example below):

Feb 14 09:14:25 kernel: sysctl table check failed: /kernel/grsecurity/dmesg .1.98.36 Unknown sysctl binary path
Feb 14 09:14:25 kernel: Pid: 1, comm: swapper Not tainted 2.6.24.2-grsec #2
Feb 14 09:14:25 kernel: [<c042d05d>] set_fail+0x42/0x44
Feb 14 09:14:25 kernel: [<c042d29b>] sysctl_check_table+0x103/0x314
Feb 14 09:14:25 kernel: [<c042d28c>] sysctl_check_table+0xf4/0x314
Feb 14 09:14:25 kernel: [<c042d28c>] sysctl_check_table+0xf4/0x314
Feb 14 09:14:25 kernel: [<c0225b1f>] 0xc0225b1f
Feb 14 09:14:25 kernel: [<c02332e2>] 0xc02332e2
Feb 14 09:14:25 kernel: [<c0225955>] 0xc0225955
Feb 14 09:14:25 kernel: [<c04899bd>] get_inode_number+0x2e/0x52
Feb 14 09:14:25 kernel: [<c0489d26>] proc_register+0x3b/0x9f
Feb 14 09:14:25 kernel: [<c0489f98>] create_proc_entry+0x61/0x92
Feb 14 09:14:25 kernel: [<c0436270>] register_irq_proc+0x7e/0x95
Feb 14 09:14:25 kernel: [<c0489f16>] proc_mkdir_mode+0x33/0x48
Feb 14 09:14:25 kernel: [<c0225b1f>] 0xc0225b1f
Feb 14 09:14:25 kernel: [<c0225b80>] 0xc0225b80
Feb 14 09:14:25 kernel: [<c0403b37>] kernel_thread_helper+0x7/0x10

[spender]

I'll have it fixed tonight. It's due to more stupidity from Eric Biederman's sysctl rewrite. All the grsec sysctl entries have to now also be listed in sysctl_check.c.

-Brad

[spender]

I've uploaded an updated patch that should fix this issue and some other PaX issues as well.

-Brad

[salam]

just an idea, but would't it be possible to implement a feature which will disallow any uid/gid changes for any binary not executed from a trusted path? something like a TPE for userID changes. i'm not a programmer, so i'm totally unsure if this is possible, but if it was, it would also stop any privilege escalation bug which is not directly within system binary(which the user has to run from his homedir). for me,with this exploit, TPE did its job well, but sometimes, you have users who you allow to execute in their homedirs....

[PaX Team]

just an idea, but would't it be possible to implement a feature which will disallow any uid/gid changes for any binary not executed from a trusted path?

it's not possible because in cases like this it's not the kernel's own code changing the UID but that of the attacker. so to stop this kind of attack you want to prevent the execution of the attacker's code.

it's a hard problem in general on localhost and even we are far from full coverage (TPE/UDEREF/KERNEXEC can and do prevent exploitation in specific cases only like here, not in general), and most other systems are pretty much sitting ducks in this regard.

the lesson to take home is that if you have untrusted local users able to execute their own code then you'll be always vulnerable. note that 'code' here doesn't necessarily mean machine code, it can be scripts as well if the given script intepreter is powerful enough to express the exploit code in that language.

i think this vmsplice exploit could be rewritten in say python and then that'd shift the 'code execution' problem into userspace, for which noone provides any protection (ok, i hear certain NetBSD folks have an idea or two, hi setxhi , there's not even enough awareness of this, although that's understandable as long as normal machine code execution attacks are so much easier (and possible).

obviously you can use TPE on the script interpreters as well, but that's the proverbial 'baby goes with the bathwater' kind of solution and can be only used as a temporary stop-gap measure, not something constantly on. so as i said, the generic problem is left unsolved for now.

[I_Vladimirov]

Hello,
I have been working on solution for hardening my web servers and using grsecurity patch mainly in chroot environment what while
happened if some one useing this exploit get root uid in chrooted environment when kernel with grsecurity is used ?
Is it posible to escape its chroot jail. and damage the system.