Critical Linux Exploit In The Wild

If you run servers that provide shell accounts, it’s time to take some preventive measures. At least it is if you are running kernel versions 2.6.37 to 3.8.8, or if you are running RHEL 6 or a clone like CentOS, then the bug was backported to 2.6.32. I ran the exploit myself in a test environment, and it works exactly as expected. Log in as a normal user, compile 100 or so lines of C code, run the executable and you’ve got a root shell. Scary stuff if you manage public shell accounts.

If the exploit is combined with compromising a daemon to gain restricted shell access, the attacker could use this code to remotely gain root access. I can generally get by reading C, but I have to admit that the exploit code is over my head. I can tell from the last two lines that the code sets the uid to zero (root), and returns a new /bin/bash shell. Packet Storm has the entire file available for examination.

This Red Hat Bugzilla thread has several good suggestions for mitigating the risk of your servers being compromized, and given the public attention this bug is now recieving, I expect a fix in the mainstream repositories to show up soon. However, it appears that the bug has existed since 2010, so this raises some important questions. If the bug has been in shipping code for nearly three years, how many servers have already been compromized? Can the full extent of the exploit be calculated? How can we take measures to avoid issues like this in the future?

The original timestamp for the exploit code was 2010, and was updated in 2013 when the bug was backported. One of the often touted benefits of open source software is that bugs get identified and fixed faster than their proprietary counterparts. I’d like to say I’m dissapointed in how this was handled, but in all honesty I can’t. As I stated previously, this code is over my head, so I can’t in good conscious falt anyone else for not catching it.

Reading more into the system I’m reminded of my recent explorations in containers using OpenVZ. I have not tested this yet, but I believe that even if the vulnerability is present in a container OS, the attacker should still be limited to root access inside his container. If anyone can confirm this I’d love to hear about it. Even if the privledge escalation is limited to a container, the overall effect could still be devastating, depending on how the application is architected. Do you keep keys, passphrases, or any client data on in the container? Once an attacker has root access to your box, it’s generally game over.

Personally, I see this as a mark in favor of FreeBSD jails. Not that the BSDs are immune to a similar type of attack, but they do seem to be few and far between. The overall architecture of runnign systems inside of severely restricted jails still looks like the right choice for nearly all environments.