First off, this is the article that almost didn’t happen. If you don’t want to hear this, just skip down to the “All That Aside” heading below, but I encourage you to first read through my little “aside” here first so you can understand what’s happening in this article since it doesn’t follow standard/straightforward blog-authoring technique.

See, I’ve been working on this draft for about three weeks now which covered all of the bases of the concept of hypervisors and a look at the security involved with them and various modes of attack – all of about 3,000 words according to the draft’s word count. But then…

Stuff Came Up

…I got really really busy. The 3,000 word article was seemingly nowhere-near completion, despite it’s length and broad (yet, incomplete) coverage of all the concepts that this article needed to “touch up” on, and yet my non-blog activities continued to grow in time consumption. So I’ve chosen to scrap the borderline-eBook draft entirely and to just sum it up here without going on for ages.

Oh, and just so I can finally publish this article without deferring it to an even later date, I’ve merely placed my sources at the very bottom under their own heading. In other words, if you don’t take my word for it (and why should you?) then hunt for a reliable source in those links. Properly placing them within the article inline with the rest of the text is simply too time consuming since this is being written in raw HTML; this thing would never get published if I had to place them all in the actual text Wikipedia-style.

All That Aside

The basic idea/thesis of this article (and the previous, unfinished draft) is this: hypervisors are getting more and more common, and are growing in deployment in everything from datacenter systems to embedded consumer electronics. But, as their deployment increases, more and more security concerns come into play, including a variety of attack methods and the dire consequences of a compromised hypervisor.

If you know what a hypervisor is, then skip this paragraph: A hypervisor is basically a very minimalist operating system designed with the purpose of abstracting real, physical computer hardware from one or more virtual machines running “above” it (from a layered perspective) – if you’ve ever run VMware player/workstation/Fusion/server atop Windows/Linux/Mac OS, a hypervisor is like that only analogous to running VMware player/server/workstation/fusion directly atop the hardware in the form of an operating system, cutting out the “middleman” OS to favor performance.

What some don’t know about hypervisors is that they utilize a few “dirty hacks” in order to implement some features and optimizations, which aren’t always security-hardened. And I don’t say “dirty hacks” in the sense that the programming is bad – the code is as good as it can be, as far as open source hypervisors can show – but the very practice of their implementation is what I consider “dirty” given their attempt to make the x86/x86-64 architectures do things they weren’t designed to do, therefore leaving a gaping security flaw capable of compromising many systems at once, including the hypervisor itself and all VMs running atop it.

A Likely Scenario

I’ll cut the crap and present a common scenario for you to more easily visualize this: say we have a hypervisor running Windows Server 2xxx (version doesn’t necessarily matter), a Unix OS, and Netware or whatever else your “dream datacenter server” would run. As many seasoned security professionals can tell you, each of these systems are potential attack victims with many possible unpatched exploits running on each system: each platform is running it’s own flawed kernel, flawed processes/services, flawed drivers etc.

Why do I outright accuse them of being flawed? Not to get into the philosophy of IT security, but it’s because they were designed by humans. Unless a team of gods designed everything from the kernel to each device driver to each individual process running in the OS userland, the system will have flaws with necessary patches in the future of the running system. That’s not even considering possible exploitable flaws within the underlying hardware itself, hypervisor-emulated or not.

So if one of these naturally-flawed systems were to be compromised, as is a likely scenario considering that it happens all of the time, then only the individual VM is affected – right?

Wrong.

A New Definition of “Privilege Escalation”

Say for example a bug in a service running on the Windows server were exploited by yours truly, and I gained administrator/root access to the system (or even simple non-administrative code execution, for that matter – read on!)

What follow between the acts of compromising a single hypervisor-controlled VM and the entire series of running systems is largely product-dependent at this point, so I’ll use generic terminology to provide a vendor-independent route of attack that falls just short of actual proof-of-concept code. Again, if I had enough time, I’d actually submit some code proving this…

Basically, a VM communicates with the underlying hypervisor via a “hypercall,” which is essentially the same thing as a system call made by a usermode program to request some I/O service of the OS kernel, only it is made between an OS running atop virtualized hardware to request a specific operation of the underlying hypervisor OS. This is usually accomplished via some code the hypervisor vendor provides for each supported guest OS to enhance performance or it is written by the OS developers themselves using the vendor’s API documentation.

Note that hypercalls and paravirtualization are not the same thing, but are somewhat related in how they operate at the assembly-level and how they are recognized/interpreted by the processor or hypervisor, depending on the operation being streamlined as a paravirtualization optimization.

Right, so there are lower-level system call-esque operations a guest OS can perform to trigger some functionality/behavior from the underlying hypervisor. The key thing to highlight here is that hypercalls are, in most cases, unchecked by the hypervisor as to whether they were invoked by a kernel or usermode program within the guest OS, and also rely on data inputted from the actual code invoking the call. If you have any experience with buffer overflow attacks or anything along those same lines, there’s an alarm going off in your head as you read all of this.

And it gets better – sometimes, the guest OS may not be necessary to compromise prior to the hypervisor’s attack: with VMware’s hypervisors being the most notable case for doing this, hypervisors many times will allow a direct (bypass-the-guest-OS) interface into the hypervisor to allow for remote settings changes as the VMs run. Remote is the key word here: all that code that accepts incoming connections, accepts user input, relies on the flawed SSL/TLS system for encryption and authentication, and which filters packets before routing them via internal virtual networks emulated within the hypervisor using it’s own code are attack vectors that, if exploited, allow the direct compromise of the hypervisor and all running VMs without the need to compromise a guest OS using one of their many flaws as discussed earlier.

Real-World, Documented Example of Such An Attack

Maybe you think all of this is a crock of B.S., and after all, the chances of BOTH a guest OS and the hypervisor itself possessing vulnerabilities serious enough to compromise an entire series of systems are slim, right?

Allow me to refer you to this guy: http://blogs.gartner.com/neil_macdonald/2009/02/20/hypervisor-attacks-in-the-real-world/ – this is a real, documented attack acting on a buffer overflow exploit that allowed an attacker to compromise the hypervisor of a rather unlikely victim for this sort of attack: The Microsoft Xbox 360.

The Xbox 360, as you may have read from that link above, is merely a hypervisor itself: the “Dashboard” presents the hardware in emulated form to the currently-active game, which functions as a heavily-sandboxed guest OS atop the dashboard (presumably, it makes hypercalls to the Dashboard to draw graphics and accept input from other hardware)

This is just one example of how hypervisors are increasing in deployment and thus increasing in security concerns as well. I mean, who would think, after growing up in the Atari/Nintendo era of gaming consoles that something as advanced as a hypervisor would be allowing us to enjoy the games we play? If you look around, you can find even more shocking examples of hypervisors in unlikely places – even mobile phones.

Attack Consequences

So if one were to breach the hypervisor running several varieties of guest operating systems, as in my example earlier, one could use said root access to the hypervisor to commit dirty deeds such as planting rootkits into the memory of running operating system kernels, performing filesystem trickery as a side-effect of having direct, unabstracted/raw access to nonvolatile storage mediums, and pretty much anything one wished to do – after all, you have more control of the running guests than you would in any other scenario.

It’s like having full debugger capability with a running OS kernel (something Linux kernel debuggers may want to look into as a desired scenario)

Final Notes

Please understand that this article isn’t meant to be FUD against using hypervisors or a “we’re all gonna die” cry for attention – I can already predict that somebody will get about halfway down the article, without reading a further-down support of the presented thesis/scenario and immediately flame away within a comment. And I can already predict that said person’s comment will magically disappear during the moderation process with an email sent to said person asking them politely to finish the article before flaming.

The sources I will list below are other blog posts I read as research into this subject in addition to actual practice with a few hypervisors myself, back when I still had some free time. Also linked to is some source code from the open-source Xen hypervisor, which allows a direct look into the process of detecting/validating and processing a hypercall (which is also briefly defined in another Xen Wiki link below)

Much of the standing-flaws with hypervisors and research into the like have been performed against either Microsoft’s Hyper-V or any other private Microsoft-made hypervisor (such as the Xbox 360 Dashboard). While I certainly don’t doubt that Microsoft’s hypervisors are just as (if not more) flawed than the next hypervisor, all of them should be researched and hardened against attacks and as frequently patched as one made by a different vendor.

Don’t let the vendor’s name and image/history provide a false sense of security or cause one not to patch the hypervisor any less than the next product or OS: they all are vulnerable, and as more research is performed to test their security, applying vendor-released patches remains essential in this day and age of rampant exploiting by even more juvenile and not-so-juvenile hackers as each day passes in the sea of limitless information provided by the Internet.

With that final word of advice, I’m ending this article. If it seems long, consider the fact that this after the process of whittling away at my previous, unfinished 3,000 word draft in a desperate attempt to finally publish this thing and get this information out to those who need it the most. Like I said before, this is the article that almost didn’t happen…

Sources/References

Xen Wiki Hypercall formal definition
Securing Hyper-V: a generic overview of potential hypervisor security issues and prevention (Hyper-V specific)
A basic analogy to apply a fundamental security principle to Hypervisor security (“if it’s possible to exploit, don’t assume it won’t be”)
Secunia Advisories for Microsoft Products (dig through here for some MS-specific virtualization exploits, or even other vendors)
A real-world hypervisor security breach: the Xbox 360 Dashboard
Xen source code index for xen.h, the Guest OS interface to Xen (for version 3.3.1; details hypercall parsing and operation)

[Finally, the end of this article...]