So you've checked the kernel version with 'uname -a', googled it and found that that version is vulnerable to X. The next step is to find the exploit. You wget, gcc it, run it and ... it crashes leaving the system either unusable or simply reboots. What are your thoughts?
- The exploit is fake. The author is a retard. It doesn't work! Did I just backdoor my system with this sequence of hex characters in the payload?
- The system is patched or the kernel is not vulnerable.
Well, if the exploit crashed the system, then the kernel is likely to be vulnerable. But you need at least some basic understanding of how the exploit works. Does it rely on fixed memory addresses, access data or execute instructions located at memory addresses in user-space?
Let me give you an example. The perf_swevent_init exploit for Ubuntu 12.04.0-2 x64 systems that can be found here. I've recieved a few comments saying that it crashes the system. First, there are a number of fixed 'target' addresses that are specific to 12.04.0, 12.04.1 and 12.04.2 only. If the exploit is used against a different vulnerable kernel version/distribution, it's likely to result in a page fault due to incorrect memory addresses.
The other thing that is very important from the exploitation point of view is whether SMEP (Supervisor Mode Execution Protection) is enabled. Third generation Intel processors (Ivy Bridge) provide this mechanism of "blocking malicious software attacks from user mode code when system is running in the highest privilege level" (Page 46 in this datasheet). What that means is if the kernel running in ring0 tries to execute code located in user-space, you will get a page fault instead of your new shiny # shell.
So what can we do to check if SMEP is actually enabled on the target? /proc/cpuinfo is world-readable (correct me if I'm wrong) on most distributions and provides the CPU information that includes various extensions and features supported by the CPU:
vnik@blah:~$ grep smep /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc up arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx f16c rdrand hypervisor lahf_lm ida arat epb xsaveopt pln pts dts fsgsbase smep
If you see smep in the list and your exploit does not implement any SMEP-bypassing techniques (e.g., in-kernel ROP), do not run it! All you'll get is a page fault that is likely to be followed by a restart.