Dark Reading on Virtualization Security

Thomas Ptacek | February 26th, 2007 | Filed Under: Defenses, Uncategorized

You probably didn’t notice, dazzled by Dark Reading high point “Top Ten Admin Passwords To Avoid” (see footnote), but they just did a quick feature on virtualization security, and this is something I think you should pay more attention to.

If you’ve been living in a cave: real computers have been obsoleted. In five years, everything is going to be virtualized. Hardware is optimizing for it, hypervisor software is ubiquitous, and it is simply a matter of time before virtualization becomes a basic OS service on mainstream platforms.

I had two answers for how virtualization complicates life for systems security people:

  1. You now face the spectre of guest-hopping attacks, which are vulnerabilities in your hypervisor that allow you to beat VM protection and gain access to other hosts. The driver for these attacks is that a hypervisor has to provide at least the illusion of a “ring 0” for a guest operating system to run in.

  2. If you’re on the same hardware as your target, you have significantly improved timing channels to pry encryption secrets out with.

I have two thoughts on what this implies for security architecture:

  1. I agree wholeheartedly with the product manager at VMWare who says “… one of the key things about hypervisors is their design is simpler than the modern operating system. As a result, they are simpler to harden and lock down…”. With the exception of device emulation, hypervisors have a smaller attack surface than operating systems. Code-rewriting Dynamo-style VM’s like VMWare also have a great degree of control over their clients built into the architecture. So guest-hopping doesn’t keep me up at night.

  2. The answer to this problem is very familiar and very straightforward: segmentation. If you’re a security person in an enterprise, you have an opportunity now, before everything shares the same 12-core, SAN-backed “aggregation server”, to push out a policy that spells out what kinds of applications can safely share the same hardware resources. Unlike the VLAN debacle, you might actually have a chance at enforcing this one, if you start early enough.

A couple other (predictable) comments:

  1. I’d ignore “Hypervisor IPS”. There’s little evidence that IPS has improved security at the OS or network level, and the companies that produce those products uncover significant vulnerabilities in the course of improving their products every year. Right now there is zero evidence to suggest that hypervisor IPS is anything but snake oil, and zero hypervisor research findings to back the concept up.

  2. I’d also ignore “hypervisor malware”; as we asserted earlier, “ring -1” is actually kind of a crappy place to hide a rootkit, because you’re a simpler target to look for when you’ve interposed yourself between the entire OS and the hardware.

Footnote:

(For the record, they include: (username), (username)123, 123456, password, 1234, 12345, passwd, 123, test, 1, along with shockers like changeme, dontforget, letmein, root, default, system, attack, cisco, tiger, public, sun123. Damn, they got me! But don’t worry; all “root” gets you is the raw data, which is easier to read on the web site anyways.)

Viewing 20 Comments

    • ^
    • v
    Isn't it your hypervisor IPS that's likely to find your hypervisor malware? How can you ignore both?
    • ^
    • v
    how about hypervisor IDS i.e. xenaccess?
    • ^
    • v
    Larry, I think you're conflating AV with IPS. Hypervisor AV has some value, albeit minimal (there are two hypervisor rootkits I know of and both are proof-of-concept and we own one of them). I predict Norton AV and McAfee will both have this checkbox by 2008.

    Hypervisor IPS sits in, above, or alongside your conventional hypervisor, and attempts to intercept attacks on the hypervisor, thus ostensibly preventing guest-to-guest attacks. There will be, I predict, 6 of these types of vulnerabilities in VMWare ESX over the next 8 years. Of them, 1 will be detectable by a shipping "Hypervisor IPS" within 6 months of the attack's disclosure on Bugtraq. You tell me whether it's worth it.

    Hypervisor IPS will have no play vs. Hypervisor Malware; by the time you've cracked ring -1, you're already implicitly past any IPS installed on the machine.
    • ^
    • v
    Was this the article you meant the first link to go to?
    • ^
    • v
    Er, yes. Thank you. =)
    • ^
    • v
    just a minor additional point: everyone in the 'security through virtualization debate' seems to be taking for granted that all guest to guest and guest to host communications and data/code context switches WILL be effectively mediated by the hypervisor. That is not necessarily so.
    • ^
    • v
    Thomas:

    The key factor for securing virtual servers behind the hypervisor will be a shield layer (within the hypervisor) that decodes protocols, etc. The idea of signatures for virtual server protection is dead:

    http://alwayson.goingon.com/permalink/post/9944

    G
    • ^
    • v
    A Nemertes Issue Paper: Securing Virtualized Infrastructures

    http://www.bluelane.com/lib/pdfs/SecuringVirtua...

    To insert Andreas into the discussion... I think there will be at least two panels in Vegas during Interop week on this topic. I think Andreas is moderating one of the panels (Interop Data Center Summitt; Art Wittmann the other(Interop). FYI

    G
    • ^
    • v
    I hope Andreas came cheap. "Virtual Shield" is a Blue Lane brand; it's a bit of a tip-off when your independent analyst puts your brand in the title of his paper.

    I think there's a decent claim to be made for "the network security device that will sit between VMs because it's hard to filter between VMs".

    Of course, I also think modern enterprises are so far from having reasonable access control between the VLANs they already use without virtualization that it's not a "next 18 month" priority to install them.

    I think there's no claim to be made for the need to protect OS's from malware that will attack either hypervisors or kernel-level security products.
    After-market hypervisor security products introduce exactly the same types of security problems that after-market kernel security products do.
    • ^
    • v
    Wasn't Blue Lane the company selling "no patching" IPS? So I guess the marketing message is "protect the OS^H^Hhypervisor". Isn't my firewall really a "no patching" Windows SMB appliance?
    • ^
    • v
    Thomas:

    We'll talk to you soon. That way we can give you a clearer picture of what we're doing and where.

    Nate:

    http://www.bluelane.com FYI- emulating the security functionality of the patch isn't patch replacement, except in the case of impossible to patch systems. In the case of hard to patch, it allows for a saner, lower risk schedule. I provided a link to our website.
    • ^
    • v
    Also see the recent bugtraq post about xbox360 hypervisor privelege escalation vulnerability which allowed for running unsigned code (this is different from DVD firmware patching which has allowed for pirated signed code to run since about a month after the xbox release):

    http://www.securityfocus.com/archive/1/461489/3...

    Repeat after me: there is no silver bullet.
    • ^
    • v
    There is no silver bullet. Probably never will be a silver bullet. Virtualization WILL erode the efficacy of static security solutions; and the best approach will be data center-centric vs trying to secure specific apps or tune signatures or play the hardware assist arms race.
    • ^
    • v
    No matter what new technology they come up with, there will be room for scanning and detecting products like my VAM scanner and Strataguard IPS. Regardless of the hyporvisor we can still scan the guest OS and detect mallicious code and vulnerabilities. It also doesn't stop out Safe Access NAC product which is equally effective at nipping the malware bud before it hits your network. We're also adding hypervisor detection in the next version of safe access.
    • ^
    • v
    I don't see the difference between 1. dropping a connection when there's an attempt to exploit a known flaw (IPS) and 2. "emulating" a patch when someone tries to exploit a known flaw (you). Do you really want to try to keep providing service to a clear attacker?

    And so my firewall is even better since it handles 0-day neither approach can predict.
    • ^
    • v
    Patches don't typically (merely) drop connections because availability is of prime importance. They correct the traffic in a multitude of ways. Dropping connections does work some time, but it isn't a "silver bullet" either. Blocking needs to be highly accurate for starters (operational consequences) and there are cases where even accurate session interrupts can enable denial of service attacks.

    If it was the case (no difference between the block and the patch correction) then I'm assuming that your team doesn't patch... because there is a perception that IPS sig, etc blocking and firewalls settings have everything covered. Our position... patch on your schedule because we've applied the patch's security characteristics (multi-facted correction).

    The point of my earlier posts is that virtualization is inevitable and WILL change the security requirements for the network: complexity will mushroom; server counts will escalate and processing power/apps will be more mobile than ever, eroding the value proposition of security tech tied to physical location. The homerun is that with the right technology/practices in place virtual environments can be MORE secure than their physical environment counterparts. But it will require new thinking.
    G
    • ^
    • v
    Mitchell, I don't understand what you mean by "hypervisor detection".
    • ^
    • v
    @mitchell: I did not understand a word of your comment. Who are "they" and who are "we"? What's a VAM scanner? what's that stratathing IPS? are you talking about VMM security or running a surreptitious marketing campaign on security blogs? "nipping the malware bud before it hits your network"?! whoah! did you come up with that phrase yourself? do not worry, *we* are adding DMA-capable devirtualization agents with hypermophic payloads (tm) in on upcoming release RSN, it will roll up your NAC thing and smoke it for breakfast!
    @nate: attack behavior does not necessarily imply that the source of traffic is the real attacker, sometimes tearing down sessions -even if they are clearly part of an attack- could have unwanted consequences somewhere back/up-stream towards the traffic's source. I don't want some stupid thing reseting TCP sessions because it 'knows' an attack is going on and making some other stupid thing upstream blackhole the dst or src net because something is 'miss-behaving', let the transport layer be IFF you can deal with the issues at the app layer. That is a huge IFF and i'm yet to see this so called virtual-patching dealing with it and if it really is any different than an IPS
    @greg: Would you elaborate on the last comment? It seems obvious that with the right technology/practices anything can be more secure than something else without them but how is it that virtual environments are inherently more secure than their physical counterparts? a virtualized solaris still runs telnetd and Mitchell's "we" (or "they") can still own it with -fbin.
    • ^
    • v
    The hypervisor clear text layer is a point of profound control/leverage over what goes on behind the hypervisor. While virtualization brings heightened mobility, complexity and quantity issues, it introduces a powerful point of leverage for protecting pools of processing power, with one off and group policies, corrections, access, etc.

    Again, the virtual processor pool WILL require new thinking, new approaches... that are not tied to physical location, etc. As I wrote in my Always On blog referenced earlier I think it is the beginning of the end of static security.
    • ^
    • v
    Mitchell: The fluid nature of virtual environments meet scans can be rendered obsolete in the blink of an electron. The only way to stretch the time value of a scan is to set up policies that make virtualization less flexible... limit server creation and mobility capabilities to a predictable schedule. But who would virtualize only to try to run the virtual environment in the same way as the physical world? Does that really make sense?

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus