Researchers from CrowdStrike recently revealed a security flaw in a popular virtualization software. The vulnerability was dubbed VENOM, short for Virtualized Environment Neglected Operations Manipulation, and assigned the distinction CVE-2015-3456.

Vulnerability and Impact

VENOM is a vulnerability called a guest escape bug. It may allow attackers to work around their status as a virtual machine (VM) guest and infiltrate the data network, potentially granting them code execution access to the host. The flaw is situated in the virtual floppy drive code (FDC) and cannot be exploited remotely. An attacker needs local access in order to get into the hypervisor.

Xen, KVM, VirtualBox and the native QEMU client are vulnerable. VMWare, Microsoft Hyper-V, Linode and Amazon AWS instances are not affected. But even if you don’t use a virtual floppy, you might still be vulnerable. The vulnerability may have been added by default or because — in the case of Xen and QEMU — an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

Should the cybercriminal gain access to the host system, it could lead to lateral attacks against the hosting environment, endangering other VMs. The attacker could then gain entry to the local network of the host and its adjacent networks. As a result, the cybercriminal could have access to sensitive user and customer data stored in the affected VMs.

Cybercriminals must meet certain requirements in order to obtain private information. To start, the attackers need to have root-level privileges — making them so-called “super users” — on the guest machine. This is probably not a real issue because an attacker could rent a VM from a cloud computing service and exploit the hypervisor from there. Further exploitation depends on the protective measures put in place by the cloud provider.

For code execution, the attacker needs knowledge of the memory layout of the QEMU process. Using address space layout randomization (ASLR) might make it more difficult, but not impossible, for an attacker to achieve this.

While the vulnerability was only discovered somewhat recently, vendors have sprung into action to prevent further damage. Most have already released a patch. And although a proof of concept exploit exists, currently no practical widespread use has been seen.

Why Should I Care About VENOM?

The VENOM flaw itself may be small, but it has the potential to do major damage. If you run your services on a VM with a provider that runs a vulnerable product, then someone who breaks into a VM belonging to another customer of your provider could access all of your data.

Imagine your provider does not use isolation. One of its other customers runs a badly configured personal website on a VM. You run your hosted invoicing and customer relations application on another VM. If the vulnerable website of the other customer gets attacked, and the attacker is able to get super user rights on that VM, then the cybercriminal could use the VENOM vulnerability to gain access to your machine. Consequently, the attacker could have access to all the customer data stored in your VM. This could happen regardless of all the security measures that you put in place for protecting your applications, data and machines.

Thus, choose your VM provider wisely. Request that it applies relevant patches as soon as possible and verify that it follows best practices for cloud security.

What Should I Do?

There are a few instances that may require you to take action regarding VENOM. Here are three questions to ask regarding your cybersecurity, as well as a possible course of action you’ll need to follow to protect your organization and its customers.

Do you rent a VM with a cloud provider?

• You should ask your cloud provider if it uses an affected product. If this is the case, ask if the IT team has already patched the product or plans on patching it. If your provider has a plan, it might be worth asking about the timeline. Remember that a patch requires a reboot. This will cause downtime for your VM and the services that you provide, so you’ll need to inform your customers of possible downtime.
• Remediation: There’s not a lot that you can do in this scenario. You have to rely on your provider to act responsibly and apply the patches.

Do you run virtualization software?

• If you run your own virtualization software, then you might be at risk. This vulnerability affects both you and the users for which you provide virtualization solutions. Not applying the necessary patches can put your data and your customers’ data at risk.
• Remediation: Check if your virtualization software is vulnerable. If so, go to your vendor for updates and apply the patches as soon as possible. Once again, applying the patches will necessitate a reboot, which causes downtime for the VMs. Before rebooting, it might be a good idea to verify your disaster recover plan and backup/restore plan. You also have to inform the owners of the VMs that use your software and the customers that rely on the services.

Do you provide the public with virtual private server (VPS) services?

• You could also be at risk if you provide VPS services. The risk associated with VENOM then affects both you and the customers for which you provide virtualization solutions. Not applying the necessary patches makes all data vulnerable to attackers.
• Remediation: If you run one of the vulnerable products, there is no reason to panic. You should check with your vendor for updates and apply the patches immediately. Any reboot will impact the services that your customers rely on. You should streamline the patch and reboot cycles with a clear line of communication toward your customers stating the intended actions and the results.

Again, while the VENOM vulnerability may seem small, its implications are huge. Be sure that you’re doing all you can to protect both your organization’s and your customers’ data from potential loss.