Have you ever heard of the "Ten Immutable Laws of Security"? It is a list put together by Microsoft in 2000 that...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
outlines 10 basic security truisms that are as crisp and pithy as they are accurate. It's a good list; it's still relevant today, and it's a list any security practitioner should read. In fact, Microsoft updated the list to version 2.0 in 2011 to make sure the laws stayed just as relevant in light of technology changes as they were when they were first written almost two decades ago.
When it comes to virtualization -- particularly in the context of the cloud (specifically infrastructure as a service [IaaS]) -- the laws apply in a few different ways, but law two stands out as particularly relevant. Specifically, "if a bad guy can alter the operating system on your computer, it's not your computer anymore." Meaning, in a situation where a nefarious actor can alter the operating system of a given virtual slice, they can subvert that slice's operation or otherwise make pretty much whatever changes they want. Because a hypervisor generally requires the ability to make changes to the slices running on it, the logical extension is that an IaaS provider is in a very trusted position.
This means that the only thing stopping a running OS image from becoming "not your computer anymore" in an IaaS situation is the degree to which your individual provider is able to prevent bad guys from gaining access to hypervisors they're providing to you and turning them into malicious hypervisors. And, as we all know, not all cloud providers are equally trustworthy -- or equally transparent about what they do from a security operations perspective.
SEV and SEV issues
As a strategy to help prevent this issue, Advanced Micro Devices Inc. (AMD) has developed a feature called Secure Encrypted Virtualization (SEV). SEV enables the transparent encryption of the memory space used for a virtual machine using a key that is outside the direct control of the hypervisor running it; the firmware of the system where the hypervisor resides maintains the key. This enables SEV to perform a few specific operations, like running the guest OS (including activation and deactivation), taking snapshots and migrating the virtual machine from hypervisor to hypervisor, decommissioning the virtual machine, etc.
There are a few potential benefits to this model, but one of the primary benefits is that it seeks to change the trust model between a hypervisor and guest systems. Specifically, an organization might choose to trust a hypervisor to execute a guest image, but might not trust that same hypervisor to make other changes. It's an interesting and potentially valuable concept.
Check out the full "Ten Immutable Laws of Security" version 2.0 from Microsoft
As of December 2016, though, researchers at the Technical University of Berlin noted some issues with an implementation of SEV that serve to undermine some of the protections that it provides. They demonstrated how to "force the guest to perform arbitrary read and write operations on protected memory," "completely disable any SEV memory protection" and "implement a replay attack that uses captured login data."
The researchers were clear to point out that they didn't directly attack the SEV implementation itself, but were focused instead on design issues that they noted from the AMD technical documentation. Nevertheless, these are some very serious considerations.
The upshot of their research, though, is that the issues they highlighted enable a malicious hypervisor to compromise guest OS images running on that hypervisor. In light of that, what do security practitioners need to consider as they evaluate the utility of SEV? How likely is a malicious hypervisor situation to occur?
The first thing that's useful to note is that the term malicious hypervisor (sometimes called hyperjacking) is just another way to describe the situation in which an attacker misuses a hypervisor to target a virtual system running on it -- meaning the attacker subverts that hypervisor to specifically attack an individual guest OS instance.
Over the years, there have been several attacks that could have helped to enable this. Attacks against segmentation between virtual images (e.g., Flip Feng Shui) or specific vulnerabilities that would enable an attacker to break out of a virtual instance (e.g., VENOM) have been discovered, but the use of those conditions as practical attacks are rare. In fact, execution of these attacks at an IaaS provider is generally unheard of (that we know about) outside of proof of concept or test conditions. The more common situation is, instead, a direct attack either against the hypervisor itself or a direct attack against the running virtual image.
That doesn't mean that security practitioners should discount the possibility entirely, however. Just because something isn't common now doesn't mean it won't become so in the future. Likewise, it's not a given that an IaaS provider would even know if an attack like this were to take place -- or that they would alert the public if it did. From a due diligence perspective, accounting for a malicious hypervisor situation should be incorporated into the risk analysis that security practitioners are (hopefully) already doing of their environments, as well as the control selection process they use when cloud-dwelling workloads are fielded.
In terms of the impact of the issues outlined in the SEV research specifically, it's something to weigh, as well. It's, of course, likely that AMD will address the issues pointed out by the researchers. This is particularly true since the research findings do somewhat undercut the value proposition for the SEV technology (i.e., if an attacker can disable it through manipulation of the hypervisor, you can't really trust that the protections will deter a dedicated and skilled adversary).
That said, it's important to realize that the use of SEV can make an already complex and uncommon attack even harder to create from the point of view of an attacker than would otherwise be the case.
So, is there still value in using SEV? There absolutely could be. The amount of value, though, depends on your usage: what you're fielding and what the impact would be should it be compromised.
Think you're an expert of hypervisors? Take this quiz and prove it.
Find out how hypervisor management software handles multiple hypervisors
Learn how to export an Amazon Web Services instance to your hypervisor