Crowdstrike disclosed a serious VM Escape vulnerability – codename VENOM, CVE-2015-3456 which has been around here since 2004. This one is especially serious because it is affecting the VMs in their default configuration and could be also affecting thousands of the VMs in cloud.
This vulnerability may allow an attacker to escape from the confines of an affected virtual machine (VM) guest and potentially obtain code-execution access to the host. Absent mitigation, this VM escape could open access to the host system and all other VMs running on that host, potentially giving adversaries significant elevated access to the host’s local network and adjacent systems.
Unlucky ones are those who are running Xen, KVM, or the native QEMU client and those are advised to check with their vendors for the latest scurity patches.
It is most probably also affecting cloud providers and services which are running on the affected hypervisors like Amazon, SoftLayer, Rackspace… therefore you should also verify with them if you are safe.
Luckily you should be on the safe side if you or your provider is running on top of VMware, Microsoft Hyper-V, Bochs hypervisors as those are not affected.
VENOM is using bug in virtual floppy drive code from where it is possible to gain control of a hypervisor itself and the others VMs too. Also if you have your virtual floppy drive disabled, due to a non-related bug in Xen and QEMU, vulnerable code is still active.
UPDATE: Cloud providers statements
We are aware of the QEMU security issue assigned CVE-2015-3456, also known as “VENOM,” which impacts various virtualized platforms. There is no risk to AWS customer data or instances.
Server Types that ARE Impacted
* FirstGen Cloud Servers running Windows
* NextGen Cloud Servers built from a PVHVM image
Server Types that are NOT Impacted
* FirstGen Cloud Servers running Linux
* NextGen Cloud Servers built from a PV image
We patched the portion of our infrastructure that supports the Cloud Virtual Machine (VM). For the patch to be effective in resolving the vulnerability, the customer VM must be power cycled, either by the customer or by Rackspace. Our preference is that customers do this themselves, and we strongly recommend that customers take this action as quickly as possible…
SoftLayer engineers, in concert with our technology partners, completed a deep analysis of the vulnerability and determined that SoftLayer virtual servers are not affected by this issue.
Latest posts by Dusan Tekeljak (see all)
- VM Latency Sensitivity set to High still fails with no (proper) warning - June 27, 2024
- ESXi 6.7 U1 fixes: APD and VMCP is not triggered even when no paths can service I/Os - November 30, 2018
- Update manager error: hosts could not enter maintenance mode - November 19, 2018
