Archives

VMware Security Response Center

For those visiting VMworld, come and meet VMware Trust and Assurance (which includes VMware Security Response Center) in Las Vegas next week or in Barcelona in three weeks from now. Bring your questions and concerns on security issues in our products and services, and how we address these. We would also like to have feedback on the VMware Security Advisories and our patch policies.

How to find us? We are accepting 1:1 meetings at VMworld. If you would like to schedule a meeting please contact your Technical Account Manager with a general idea of what you would like to speak with us about and we will schedule time with you. Alternatively just come and meet us; we are stationed in the Listening Post located in the VM Village. This is the lounge area with seats and games on the top floor.

We share the Listening Post with other teams and they would be delighted with your visit as well! They are Support, Customer advocacy, and the Information Experience, Quality Assurance, and Product Globalization teams of the VMware R&D Central Organization.

The advisory documents a hard to exploit denial of service vulnerability in the implementation of the OSPF protocol in NSX-V Edge. This issue is present due to incorrect handling of link-state advertisements (LSA). NSX-V Edge 6.2.8 and NSX-V Edge 6.3.3 address the issue.

We would like to thank Adi Sosnovich, Orna Grumberg and Gabi Nakibly for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisory and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0014 appeared first on VMware Security & Compliance Blog.

CVE-2017-4921 is an insecure library loading issue that occurs due to the use of ‘LD_LIBRARY_PATH’ variable in an unsafe manner. Successful exploitation of this issue may allow unprivileged host users to load a shared library that may lead to privilege escalation.

CVE-2017-4922 is an information disclosure issue that occurs due to the service startup script using world writable directories as temporary storage for critical information. Successful exploitation of this issue may allow unprivileged host users to access certain critical information when the service gets restarted.

CVE-2017-4923 is also an information disclosure vulnerability. Exploiting this issue may allow an attacker to obtain plaintext credentials when using the vCenter Server Appliance file-based backup feature.

CVE-2015-5191 is a local privilege escalation issue that exists because VMware Tools contains multiple file system races in libDeployPkg.

We would like to thank Thorsten Tüllmann, researcher at Karlsruhe Institute of Technology, Joe Womack of Expedia, Florian Weimer and Kurt Seifried of Red Hat Product Security for reporting these issues to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0013 appeared first on VMware Security & Compliance Blog.

The Black Hat USA 2017 conference includes a talk by Ofri Ziv of Guardicore Labs about using the VIX API to obtain privileged access to a guest operating system with unexpectedly low VIM API permissions. VMSA-2017-0012 contains details of impacted versions and workarounds. The Common Vulnerabilities and Exposures project has assignedCVE-2017-4919 for this issue, with thanks toOfri Ziv and Itamar Tal of Guardicore for discovering and reporting it.

In proof-of-concept code, authors used this permission to enablethe “shared secret” mechanism at the host level. VMware considers use of this permission equivalent to full control (e.g. root) and thususing it in an attack chain does not amount to a privilege escalation.

However, someVMware products(SRM, VUM, and VIN) operate with this permission, and the settingis host-global. When such software enables “shared secret”, they allow a lower privilege user to gain guest access for the window when it is enabled.

The issue reporters argue that a typical datacenter would frequently enable “shared secret”. VMware believes such enablements are uncommon, and collisionsare unlikely and can be mitigated. But as the collision is possible, VMware is treating this as an exploitable issue.

VirtualMachine.Config.AdvancedConfig. This is the “vulnerable” permission. Virtual machine advanced configurations are a lower privilege level than host advanced configurations, and this setting should have been safe to give to lower-privilege users.

VirtualMachine.Interact.GuestControl. This is the “guest control” permission; users with this permission may establish VIX API connections and thus present some form of authentication.

To compute a CVSS v3 score, VMware recommends “Access Vector: Local” to represent the need to be on the management network (equivalent to local access in a non-virtual environment), and “Attack Complexity: High” to represent the difficulty in bypassing the Host.Config.AdvancedConfig permission.

Impact andWorkarounds

Accessing a virtual machine should require two authentications: a VIM API authentication to provide a “route” to a virtual machine, and a VIX API guest authentication to access the virtual machine itself. The security issue here bypasses only the second authentication; the first authentication remains a requirement.

Before worrying about this security issue, an organization should first confirm that their configuration does assumea separation of privilege, with some users being given rights to configure or access virtual machines but being denied rights to configure hosts, and vice versa. Such least-privilege configurations are a best-practice recommendation, but manydeployments have so few vSphere users that all users operate with full permissions - at which point there is no escalation from a low-privilege user to a high-privilege user.

The escalation of privilege here requires both an ESXi host version capable of reading “shared secret” information, and a VMware Guest Tools version willing to accept “shared secret” authentication. All current versions of VMware ESXi are impacted by this issue.VMware Guest Tools prior toversion 10.1.0(released October 2016) are impacted by this issue, as beginning with Tools 10.1.0 we have disabled the “shared secret” authentication mechanism.

VMware has two recommended workarounds. Either is sufficient.

Upgrade VMware Guest Tools to at least version 10.1.0, in combination with running ESXiat least version 6.0. Without an in-guest endpoint willing to accept “shared secret” authentication, there is no privilege escalation.

However, some older products are incompatible with newer VMware Guest Tools (see “known issues” in the 10.1.0 release notes). Those products are incompatible precisely because they depend on “shared secret” authentication.

VMware Guest Tools version 9.10 and later have an in-guest configuration option to disable this functionality, which is enabled by default. Version 10.1.0 changes the default to disabled. See KB 2151027for further details.

Remove theVirtualMachine.Interact.GuestControl permission from vSphere users, applicable to allvSphere versions. This permissionenables VIX API access, which is necessary to present any credential at all via the VIX API (whether “shared secret”, username/password, or SAML token).

Most vSphere customers do not use the VIX API (and those that do, are probably aware of it). Any existing users of the VIX API should prioritize moving to the replacement Guest Operations VIM API discussed below.

VMware believes the above workaroundsare sufficient for most customers.In particular, either a Tools upgrade or removing GuestControl are straightforward to apply inmost scenarios.Regarding ESXi releases:

ESXi5.5 will retain “shared secret” behavior as a “mis-feature”; the only workaround is to disable the VIX API entirely via the GuestControl permission. This is ultimately a recognition that in vSphere 5.5, guest authentication was designedas a mechanism to run guest operations as a particular user and not as a security barrier. As described below, adequate securitymechanisms to provide a barrier are not available architecturally until vSphere 6.0.

Any future major release of ESXi will have “shared secret” authenticationremoved entirely, due to VIX API end-of-life as describedbelow.

VIX API: a slow path to deprecation

The VIX API is an old VMware API written in C, primarily intended for automation use cases. Originally created for Workstation 6 (released 2008), VIX version 1.6.2 (released 2010) added vSphere support.

That heritage embedded some toxic assumptions. The automation use case around 2008 envisioned deployingVMs under API control, and “obviously” the user invoking automation would have full control of those VMs to run processing tasks - so the VIX API offered full guest control without authentication.

Around 2010, VMware recognized that holistically, the VIX API bypassed too many important checks offered by the VIM API and needed to be removed. However, as some bloggers had noticed, the VIX API was unique in being the only mechanism to run a command in guest, which turns out to be a very powerful tool for automating virtualized software. Thus, we added Guest Operations support in the VIM API, a project that started vSphere5.0 and culminated with vSphere6.0’s support for SAML tokens to share pre-authenticated access (allowing a guest to opt-in and mapVIM users to guest users as a bridge betweentwo security domains). Simultaneously, we moved the guest-unauthenticated access to be off by default and enabled only via higher-privilege “shared secret” settings, to prevent new usages of this functionality.

Deprecation of the VIX API was announced in 2011 with VIX version 1.11, indicating “VIX will be unsupported in the second major release after vSphere 5”.Nominally those next two releases were ESXi 5.5 and 6.0, with VIX scheduled for removal in ESXi6.5. That didn’t happen.

Now for the bad news. As anyone familiar with IT or software engineering knows, anytime a feature is deprecated, somebody will build a new product depending on it before the deprecation window expires. We initially tried disabling VIX’s unauthenticated guest access entirely… and regressed many VMware products, so needed another release. SRM ported to the Guest Operations API in the 6.5 release. VUM dropped the only feature which used VIX (appliance upgrade). vRealize Infrastructure Navigator chose to end-of-life, with the replacement being the Service Discovery Management Pack.As most of those were completed late in the release, we were uncomfortable removing VIX (or even VIX’s “shared secret”) inthe 6.5 release, so delayed removal to the first major release after 6.5.

Astute observers will notice the dilemma here. On one hand, bypassing guest authenticationis increasingly an untenable security posture. On the other hand, removing this functionality will break mission-critical functionality like SRM (for disaster recovery). And there are no good answers.

Conclusions

Deprecating and removing concerning code is always a tradeoff between the risk of unknown security bugs, and unknown functional regression - a hard tradeoff to make for enterprise products where functional regressions can bring an entire business down. The removal of the entire VIX API will occur promptly as planned; thanks to this security research,the securitycosts of any further delay are more obvious.

VDP contains a deserialization issue (CVE-2017-4914). Exploitation of this issue may allow a remote attacker to execute commands on the appliance. VMware would like to thank Tim Roberts, Arthur Chilipweli, and Kelly Correll from NTT Security for reporting this issue to us.

VDP locally stores vCenter Server credentials using reversible encryption (CVE-2017-4917). This issue may allow plaintext credentials to be obtained. VMware would like to thank Marc Ströbel aka phroxvs from HvS-Consulting for reporting this issue to VMware.

Issue (a) is a heap-based buffer overflow vulnerability (CVE-2017-4907) which affects VMware Unified Access Gateway and Horizon View. This issue may be exploited remotely to execute code on the security gateway. VMware Unified Access Gateway 2.9 is not affected. This issue has been addressed in VMware Unified Access Gateway 2.8.1, Horizon View 7.1.0 and 6.2.4.

Issues (b), (c) and (d) are heap-based buffer-overflow, out-of-bounds read/write and integer-overflow vulnerabilities (CVE-2017-4908, CVE-2017-4909, CVE-2017-4910, CVE-2017-4911, CVE-2017-4912, CVE-2017-4913) in JPEG2000 and TrueType Font (TTF) parsers in the TPView.dll. These issues exist due the use of vulnerable Cortado ThinPrint component and impact VMware Horizon View Client for Windows and Workstation. Exploitation is possible only if virtual printing has been enabled. This feature is not enabled by default on Workstation but it is enabled by default on Horizon View. These issues have been addressed in VMware Workstation 12.5.3, Horizon View Client for Windows 7.1.0 and 6.2.4.

We would like to thank Claudio Moletta (redr2e), and Ke Liu of Tencent&#rsquo;s Xuanwu Lab, Gogil and Giwan Go of STEALIEN working with ZDI for reporting these issues to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

Customers should review the security advisories and direct any questions to VMware Support.

The post New VMware Security Advisory VMSA-2017-0008 appeared first on VMware Security & Compliance Blog.

On Tuesday, 4th of April 2017 a remote code-execution issue in the BlazeDS library (CVE-2017-5641) was disclosed in a US-CERT security advisory. We have reviewed the issue and determined that VMware vCenter Server 6.5 and 6.0 are affected due to the use of BlazeDS to process AMF3 messages. VMware vCenter Server 5.5 is not affected.

We have released the following new security advisory which documents the fixes for VMware vCenter Server 6.5 and 6.0 along with the workarounds:

Successful exploitation of this issue may allow an attacker to execute arbitrary code when deserializing an untrusted Java object. We have also investigated this issue against the other VMware products. VMware products which are not listed in the security advisory are not affected.

We would like to thank Markus Wulftange of Code White GmbH for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

The post New VMware Security Advisory VMSA-2017-0007 appeared first on VMware Security & Compliance Blog.

On Tuesday, 4th of April 2017 a remote code-execution issue in the BlazeDS library (CVE-2017-5641) was disclosed in a US-CERT security advisory. We have reviewed the issue and determined that VMware vCenter Server 6.5 and 6.0 are affected due to the use of BlazeDS to process AMF3 messages. VMware vCenter Server 5.5 is not affected.

We have released the following new security advisory which documents the fixes for VMware vCenter Server 6.5 and 6.0 along with the workarounds:

Successful exploitation of this issue may allow an attacker to execute arbitrary code when deserializing an untrusted Java object. We have also investigated this issue against the other VMware products. VMware products which are not listed in the security advisory are not affected.

We would like to thank Markus Wulftange of Code White GmbH for reporting this issue to us.

Please sign up to the Security-Announce mailing list to receive new and updated VMware Security Advisories.

The post New VMware Security Advisory VMSA-2017-0007 appeared first on VMware Security & Compliance Blog.