VMware is aware of suggestions that the recent defacement of the OpenSSL Foundation website (http://www.openssl.org/news/secadv_hack.txt) may be as a result of a hypervisor compromise.
The VMware Security Response Center has actively investigated this incident with both the OpenSSL Foundation and their Hosting Provider in order to understand whether VMware products are implicated and whether VMware needs to take any action to ensure customer safety.
We have no reason to believe that the OpenSSL website defacement is a result of a security vulnerability in any VMware products and that the defacement is a result of an operational security error.
VMware recommends the use of vCloud Director in deployment scenarios that require secure Internet facing access to Virtual Center and ESXi. In the event that Virtual Center is directly Internet facing VMware recommends customers remain current with patches and updates and that they follow the best practices in the vSphere Security Hardening guides https://www.vmware.com/support/support-resources/hardening-guides.html.
Updated: January 3, 2014
OpenSSL updated their advisory at http://www.openssl.org/news/secadv_hack.txt to confirm that their understanding of the cause of this incident is the same as VMware’s. The VMware Security Response Center would like to thank their colleagues in the OpenSSL Security Team for their timely collaboration in understanding this incident further.
Today, Nov. 4, 2012, our security team became aware of the public posting of VMware ESX source code dating back to 2004. This source code is related to the source code posted publicly on April 23, 2012. (For reference: April 24, 2012 and May 3, 2012). It is possible that more related files will be posted in the future. We take customer security seriously and have engaged our VMware Security Response Center to thoroughly investigate.
Ensuring customer security is our top priority. As a matter of best practices with respect to security, VMware strongly encourages all customers to apply the latest product updates and security patches made available for their specific environment. We also recommend customers review our security hardening guides. By applying the combination of the most current product updates and the relevant security patches, we believe our customer environments will be best protected.
As is our practice, VMware will continue to assess any further security risks, and will provide recommendations and updates here as appropriate.
Note: We encourage customers to view the May 3, 2012 security patch information as a resource: http://kb.vmware.com/kb/2019941 and http://www.vmware.com/security/advisories/VMSA-2012-0009.html
On April 23, 2012, our security team became aware of the public posting of a single file from the VMware ESX source code dating back to 2004, and the possibility that more files may be posted in the near future. Ensuring customer security is our top priority. As a matter of best practices with respect to security, VMware strongly encourages all customers to apply the latest product updates and security patches made available for their specific environment. As part of its regular program of providing patches for security and other issues, VMware has accelerated the delivery of a set of software patches for specific product releases that may be exposed to increased risk. We encourage all customers to view the following links to determine if appropriate patches are available for products in their environment: http://kb.vmware.com/kb/2019941 and http://www.vmware.com/security/advisories/VMSA-2012-0009.html.
By applying the combination of the most current product updates and the relevant security patches, we believe our customer environments will be best protected. As is our practice, VMware will continue to assess any further security risks, and will continue to provide updates and patches as appropriate.
As always, we welcome any security-related concerns to be shared with VMware via the following channels:
2012 セキュリティアップデート: VMware のセキュリティブログに関する声明書（訳文）
Frequenty Asked Questions:
1. Are these software patches related to source code associated with the April 23rd incident?
VMware has consistently provided software updates and patches to help customers maintain the most reliable and secure environment. In light of the current circumstances, we have accelerated our most recent security patches and applied them to all affected currently supported products.
2. Is my environment at risk if I do not apply these latest patches?
VMware provides security updates and patches from time to time to mitigate known security issues that may put customer environments at risk. As a matter of best practice, we encourage customers to always apply the latest software updates and patches relevant to their environment. We encourage all customers to view the following link to determine if appropriate patches are available for products in their environment: http://kb.vmware.com/kb/2019941 and http://www.vmware.com/security/advisories/VMSA-2012-0009.html.
3. What does VMware do on a regular basis to secure its information?
VMware has a comprehensive Information Security Program in place. The Information Security Team is focused on effectively safeguarding VMware’s information, intellectual property, infrastructure, and users. The VMware Information Security Team effectively assesses and manages security risks across the enterprise based on the evolving landscape of threats, laws, regulations, and industry practices.
4.What does VMware do to ensure a secure customer virtual environment?
VMware uses a number of techniques during its software development cycle to improve upon the security of its products. These standard techniques include Threat Modeling, Static Code Analysis, Incident Response Planning, and Penetration Testing using both internal and external security expertise. VMware has an established security engineering group that integrates these techniques into the software development cycle, provides security expertise, guidance on the latest security threats and defensive techniques, and training within the development organization. This group is also responsible for driving VMware products through external security accreditations and certifications.
5. How are you keeping customers informed?
VMware will continue to update our public security blog with up-to-date communications and instructions, as well as inform customers through the VMware Product Support Center.
Yesterday, April 23, 2012, our security team became aware of the public posting of a single file from the VMware ESX source code and the possibility that more files may be posted in the future. The posted code and associated commentary dates to the 2003 to 2004 timeframe.
The fact that the source code may have been publicly shared does not necessarily mean that there is any increased risk to VMware customers. VMware proactively shares its source code and interfaces with other industry participants to enable the broad virtualization ecosystem today. We take customer security seriously and have engaged internal and external resources, including our VMware Security Response Center, to thoroughly investigate. We will continue to provide updates to the VMware community if and when additional information is available.
Director, VMware Security Response Center
If you are at VMworld next week and you are interested what we are doing to make our products more secure, come to our talk on VMware’s Secure Software Development Life Cycle (follow link, click "Content Catalog" and search on "secure"). The first part of the talk will spell out our security training, architectural reviews, security testing, code analysis, and the Product Security Policy. The second part of the talk will feature the security response activities and take you through a real-world disclosure scenario.
We hope to see you in room 301 at 2.30 pm on Tuesday September 1!
Are you interested in security and virtualization? We made a summary table listing the VMworld sessions on product security, compliance, hardening, secure architecture, VMsafe, and securing the Cloud.
Today, VMware released a new version of VirtualCenter, VC2.5 Update 3, a new version of Virtual Consolidated Backup, VCB 1.1 Update 1, and patches for ESXi and ESX 3.5. These and the recently released versions of VMware’s hosted products and patches for ESX 3.0.1, 3.0.2 and 3.0.3 address several security issues. The issues are described in a new and an updated security advisory published today.
One of the fixed security issues is a privilege escalation on certain 64-bit guest operating systems, CVE-2008-4279. It allows an attacker with a login account on a guest operating system to elevate their privileges on that system. The flaw doesn’t allow for compromising the host system. The other security issues involve password disclosure and an update to JRE.
On a side note, we like to thank everyone that completed our questionnaire on security advisories during the VMworld 2008 Security Lab. Expect a blog post on the results soon.
Today, VMware released a patch for a critical openwsman security issue, CVE-2008-2234. Affected are ESX 3.5 and ESXi 3.5 that have openwsman 2.0.0 installed. VMware Security Advisory VMSA-2008-0015 provides details on the openwsman versioning, on the patches and on the possible workaround. The openwsman service is running by default. This vulnerability can be exploited remotely however best practices provided by VMware recommend that the service console be isolated from the VM network.
The other patches for ESX(i) 3.5 released today update libpng, bind, net-snmp, and Perl. These patches and the patches released last month for ESX 3.0.1, 3.0.2, and 3.0.3 are listed in updated advisories VMSA-2008-0010, VMSA-2008-0011, VMSA-2008-0013, and VMSA-2008-0014. Advisory VMSA-2008-0014 also lists the security issues that are fixed in the new versions of VMware Workstation, Player, ACE, and Server released last month.
The ESX(i) 3.5 Update 2 Virtual Machine power on problem that surfaced today is not related to exploitation of a security issue on ESX. Several customers have been worried that their ESX systems had been compromised by an attack and that this was the cause for not booting of their ESX update 2 Virtual Machines today.
We know that the boot problem is due to an expired license. License expiration was set at August 12 and was not removed prior to releasing ESX(i) Update 2. VMotion is affected by the license expiration as well.
VMware is working very hard to get a patch out of the door. Please see here for a workaround and the latest developments.
Express patches have become available. Visit this VMware Web site for details.
On June 3 and May 29, VMware released patches for security issues in VMware ESX(i) and VMware Workstation, Player, ACE, Server, Fusion, and Server. The issues range from denial of service to code execution on the host system from the guest system. You are advised to review the new security advisories, VMSA-2008-0008 and VMSA-2008-0009, and the updated advisory VMSA-2008-0007 and deploy the patches and new binaries per your security policy.
We like to draw your attention to a special situation with one of the patches listed in VMSA-2008-0009. Installing the new hosted release or the ESX patches alone will not remediate the VMware Tool Privilege Escalation issue. To fix this issue, the VMware Tools packages will need to be updated on each guest operating system followed by a reboot. This issue affects Windows-based guest operating systems only.
As always, we welcome your comments and questions at email@example.com (PGP key).
Recently ESX and VirtualCenter (VC) patches were released which – among others – fix several security issues. These issues are detailed in a new advisory, VMSA-2008-0007, and in the updated advisories VMSA-2008-0002.1, 0003.1, 0004.1, 0006.1. Please take some time out of your busy schedule to review your deployments and update where appropriate.
In an effort to improve our advisories, we have added a change log which should help identifying what has changed. Your feedback on this and on other possible additions to our advisories is highly appreciated. You can reach us by e-mailing firstname.lastname@example.org; our PGP key can be found here.