Ed Skoudis and Mike Poor were kind enough to invite me to sit in on their recent SANS webcast round-table about emerging security threats. During the webcast I was discussing some emerging attack trends against the Linux kernel, which I thought I would also jot down here for those of you who don’t have time to sit down and listen to the webcast recording.
Over the last several months, I’ve been observing a noticable uptick in the number of denial-of-service (DoS) conditions reported in the Linux kernel. What that says to me is that there are groups out there who are scrutinizing the Linux kernel source code looking for vulnerabilities. Frankly, I doubt they’re after DoS attacks– it’s much more interesting to find an exploit that gives you control of computing resources rather than one that lets you take them away from other people.
Usually when people go looking for vulnerabilities in an OS kernel they’re looking for privilege escalation attacks. The kernel is often the easiest way to get elevated priviliges on the system. Indeed, in the past few weeks there have been a couple   of fixes for local privilege escalation vulnerabilities checked into the Linux kernel code. So not only are these types of vulnerabilities being sought after, they’re being found (and probably used).
Now “local privilege escalation” means that the attacker has already found their way into the system as an unprivileged user. Which begs the question, how are the attackers achieving their first goal of unprivileged access? Well certainly there are enough insecure web apps running on Linux systems for attackers to have a field day. But as I was pondering possible attack vectors, I had an uglier thought.
A lot of the public Cloud Computing providers make virtualized Linux images available to their customers. The Cloud providers have to allow essentially unlimited open access to their services to anybody who wants it– this is, after all, their entire business model. So in this scenario, the attacker doesn’t need an exploit to get unprivileged access to a Unix system: they get it as part of the Terms of Service.
What worries me is attackers that pair their local privilege escalation exploits with some sort of “virtualization escape” exploit, allowing them hypervisor level access to the Cloud provider’s infrastructure. That’s a nightmare scenario, because now the attacker potentially has access to other customers’ jobs running in that computing infrastructure in a way that will likely be largely undetectable by those customers.
Now please don’t mistake me. As far as we know, this scenario has not occurred. Furthermore, I’m willing to believe that the Cloud providers supply generally higher levels of security than many of their customers could do on their own (the Cloud providers having the resources to get the “pick of the litter” when it comes to security expertise). At the same time, the scenario I paint above has got to be an attractive one for attackers, and it’s possible we’re seeing the precursor traces of an effort to mount such an attack in the future.
So to all of you playing around in the Clouds I say, “Watch the skies!”