First published on TECHNET on Apr 07, 2008
Our resident VM security dev lead, Brandon Baker,
posted a blog
today about isolation of VMs. Brandon shares his thoughts on VM security, many of which he also shared to attendees of the BlackHat security conferences in U.S. and Japan last year. Brandon discusses the design goals of Hyper-V development and areas of focus. Here's an excerpt:
The reason this matters so much is that a compromised physical machine almost always has only one way to get at other machines - through the network. Ideally we want virtual machines to have this same security model, but if you have lots of channels out of a VM and a wide attack surface in your virtualization software then you present new ways for malicious software to jump the gap. It would be like having to worry about software from one physical machine finding its way across the carpet into all of the other machines in the same room. This is not something that a system administrator or security professional wants to worry about.
Instead, security professionals talk about one common theme: reducing risk. An established way of doing this is through reducing your attack surface. The logic here is clear - if you present a smaller surface to an adversary you stand a better chance of defending yourself. We’ve taken that to heart in Hyper-V by separating our hypervisor from the rest of the virtualization software and device drivers that run in the dedicated service, or “root,” partition, limiting the number of channels and touch points into and out of a VM, creating per VM worker processes for all of our emulated devices that live way up in unprivileged processes in the root partition far away from the hypervisor, and providing tools to minimize the environment in the root partition with Server Core. We’ve also made it easy and advisable to not run any additional software in the root partition. I was
quoted as saying
“The last thing I ever want to hear as a security engineer is 'it's a feature, not a vulnerability’,” and I firmly believe this is the right attitude when thinking about virtualization security.
I expect to read/hear more on the topic of VirtSec from the
RSA 2008 conference
, going on this week. I know Citrix's Simon Crosby is speaking on a panel there, and given Simon's propensity and ability to be quoted, I'm looking forward to it. I'm certain he'll be better off than
Oded Horovitz was up in Vancouver
.
Patrick O'Rourke
UPDATE
: the following question was submitted by a reader: "How does vulnerability in VMBus will affect the VM isolation? All VMs (ideally) will go through VMBus. So, doesn’t it affect VM isolation if one can exploit VMBUS? They may gain system level access to all VMs through VSCs. Please correct me if I am wrong"
Here's Brandon's response: "Each VM has a separate instance of VMBus. VMBus is a bus only in the sense that multiple VSCs inside a VM share the same instance of VMBus. This means that a local, kernel mode compromise of a VM will not reveal any data from other VMs. That said, a vulnerability in VMBus and VSPs in the root partition could critically affect VM isolation if the vulnerability resulted in arbitrary code execution there. For this reason we treat all data coming from guest VSCs to the root VSPs over VMBus as untrusted data when validating the Hyper-V root components."
