Login  |  Register  |  Contact


Thursday, April 17, 2008

VMware: Please Hire The Hoff

By Rich

Do you care about virtualization security?


Then get out of the security or virtualization biz.


Then go read this.


Do you work for VMware?

Good. Go hire the guy that wrote it.

I’ll admit I might be a bit biased; Chris Hoff is a good friend (but I deny my wife’s accusation that we have a man crush thing going on). We’ve been doing a fair bit of work together and have some upcoming speaking gigs. But I like to think I can set my bias aside, that being a major part of my job, and Chris’ post on virtualization security is the best summary of upcoming issues I’ve seen yet.

Rather than repeat his Four Horsemen of the Virtualization Security Apocalypse, I’ll add on with a little advice on what you can do today, while waiting for VMware to hire Chris and get this stuff fixed. These suggestions are very basic, but should help you when you finally do have to run around fixing everything. Flat out, these aren’t anything more than Band-Aids to hold things together until we have the tools we need.

  1. Don’t mix high and low value VMs on the same physical system: If something is really really sensitive, don’t put it on the same VM as the beta version of your new social networking widget. At the least, this will let you apply the same security controls to the entire box, even if you can’t set controls between those VMs on the same hardware.
  2. Threat model VM deployments: Set a policy that security has to work with ops and threat model VM deployments. This will feed directly into the next suggestion, and get security into the game.
  3. Cluster VMs based on similar threat/risk profiles: If you have three VMs facing similar threats, try and group them together on the same physical server. This helps you apply consistent network-level security controls.
  4. Separate VMs where you need security barriers or monitoring in between: Some systems under like-threats still need to be separated so you can still apply security controls. For example, if you need to wall off a database and application, don’t put them on the same physical server which is the equivalent of dropping them into a black hole.

That’s three points that essentially say the same thing- clump stuff together as best as possible so you can still use your network security. Really freaking basic, so don’t pick on me for stating the obvious.

Oh, one last point, maybe try a little information-centric security? Over time we’re going to lose more and more visibility into network communications and won’t be able to rely on our ability to sniff traffic as a data-level security control. Between collapsing perimeters, increasing use of encryption, and data-level security controls, never mind business innovation like virtualization, our network-centric models will just continue to lose effectiveness.


p style=”text-align:right;font-size:10px;”>Technorati Tags: , , , ,


Monday, August 27, 2007

Yes Chris, It’s a Circle Jerk of Pain

By Rich

Hoff owned me. In an email he claimed he pwned me, but he totally didn’t earn that p.

Apparently I’m slightly late to the game in talking about hyperjackstacks (we’re back on virtualization, in case I lost you). That’s something I’m totally willing to concede, especially since I’m more of a data and applications guy.

Chris agrees that this is an important issue, but then asks:

Ultimately though, I think that the point of response boils down to the definition of the mechanisms used in the detection of a malicious VMM/HV. I ask you Rich, please define a “malicious” VMM/HV from one steeped in goodness.

Umm, one that does bad stuff? Like sniff data, mess with things? Du

o, I’m a little buzzed right now from some good organic wine.

Thomas explained things a little better and I think we hit a bit of agreement. Basically, the concern is that if someone compromises the hypervisor somehow, they can do all sorts of badness. Thomas, in the comments to his post, shows how one potential solution is to nudge the hypervisor aside and run checks against it (while you’re unvirutalized, I just made up a word). But I think the real solution is something Hoff mentions that I also mentioned in my post, albeit without the proper name:

Intel TXT ensures that virtual machine monitors are less vulnerable to attacks that cannot be detected by today’s conventional software-security solutions. By isolating assigned memory through this hardware-based protection, it keeps data in each virtual partition protected from unauthorized access from software in another partition.

Yep- dump the problem to hardware. I think that’s where we’re headed, so all this debate serves as a friendly reminder to our big chip manufacturing brethren that probably don’t pay attention to any of our blogs.

But then the bad guys will compromise the hardware, and we’ll defend against that, and then… you get the circle jerk of pain reference yet?

Like everything, it’s always an arms race. Good news is I think this is one of the more manageable problems we face, and the work of Thomas and Joanna will go a long way towards nudging the vendors to reduce our pain.

Can I talk about DLP again now?


Virtualization Security: Are Ptacek/Lawson and Joanna Fighting the Wrong Battle?

By Rich

I’m getting caught up on my blog reading after my big APAC (that’s Asia Pacific) tour with a half-busted Mac, and noticed Tom’s post at Matasano on detecting unauthorized hypervisors. Tom and Nate have been going back and forth with Joanna Rutkowska on how detectable these things might be. For those of you less familiar with all this virtualization stuff, let’s review a little bit.

There are a lot of different types of “virtualization”, but for purposes of this discussion we’re talking about operating system/platform virtualization. For a bit more background there’s always Wikipedia. OS virtualization is where we run multiple operating system instances on a single piece of hardware. To do this most efficiently, we use something called a hypervisor, which (oversimplified) is a shim that lets multiple operating systems run side by side all nice and happy. The hypervisor abstracts and emulates the PC hardware and manages resources between all the operating systems on top (yes you geeks, I’m skipping all sorts of things like Type 1 vs. Type 2 hypervisors and full vs. partial virtualization). Most people today run the hypervisor as software in a “host” operating system, with multiple “guest” operating systems inside. For example, I’m a massive fan of Parallels on my Mac, and use it to run Windows within OS X (I really should upgrade to version 3 soon).

The simple diagram is: 200708270950

First things first; I feel lucky that Joanna and Ptacek (haven’t met Nate yet) let me in the same room as them. They’re smart, REALLY smart. I’ve also never programmed at that level (I was a DB/web application guy) so sometimes I can miss parts of their arguments.

Joanna has been doing some cool work around something called the Blue Pill and virtualized rootkits. To do my usual over-simplification, on a system not already running a hypervisor, the attacker runs code that launches a hypervisor. The hostile hypervisor drops below the host operating system it launched from, virtualizing the host itself. Now everything the user knows about is virtualized and the malicious hypervisor can Do Bad Things unnoticed. Our diagram becomes:


Joanna originally called this undetectable. Thomas and Nate did an entire Black Hat presentation on how they can always detect this, with some blog posts on Nate’s site and at Matasano.

Problem is, they’re looking at the wrong problem. I will easily concede that detecting virtualization is always possible, but that’s not the real problem. Long-term, virtualization will be normal, not an exception, so detecting if you’re virtualized won’t buy you anything. The bigger problem is detecting a malicious hypervisor, either the main hypervisor or maybe some wacky new malicious hypervisor layered on top of the trusted hypervisor.

Since I barely know my way around system-level programming I could easily be wrong, but reading up on Nate and Tom’s work I can’t see any techniques for detecting an unapproved hypervisor in an already virtualized environment. Long term, I think this is a more important issue (especially on servers). Since Intel will be putting some trusted virtual machines on our hardware by default, maybe that’s where we need to look.

Spinning the wrong wheels perhaps?