VMWare Escape Publicized at SANSfire 2007
Anyone in the know on VMware security knows that Ed Skoudis, Tom Liston and “crew” from Intelguardians (and some close researchers) have been researching VMware escapes for the last couple years for an US government customer. At SANSfire 2006, they presented some of this research to include how malware might detect the fact it was running under virtualization and hinted that there were possible exploits ( Tonight at SANSfire 2007 some of these were revealed and the world saw the first public display of this capability. The information presented below represents my takeaway from this presentation given tonight (7/27/2007). The presentation is not expected to be made publicly available (other than via paper tomorrow) so hopefully this will be of interest to anyone not in attendance. I am sure this will also hit some of the main-stream press sites in the next day or so. Any errors and misstatements in this are my own.

VMchat – interesting little application that communicates across the ComChannel (what VMware refers to the backdoor) between a client OS and host OS. An application is run on the client OS which allocates a known memory buffer string. A DLL injection attack is performed against VMware on the host OS which gives an application running on the host access to the memory of the client VMware machine. Once this is achieved, the memory buffer is used as a communications channel between the client and host machines as a shared buffer. Each can read and write data from this area. This was used to implement a simple chat program. While not a total VM escape, this clearly shows the potential for abuse of any boundary separation between such hosts. Therefore, VMware is clearly unsuitable for separation of virtual machines with differing levels of data sensitivity. This capability exists regardless of if VMware tools is actually installed.

VMcat – essentially extended the above idea to provide a netcat equivalent across client and host OSes. The implication is of course any arbitrary file can be moved or a shell can be shoveled just like with netcat. This a larger more real world abuse of the above exploit.

VMdrag-n-hack – one of the capabilities of VMware allows file and other communications between host and client OSes. The method by which this communication occurs is across the communications channel previously indicated. Using memory debuggers they were able to determine where data was read and written in these transfers. This allowed running code in the client OS that would allow a file being drag-n-dropped to be replaced with another arbitrary file. This of course relies on the user to do a drag-n-drop between the client and host OS.

VMdrag-n-sploit – Extends the concept of VMdrag-n-hack. If the user then executed this file on the host OS, it essentially would provide the two execution points used to exploit VMchat or VMcat and open a channel between the client and host OSes. While not a total VM escape, this is a serious thread to anyone using drag-n-drop.

VMftp – This is the first publicly acknowledged escape of VMware and seriously calls into question the use of virtualization for many tasks in my opinion. The application exploits a VMware directory traversal flaw when a shared folder exists as identified in CVE-2007-1744 which was reported and patched in April 2007. This flaw can be exploited within the client OS (with no privilege) and allows an arbitrary command to be executed on the host OS with the same privilege as the VMware application. This is somewhat mitigated by the requirement for a pre-existing share, but this shows the implications that should a flaw exist it could be exploited.

At this point, there was significant discussion of issues which have been found in other virtualization products. This included flaws in QEMU, BOCHS, Parallels, XEN, and Microsoft PC. QEMU and BOCHS both have publicly disclosed flaws and attacks against most of the virtualization support infrastructure used to provide virtual hardware such as the video, network, modem, and other virtual hardware pieces. Fuzzing and testing of other systems revealed ability to crash the VMs in many cases although specific exploits were not publicly identified. It was explicitly pointed out they were not commenting on any testing of this against ESX. If you read between the lines, either they are very close or have completed such exploits against VMware and are not talking about it. I would personally question the ESX thing, but that is just one man’s opinion.

Additionally, another “un-named” application was run on the client OS. This ran for quite a while and eventually produced a crash of the client OS. While not immediately visible this had the effect of killing the client OS, but in doing so they were able to execute arbitrary code on the host OS thus providing a full escape of the virtualization that did not rely on the path traversal flaw above. The details of how this worked was not disclosed and I would not speculate as to how it was done, but I would call this VMowned and say it is GAME OVER.

All of the above exploits and flaws were achieved against versions 4/5 of VMware workstation code bases. This is shared with VMplayer in many cases. Exploits against ESX were not discussed. As to if such exist, it would be total speculation, but my “bat sense” says be very wary. The current VMware workstation version 6 has also added some more sophisticated communication channels for cross machine communication under their VX API. While stated, and I do believe this has not been a looked at, it would be a highly suspect way of doing this or worse in version 6.

Following the exploits, there were a number of specific recommendations of how the security of these VM deployments could be improved. Patching and hardening the guest and host OSes is key to having any security. There are also some very specific settings which can be made in VMware to kill and or limit the back communications channels. These were published in their 2006 presentation and hold true today. These stop most of these attacks but have the effect of breaking all such communications and VMware tools (not that these should ever be run as they have even more security risks). There are also quality VMware hardening guides expects out of the Center for Internet Security by the end of September 2007 which “should” also server to better protect any existing VMware installs. A strong recommendation was made to never use VMs to separate virtual systems of differing sensitivity. If you need strong protections these should never be implemented on the same host OS. Finally, they suggested they had written a tool named VMXh which would allow the fixed password used to protect the back ComChannel to be changed. While not a silver bullet it would make it harder for malware to exploit this channel. But this limits ability to move virtual machines across VMware instances since all VMware installs currently have the same fixed 32-bit password string. This of course was also identified in 2006. Anyone care to guess when some of the other flaws may have been identified? -- Monty McDougal
Category: Security News Posted: 28 July, 2007, 00:27 am Link: Permalink