Many of the virtualization security people I have talked to are waiting patiently for the next drop of leaked VMware hypervisor code. But the real question in many a mind is whether or not this changes the the threat landscape and raises the risk unacceptably. So let’s look at the current hypervisor threat landscape within the virtual environment to determine if this is the case, and where such source code will impact. Are there any steps one can take now before the code drop is complete to better secure your environment?First however, we should understand that VMware’s code has been looked at many folks already not just inside VMware but other organizations: specifically those that issue Common Criteria Evaluation Assurance Level (CC EAL) ratings, as well as specific partners so that integration can continue. In addition to this we need to understand the current threats to the environment to determine if there will be increased risk. There are 3 areas of threats to the virtual environment that may or may not touch the hypervisor.
- Management
Management threats are the easiest to exploit and can potentially cause the most damage as they allow the attacker to gain access to the hypervisor management layers as administrative, delegate, or other highly placed users. With this access, bad actors can affect availability, integrity, and confidentiality of virtual machines. These attacks have the potential of giving FULL access to all VMs. There is still one unknown within the management stack of VMware’s hypervisor, and that is the API used within the management constructs that reside within the hypervisor itself.
- Escape the VM
Escape the VM attacks seem like the bane of all virtual environment attacks as there is the potential to jump from virtual machine to virtual machine. In a cloud, this would be disastrous as one tenant could affect the confidentiality and integrity of another tenant’s virtual machines. While the potential for this style of attack exists, there has not been one that jumps between virtual machines. On Type 1 hypervisors, we have been able to potentially see instructions (first attack against Amazon Xen, quickly fixed; confidentiality) from out nearest neighbor and crash virtual machines (usually paravirtualized driver related; availability) but we have not yet been able to jump between virtual machines. Access to code related to the virtual machine manager within the hypervisor could change this threat landscape, but given the amount of eyes looking at this type of attack today, the risk may not increase significantly.
- Driver Attacks
Driver attacks are ones aimed at coming in from below and almost always impact availability as well as integrity of the virtual environment. Even though drivers have been written for VMware hypervisors by all major vendors, we do not know the internal constructs for the each of the class of the devices. Given that the drivers are nearly all Linux-like we have been able to surmise those internal constructs in the past.
- Direct Hypervisor Attacks
There are currently no direct hypervisor attacks, all attacks currently go through either management APIs, drivers, or attempt from within the guest operating system to the virtual machine management. The hypervisor interacts with all these constructs to schedule and assign resources as needed. However, badly configured virtual workloads can adversely impact other workloads causing a denial of service which impacts availability. It is after all a shared resource environment. Having hypervisor code, could increase this risk, but we would still need to go through other layers.
- Storage Attacks
There is an increasing number of attacks that attempt to bypass the hypervisor directly and go to the storage layers directly, these attacks are attempting to either adversely affect storage resource allocation by the hypervisor or to steal data that lives on disk. Some attacks use hypervisor management attacks to access storage, but those we file under hypervisor management attacks, instead these groups of attacks only target the storage network and its immediate components. These attacks will affect availability, integrity, and confidentiality. Having code that clearly defines with things are on storage will aid these attacks.
Each of these family of attacks have their own risks and potential for disaster. But let’s look at the existing open source hypervisors, Xen and KVM. These hypervisors have been inspected and their code has been available from day 1, and we still do not have successful Escape the VM, Driver Attacks, or hypervisor specific driver attacks, but we DO have management and non-hypervisor specific storage attacks. With this code leak is there potential for more management attacks, yes. But we do not yet know where the code fits into the scheme of possible attacks.
So how can we pre-plan for the release of this code? By following best-practices. Segregate your management networks, employ proper role based access controls, ensure any third party drivers come from well known sources, set all isolation settings within your virtual machine containers, at-rest disk encryption, properly apply resource limits, and limit para-virtualized driver usage. All of these we have discussed before and are well documented at various locations. Here is a list of articles that may help prepare your environment.
- Centralized RBAC Missing from Virtualization Management Tools
- TakeDownCon Dallas: Virtualization Security is NOT just about the Virtual Host
- Security of Performance and Management tools within the Virtual Environment
Any attacks that will arise from this code leak will show up very shortly after the code is made available, but will it increase your risk past where it is today? No, we already have porous security when it comes to management constructs, do not follow best practices, and do not pay attention to confidentiality and integrity today. If we did, we would have secure multi-tenant environments and not just trusted ones.
The use of best practices for securing virtual environments is on the rise, but we are still a long way from our goal. Just getting proper management network segregation is an uphill battle. If there is currently a real risk to your virtual environment it is the lack of following current best practices, not an impending leak of code.