Virtualization has revolutionized the data center and is one of the key foundational technologies underlying cloud computing. Many companies are rushing headlong into deploying virtualization solutions both in their private and public clouds, assuming the risks are similar to deploying physical servers.
However, protecting virtual assets can be more difficult than protecting physical servers; ultimately, there is no virtualization technology that can equal the protection of physical separation. Yet the same concepts apply in the virtual world as the physical world: Hardened configurations, patch management, network security and monitoring all have a role. It’s also critically important that anyone managing a virtual environment be aware of the evolving threat landscape targeting virtual infrastructure. This is no different than the familiar risk management processes done to protect operating systems running on physical servers.
Virtualization has become a target for malicious activity for the same reason it is popular with IT technicians -- server consolidation. Attacking a single physical host could possibly give the attacker access to confidential data stored in many different virtual servers. This task becomes even easier for the attacker as servers are migrated from behind a private firewall into cloud-based virtual hosts that are accessible from the Internet.
Let’s take a look at some recent
Virtualization vulnerabilities: VMware
VMware has identified several major vulnerabilities this year that have required patches for its entire virtualization product line. In May, VMware issued a security advisory to inform customers of five related vulnerabilities in its virtualization products. The first two vulnerabilities involved a problem with RPC commands in which a guest could crash the VMX process or execute code on the host. The third vulnerability identified an issue where NFS traffic could potentially overwrite memory, allowing code execution without authentication. The fourth and fifth vulnerabilities listed in this advisory involved out-of-bounds memory writes with virtual floppy drives and virtual SCSI controllers. These issues were all addressed by installing the appropriate security patch for each VMware product. VMware’s advisory included mitigation advice for customers who haven’t yet installed the patch, but it may be a little difficult to implement: “Do not allow untrusted users access to your virtual machines. Root- or administrator-level permissions are not required to exploit this issue.”
The important fact is that this one advisory defines five individual vulnerabilities in virtual infrastructure that wouldn’t exist in a physical infrastructure; the virtual infrastructure adds a new layer of risk.
Soon after VMware’s May security advisory, security researchers from German security consulting firm ERNW GmbH revealed another threat to VMware infrastructure with a presentation about creating a malicious VMDK (VMware virtual disk configuration file) that would allow an attacker to access the file system on the host machine. The researchers demonstrated that by using common fuzzing techniques, they were able to access critical files such as log information and all other information contained in the /etc directory, including the hashed password file on the VMware server. This attack required a VMware deployment allow uploading of the malicious VMDK, which should be limited in private environments but is allowed on some cloud-based virtual private server (VPS) environments. The risk posed by this type of virtualization security threat should prompt administrators to scrutinize server images thoroughly before loading them into their virtual environments.
Another recent development in the VMware threat landscape was the ESX hypervisor source code leak. In April, VMware confirmed source code to its popular ESX hypervisor had been leaked and posted to the infamous pastbin.com site. According to published reports, a hacker using the name “Hardcore Charlie” claimed to have downloaded the VMware code after breaking into military contractor China National Import & Export Corp. VMware said the source code in question was from an older version of ESX from around 2003. There is no way for administrators to judge the level of risk imposed by this source code leak. The only indicator will be if the number of new exploits discovered in the next few months in VMware increases dramatically. The only defense for this unknown virtualization security threat will be increased vigilance in monitoring logs and security advisories. Administrators should be looking for abnormal or increased activity in their environment and restricting access to any higher level security functions.
Virtualization vulnerabilities: UC-CERT warning
VMware is far from alone when it comes to security vulnerabilities in the virtualization space; all virtualization technologies will require patches. Last month, US-CERT issued a warning describing a vulnerability that affected some virtualization software and 64-bit operating systems running on Intel CPU hardware. The vulnerability stems from the creation of the x86 64-bit architecture by AMD and Intel’s Intel development of its own 64-bit architecture that was compatible with the original AMD instruction set. The compatibility is almost 100%, but under very specific circumstances it is possible to execute an instruction that leaves the processor in a state that allows execution of malicious code with maximum privilege. This would allow a guest virtual machine to access resources on the host, much like in the malicious VMDK demonstration described above.
VMware is not susceptible to this vulnerability; AMD processors and Intel’s 32-bit processors are also immune. However, affected virtualization platforms come from other major players, including Citrix, Microsoft, Oracle, Red Hat and SUSE Linux. Patches have been posted for all of these affected systems due to the critical nature of the vulnerability.
There will always be security vulnerabilities in software that need to be addressed. These vulnerabilities could be particularly damaging to a virtual environment because they have the potential to allow unauthorized access to multiple virtual machines. Companies deploying virtual infrastructure need to adopt strong risk management processes that include defense-in-depth strategies. A good source for building a risk management process is available from the PCI Security Standards Council. Last June, the council released guidance to address PCI DSS 2.0 security requirements in virtualized environments, but it is applicable to non-PCI DSS environments as well. In addition, VMware in June released the vSphere 5.0 Hardening Guide, which offers a checklist approach to securing a VMware environment.
About the author:
Joseph Granneman, CISSP, has over 20 years in information technology and security with experience in both healthcare and financial services. He has been involved in the Health Information Security and Privacy Working Group for Illinois, the Certification Commission for Health Information Technology (CCHIT) Security Working Group, and is an active InfraGard member.
This was first published in July 2012