filograph - Fotolia


Addressing the VENOM cloud vulnerability with cloud patch management

The VENOM cloud vulnerability was called the next Heartbleed, but how bad is it? Expert Rob Shapland explains the affect it should have on your enterprise.

The VENOM cloud vulnerability follows the recent trend of giving vulnerabilities catchy names to generate more media attention. But is it another cloud vulnerability that hails the end of the Internet as we know it, or is it an issue that seems serious when released but has limited impact in the real world?

VENOM, which is short for Virtualized Environment Neglected Operations Manipulation, exploits a flaw in the virtual floppy disk driver code in virtual machines to allow an attacker to break out of the guest operating system and interact with the host.

This could potentially have a massive impact, as cloud providers rely on virtualization platforms to provide their cloud computing power, and most enterprises deliver a large proportion of their server estate using virtual machines. The ability to jump out of the guest and onto the host could allow attackers to access other virtual machines, potentially even machines from a number of different organizations in a cloud computing environment. This could lead to the disclosure of highly sensitive information -- depending on what information is being stored in the cloud -- which would have a large impact on organizations' trust in cloud security.

However, as the dust clears from the initial furor surrounding the discovery of the cloud vulnerability, we can better assess its long-term impact.

First, let's look at cloud service providers.

Cloud providers are generally quick to apply patches, and this has proved to be the case with VENOM. It is important for enterprises to assess their specific cloud infrastructure and make sure their providers have installed the relevant patches.

The impact on organizations is relatively small and simply involves patching the internal virtual machine estate and ensuring cloud providers have applied the patches.

VENOM primarily affects Xen, VirtualBox and KVM. Amazon uses a modified version of the Xen hypervisor for AWS and was quick to announce its service was not affected by the vulnerability; Microsoft Azure was also not affected. Other popular cloud providers, such as Rackspace and IBM, patched their systems. Many providers were already patched before the vulnerability details were released; others were patched within a week.

Within corporate networks, the cloud patch management process is not managed by a cloud provider; it is therefore more likely that a hacker will be able to find unpatched systems. Organizations need to ensure virtual machines are controlled by their patching policy and that, if they haven't been already, the patches for the affected services are applied as a matter of urgency. However, the scope of the attack is reduced because potential attackers are limited to those that have access to the internal corporate network.

Another key point to mention that limits the scope of the vulnerability is the requirement for the attacker to be not only logged onto the guest operating system, but also to have root-level access. In a corporate environment, this level of access will only be provided to system administrators, who would most likely have access to the host operating system anyway. In order to exploit VENOM in this scenario, it is likely that kernel-level exploits would need to be run in order to escalate privileges. However, in a cloud environment, the most likely scenario would be for an attacker to sign up to a cloud service and acquire their own Linux machine (which they would have root access to), and use this to launch the attack.

In conclusion, VENOM is an interesting cloud vulnerability that proves the value of responsible disclosure and effective cloud patch management. Informing major vendors before making the discovery public gave them a chance to deliver patches to the cloud before the vulnerability could be exploited.

Fortunately, the impact on organizations is relatively small and simply involves patching the internal virtual machine estate and ensuring cloud providers have applied the patches. The main issue that emerges from the discovery may be that virtual machine hypervisors are not as secure as we'd hoped, and that more research effort needs to be completed to ensure there are no more serious vulnerabilities out there being exploited.

About the author:
Rob Shapland is a penetration tester at First Base Technologies, where he specializes in Web application security. He has used his skills to test the websites of companies that range from large corporations to small businesses using a wide variety of Web technologies. He is a firm believer that all penetration testing should have manual techniques at their core, using automated tools to support these skills. He is also involved in network testing and social engineering.

Next Steps

Learn how to overcome unique cloud-based patch management issues

Dig Deeper on Cloud Patch Management and Cloud Configuration Management