When you store your data in the cloud, the reality is that it usually lives on a server within a massive data center made up of many servers. Each server generally hosts multiple virtual machines that act as separate environments for individual accounts, allowing the provider to store your data in a way that keeps it segregated from other people’s data. Until this month, this virtual machine approach has been considered a viable approach to efficiently use server resources while also maintaining data security. However, a new vulnerability has recently been exposed that exposes the falsity of the “isolation myth” associated with running virtual machines. Following the trend of ominous vulnerability names, like Heartbleed and Shellshock, this one is called Venom (for “Virtualized Environment Neglected Operations Manipulation”).
How does Venom work?
The bug, completely undetected from 2004 until earlier this month, affects the hypervisor, which is responsible for coordinating virtual machines running on a particular system. Here’s how it works, according to Crowdstrike (the security firm that discovered Venom): “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.” The vulnerability resides in the virtual floppy disk driver code, showing that even decades-old technologies can affect today’s data security on a huge scale. Put simply, hackers with access to a protected guest environment can use the vulnerability to get control of the entire hosting system and any other virtual environments associated with it.
Specifically, Venom affects the open-source Quick Emulator hypervisor that’s been used for over ten years in many common VM products – most prominently, Oracle VM VirtualBox, the native QEMU client, and Xen hypervisors – as well as in security analysis products that inspect for malware. But even if you aren’t using a cloud storage provider that employs one of these technologies, there’s a good chance that you have an account with an organization somewhere that stores data on a server that does, making this a particularly pernicious vulnerability that could potentially impact thousands of organizations and millions of users. InfoWorld notes that service providers are going to be the most affected by Venom, since customers usually have root access (i.e. administrator-level privileges) that could allow them to move through other VMs running on machines with the vulnerability.
Fortunately, there haven’t yet been any reported instances of the Venom vulnerability being exploited by hackers, and service providers are scrambling to employ fixes to patch it and limit damage now that Venom is widely-known. The negative implications so far have mostly been for the reputation of cloud security, which people are questioning now that there is hard evidence of the interconnectedness and structural weakness of cloud storage environments.
How can I protect myself from Venom?
If you currently store your data on a system that could be exposed via Venom, the service provider should publish information on their website about what they are doing to patch the system; if not, contact them to ensure they’re taking appropriate steps to protect your data. If your system requires a manual reboot or patch, prioritize that immediately. According to Dan Kaminsky of White Ops security firm, you can also request that your cloud provider only share workflow with other people in your domain, so that you’re isolating your server to your organization and avoiding having others on your hardware.
If possible, avoid cloud storage environments entirely and keep your data within your network. If that’s difficult because of the amount of enterprise collaboration happening within and outside of your walls, consider implementing a secure file-sharing tool and limit what’s stored in the cloud.