The more elderly amongst us might remember a family of portable, magnetic disk based storage media, with typical capacities ranging from 320 KB to 1.44 MB, called Floppy Disc. These were introduced in the early 1970s then faced their decline in the late 1990s, with today’s generation of Digital Natives most probably not having seen this type of media in the wild.
Have you ever thought it possible in 2015, that your virtual machines, your VM environment, your network and thus potentially your complete IT infrastructure might be threatened by a vulnerable floppy disk controller? Or even worse: by a virtualized floppy disk controller? No? Or that the VM you are running at your trusted provider of virtualization solutions might have been in danger of being attacked by an admin of a VM running on the same infrastructure for the last 11 years?
But this is exactly what has been uncovered this week with the publication of a vulnerability called Venom, CVE-2015-3456 (with Venom being actually an acronym for “Virtualized Environment Neglected Operations Manipulation”). The vulnerability has been identified, diligently documented, and explained by Jason Geffner of CrowdStrike.
Affected virtualization platforms include Xen, VirtualBox and QEMU, but it is the original open source QEMU virtual floppy disc controller code, that has been re-used in several virtualization environments, which has been identified as the alleged origin of the vulnerability.
As a floppy disk driver still is typically included in a VM configuration by default and the issue is within the hypervisor code, almost any installation of the identified platforms is expected to be affected, no matter which underlying hosting operating system has been chosen. Although no exploits have been yet documented prior to the publication, this should be expected to change soon.
The immediately required steps are obvious:
- If you are hosting a virtualization platform for yourselves or your organization, make sure that you’re running a version that is not affected or otherwise apply the most recent patches. A patch for your host OS and virtualizing platform should be already available. And do it now.
- In case you are running one or more virtual machines at providers using one of the affected platforms, make sure that appropriate measures have been taken for mitigating this vulnerability. And do it now!
More importantly this vulnerability again puts a spotlight on the reuse of open source software within other products, especially commercial products or those used widely in commercial environments. Very much like the heart bleed bug or shellshock this vulnerability once more proves that relying on the given quality of open source code cannot be considered appropriate. This vulnerability has been out in the wild for more than 11 years now.
Open source software comes with the great opportunity of allowing code inspection and verification. But just because code is open does not mean that code is secure unless somebody actually takes a look (or more).
Improving application and code security has to be on the agenda right now. This is true for both commercial and open source software. Appropriate code analysis tools and services for achieving this are available. Intelligent mechanisms for static and dynamic code vulnerability analyses have to be integrated effectively within any relevant software development cycles. This is not a trending topic, but it should be. The responsibility for achieving this is surely a commercial topic, but it is also a political topic and a topic that has to be discussed in the various OSS communities. Venom might not be as disruptive as heart bleed, but the next heart bleed is out there and we should try to get at least some of them fixed before they are exploited.
And while we’re at it, why not change the default for including floppy disks in new VMs from “yes” to “no”, just for a start…