grsecurity forums

grsecurity has lots of functions that could prevent localroot 0day which using buffer overflow vulnerabilities,but I thought it can not prevent the localroot 0day without buffer overflow.
ninja monitor the privilege change then kill the process which wannt to be root.it can prevent bo and non-bo localroot 0day.
I hope spender could be kind engouh to improve it when free :)
Anyway,I prefer grsecurity to any other kernel harden patch.spender,thank you very much!

the ninja --> http://forkbomb.org/ninja/

exploit output
[test@centos51 enlightenment]$ ./run_null_exploits.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_sieve.c...OK.
Compiling exp_therebel.c...OK.
Compiling exp_vmware.c...OK.
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.6.31.5 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] CVE-2009-2267: VMWare vm86 guest local root
[6] Wunderbar Emporium: Linux 2.X sendpage() local root
[7] Exit
> 4
------------------------------------------------------------------------------
The person lives most beautifully who does not reflect upon existence.
--Nietzsche
------------------------------------------------------------------------------
[+] Resolved selinux_enforcing to 0xc07a8914 (via System.map)
[+] Resolved selinux_enabled to 0xc067f800 (via System.map)
[+] Resolved security_ops to 0xc07a6e40
[+] Resolved sel_read_enforce to 0xc04c385b
[+] Resolved audit_enabled to 0xc079a1a0 (via System.map)
[+] Resolved mark_rodata_ro to 0xc041d53a
[+] Got ring0!
[+] Detected 2.6 style 4k stacks, with current at 0xdfb3b550
[+] Raised to full old-style capabilities
[+] Disabled security of : nothing, what an insecure machine!
[+] Got root!
sh-3.1# Killed

ninja output
[root@centos51 ninja-0.1.3]# ninja
log: warning: no configuration file specified, using default values
log: ninja version 0.1.3 initializing
log: magic group: gid=0 (root)
log: entering main loop
log: generating initial pid array..
log: now monitoring process activity
log: NEW ROOT PROCESS: sh[32221] ppid=32133 uid=0 gid=0
log: - ppid uid=500(test) gid=500 ppid=32111
log: + UNAUTHORIZED PROCESS DETECTED: sh[32221] (parent: run_null_exploi[32133])
log: - sending signal SIGKILL to pid 32221
log: - sending signal SIGKILL to ppid 32133
log: * offending process(es) terminated
log: NEW ROOT PROCESS: sh[32321] ppid=32233 uid=0 gid=0
log: - ppid uid=500(test) gid=500 ppid=32111
log: + UNAUTHORIZED PROCESS DETECTED: sh[32321] (parent: run_null_exploi[32233])
log: - sending signal SIGKILL to pid 32321
log: - sending signal SIGKILL to ppid 32233
log: * offending process(es) terminated

This is just obscurity, but it's already explained by the author himself in the security section of the manpage: http://forkbomb.org/ninja/ninja.8.txt
It's a reactive measure instead of a preventive one -- we'd like to prevent exploitation from occurring in the first place.

It also seems like the checking is racy and there are a couple ways around the heuristics it uses -- like fork+exit to cause a reparenting to init, making any non-root parent check fail.

-Brad

spender wrote:This is just obscurity, but it's already explained by the author himself in the security section of the manpage: http://forkbomb.org/ninja/ninja.8.txt
It's a reactive measure instead of a preventive one -- we'd like to prevent exploitation from occurring in the first place.

It also seems like the checking is racy and there are a couple ways around the heuristics it uses -- like fork+exit to cause a reparenting to init, making any non-root parent check fail.

-Brad

ninja can only stop script-kids now,because it does not really stop exploit.But sometimes,we always need to defense script-kids more than real hacker.

I thought if grsecurity make the same thing in the kernel level,it can stop exploit in time.I guess.

the recent systemtap-rumtime and glibc localroot exploit seem not to be the buffer overflow way.does grsecurity can prevent the non-patch system away from the two exploit ?

thank you spender.

spender wrote:It also seems like the checking is racy and there are a couple ways around the heuristics it uses -- like fork+exit to cause a reparenting to init, making any non-root parent check fail.
-Brad

Just to clarify a few things;

You are completely right in that ninja uses a reactive model, and that checking is racy as there will be X amount of time between the creation of an offending process and ninja discovering it. The delay is configurable but will never be zero (or lower) -- hence reactionary.

Fork+exit to cause re-parenting to init can be dealt with by enabling "require_init_wlist" in the config. This enforces a requirement that all init owned processes -- processes with ppid 1 -- are explicitly whitelisted.

Ninja is meant to be a "last line of defense," for situations where proactive security models fail. The main goal is to try our best to log instances of unauthorized privilege escalation and alert administrators. This is no where near what proactive solutions such as grsec or selinux (haha) aims to do.

Running a proactive security model such as that provided by grsecurity should always be prioritized, ninja can be added as an extra layer in hopes to catch things that should slip through our proactive security.