The code, which dates to 2003 or 2004, was apparently stolen from “a variety of compromised Chinese firms,” according to a Threatpost report. The code was confirmed as genuine by the director of VMware’s Security Response Center in a blog post yesterday. Although only a single file has been released publicly, the hacker claims to have another 300 MB of source code and that the rest will be published May 5.
If the rest of the code is of the same vintage, it may not be much of a threat. In fact, providing a more secure hypervisor was a primary goal of the conversion over the last year from ESX to ESXi, a set of code with a much smaller attack surface. So far, no data has been published which indicates the ESXi hypervisor is involved.
But if the remaining code published May 5 is more current, and contains information that could allow hackers to access hosts from guests, it could potentially pose a security threat to enterprises as well as cloud service providers with infrastructures based on vSphere.
The worst-case scenario is that such a “VM escape” is found, but not published, according to Bob Plankers, virtualization architect with a large Midwestern university.
“There’s a lot of money to be made by hacking enterprises,” he said. “So VMware and their customers would be best served by an attitude akin to a race: who can find all the security holes first?”
The risk is probably not very high right now based on what’s been released, according to security expert Edward Haletky, CEO of The Virtualization Practice LLC. But “believe me, on May 5, I’ll be paying attention to what is released,” he said.
So far, escape-the-VM attacks have proven relatively toothless – none has been able to really do much to cross VM boundaries even when they have penetrated the hypervisor in experimental settings, Haletky said. If areas of the code having to do with the virtual machine manager leak out, it could help such an attack do more damage.
For now, it’s much easier to attack virtual machines through the management layers, and therefore much more common, Haletky said. Enterprises can protect themselves by following security best practices such as separating management networks from storage networks, fault tolerance and vMotion networks; limiting the footprint of VMs; effective network monitoring; and using early warning systems. But it’s something he says most enterprises don’t do.
“I think this may push more people to follow best practices because of the increased awareness,” he said.
IT pros shouldn’t expect this to be an isolated incident, according to Haletky. VMware and its competitors have become high-profile enough that their software is a juicy target for potential attackers.
“Years ago…we said we can’t say there won’t be a major incident involving one of the hypervisor vendors, whether it be VMware, Microsoft or even Citrix or Red Hat, and it’s going to be disastrous,” he said. “Does this raise the risk for VMware? Yes. As a company, absolutely.”]]>
The vSphere 5 edition of VMware’s Security Hardening Guide is still in the works, but one blogger brought up a potential conflict between the API, called VIX, and a recommendation against enabling it in the Hardening Guide issued with vSphere 4.1.
“SRM now requires that the VIX API be enabled on all protected virtual machines that will have their IP changed during recovery,” according to the blog post by Michael Webster, a VMware Certified Design Expert and director of IT Solutions 2000 Ltd., a VMware consultancy based in Auckland, New Zealand.
Previously, users had the option of changing IP addresses without using the API, which is slower but considered more secure. “This has already caused me design problems in a number of customer environments,” Webster wrote.
However, enterprises that don’t require the highest security measures may not run into an issue, experts say.
Shannon Snowden, a consulting partner at New Age Technologies in Louisville, Ky., said he has yet to run across the problem despite having done several large-scale SRM deployments over the past few months.
“If it is of concern, we could most likely use a couple of scripts to enable it temporarily during the actual SRM event then disable it as a post-recovery step,” Snowden said. “Obviously, I would prefer to have the old way as an option along with the new faster way, instead of having to put together and coordinate scripts.”
While most companies probably won’t be impacted, the use of the VIX API to change the IP address of virtual machines (VMs) may be a problem for customers in government, research and finance industries, said Bill Hill, infrastructure IT lead for a Portland, Ore.-based logistics company. He doesn’t anticipate it will be a problem in his shop, but he can see where it might be for some.
“Ultimately, VIX allows for significantly more access to a virtual machine outside of just changing the IP address,” Hill said.
Other operations enabled by VIX include the ability to copy files from hosts to guests and guests to hosts, for example.
As an alternative to the API, IT pros may be able to use Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to VMs according to MAC address, suggested VMware principal architect Duncan Epping in Webster’s blog’s comments.
But the environments that are concerned with VIX API may also disallow DHCP, according to Webster. “I think in a lot of environments block this at the switch and insist on static IP addresses.” he wrote.
Some applications for data conversion, PDF generation, and multi-factor authentication in Hill’s environment require static IP definition and therefore wouldn’t be able to use the DHCP workaround, he said.
One financial shop running SRM, South Africa’s Investec Bank, will avoid the VIX issue because its layer 2 domain is stretched, so IP addresses don’t have to be reassigned at all.
“If we do a test we actually isolate the environment completely and our VMs have the same IPs as they would have in production,” wrote Etienne Neethling, who administers SRM for the bank, in an email. “And if we had a real DR [situation], they would [also] stay the same.”
However, this approach comes with its own set of challenges, especially over distance.]]>
In the post, Wright noted that Hyper-V can make headway in the SMB market, because there are some features on VMware hypervisors that admins at smaller shops won’t or don’t need to consider. Wright goes on to note a Gartner prediction that 85% of companies with fewer than 1,000 employees will be Hyper-V shops.
Chanda Dani, senior product marketing manager at VMware, took issue with that and other claims. Dani said the “85%” prediction is incorrect; that of all Hyper-V installations, 75% will be in SMB with fewer than 1,000 employees. Dani said the “statement has been erroneously interpreted in the blog. The author should back up Gartner’s statements with citations.”
Then, earlier this week, Wright took to the SolarWinds blog again, responding to Dani’s critiques. He took to task the idea that VMware products could cater to the small-to-medium business set when VMware’s Essentials kits might not support the needs of a medium-sized company. Wright said it’s hard to deny the advancements Microsoft has made in the SMB market with Hyper-V.
With 60% of our purchasing intentions survey respondents planning to expand server virtualization, Microsoft has a chance to cut into VMware’s substantial market share. It’s no wonder why it’s a contentious topic.
What do you think about VMware and SolarWinds’ slings? Let us know in the comments.]]>