Security Ripcord

Gherard,

Your comment here shows that you are quite unfamiliar with our work. I don’t blame you… you weren’t at the talk and are relying on various blogs to understand what we presented. However, you have missed several salient points, and your comments, I think, are easily misconstrued. Again, it’s not your fault. Please let me clarify:

You wrote:
> If all they found are vulnerabilities in the host-guest communication channel (which Monty’s blog seems to imply), then we are far from VMowned or GAME OVER.

We never called our tools “VMowned” or GAME OVER. Those are the comments of others (very kind comments, for which we are grateful… still they weren’t our words). The tools we presented have names based on their functionality: VMchat, VMcat, VM Drag-N-Hack (which undermines drag-and-drop, altering a file going from guest to host), VM Drag-N-Sploit (which alters a dragged file into something that shovels a shell into the guest), and, finally VMftp. That last one (VMftp) exploited the directory traversal flaw to provide FTP-style file access to the host from the guest, representing a true escape. I do not think that VMftp is an overhyped name.

So, our tools and their names were not overhyped, in my opinion. Also, beyond those tools and demos, our talk addressed several other virtual machine crash conditions in a variety of products. Some of these crash conditions are patched; others are not.

Also, we said at least three times during the talk that we were big fans of virtualization, and really like VMware’s products. We use them a lot, and work with our clients to apply them in their environments. We are not trying to stop virtualization — the economics and functionality of it are incredibly compelling. It’s great stuff.

But, that brings us to the whole point of our talk: to illustrate the importance of applying solid security principles to VM architecture and deployments. We strongly urged patching guests, hosts, and the virtual machine environment itself. We see a lot of folks who haven’t applied some really important patches from VMware, and we wanted to urge them to do so. We talked about avoiding mixing different levels of security on the same underlying virtual platform.

We are also participating heavily in a project with the Center for Internet Security to devise hardening guides for ESX. I’m happy with the progress of that project and think it will be very helpful in improving the security of ESX deployments. The results should be available in a few months.

> As explained in the blog itself, the channel can be fully disabled, and in fact it is recommended to do so if you run VMware ESX (why would you need the VMware Tools anyway?).

We addressed this in our talk as well, discussing that VMtools is really not needed inside most enterprise guest servers, and should be left out. If there is no functional need to increase a software product’s attack surface, then the extra software should not be installed. Please note, though, that the comm channel itself is present whether the VMtools package is installed in a guest or not. Of course, if VMtools functionality is a business requirement, we have provided some additional information to the discussion about balancing risks with functional business needs. We also discussed approaches to disabling the comm channel.

> Also what Monty and friends have discovered is not a fundamental flaw of virtual machines. It is just a bug, that can (and will) be trivially patched by the vendor.

While I agree with the items you’ve said so far, I worry that your line above may be misconstrued by some. By saying that bugs will be trivially fixed by vendors, you are implying that we don’t need to architect our enterprises around their potential exploit. I mean, browser flaws can (and will) be trivially patched by the vendor. Yeah… great. Does that mean that you shouldn’t work hard to secure your browser, the underlying OS, and the network on which it resides? Of course not. Bugs happen… anticipate that. Then, secure your systems to minimize the chance of exploitation. Also, design your networks and systems so that successful exploitation is contained and damage is minimized.

Guest machines are software using more software to share the same hardware. Software has bugs. We showed that those bugs could be exploited to escape a virtual machine. Then, we recommended patching, hardening, and other security practices.

Yes, there are patches available for the bugs we used to escape. We urged installing them. There will be other bugs, to be sure. No software is perfect.

> In other words, I’m not impressed. Just like the whole BluePill story, it looks like this story is overhyped, it is just trying to surf the virtualization wave.

I have been discussing virtualization security issues publicly for over three years, and working on them in a major project with several participants for two years. We have been presenting and publishing our findings over that entire span, and are not riding some wave. We’ve been talking about this stuff for a long while.

Take care–
–Ed Skoudis.