VMSA-2020-0006 & CVE-2020-3952: What You Need to Know

On April 9, 2020 VMware publishedVMSA-2020-0006, outlining a serious vulnerability in vCenter Server 6.7. This post is intended to help VMware customers and partners understand the issue better by collecting common questions. It is not intended to replace official VMSA communication. All customer environments are different and remediation of critical issues such as this should be an immediate conversation between your organization’s management, information security personnel (CISO, etc.), and IT operations.

Please Read

The following links will help you determine if you are affected by this issue. Please read them before continuing.

• VMware Security Advisory VMSA-2020-0006
• Additional Documentation for VMSA-2020-0006: Determining if a vCenter 6.7 deployment w/embedded or external Platform Services Controller (PSC) is affected by CVE-2020-3952 (78543)

VMSA-2020-0006 (CVE-2020-3952)

What it is: Please read the VMware Security Advisory for the description , and while you’re there sign up for the security advisory mailing list using the form on the right.

What you need to do: Find all instances of vCenter Server 6.7 and Platform Service Controller 6.7 that were upgraded from a previous vSphere version, as described in the VMSA, and update them using the standard patching process. As the vCenter Server Appliance VAMI may offer several patches please ensure you are selecting the latest one. Also ensure that you are updating ALL vCenter Server Appliances as well as ALL Platform Services Controller instances. As always, ensure you have a backup of the affected systems prior to patching.

What effect will it have: Patching will close the vulnerability directly, and you can move on knowing you are secure.

So… should I be worried?

Organizations that don’t have a regular cadence for patching & updates or whose organizational structures make it nearly impossible to make changes in a timely fashion should be very worried. Even rigidly structured frameworks like ITIL support the concept of “emergency changes” and this would certainly qualify.

The best way to handle this issue is to patch it directly using the normal update procedures, such as through the VAMI on the vCenter Server Appliance.

Compensating controls, such as firewall rules on the vCenter Server Appliance, makes an environment more complicated and do not actually fix the underlying problem. Compensating controls and workarounds are like a cast on a broken leg. They don’t heal the wound; they just cover it up to help protect it. Over time the cast becomes a problem of its own. These workarounds make you less flexible, just as a cast does. They slow you down, just as a cast & crutches do. They also complicate operations by having their own rules and requiring their own maintenance. For example, “don’t get your cast wet” means a lot of normal activities are now really, really hard. Your cast will require its own maintenance, too, as it gets smelly and itchy. Same for the workarounds.

You WILL spend much less time and effort overall if you just fix the problem outright by patching. This is borne out in experience and studies of IT over the last 40 years.

While we always recommend running current versions of all infrastructure software, you can patch vCenter Server and the Platform Services Controllers independently of ESXi. A common misconception by non-technical managers, and change management staff unfamiliar with vSphere capabilities, is that workloads are affected by vCenter Server patching. Workloads do not stop running when vCenter Server and the Platform Services Controllers are rebooting. Only VM management operations like console access, power on/power off, resizing, etc. would be affected for the duration of the update process. Direct access to VMs, such as via RDP or through an application’s normal interface, continue unaffected. It is often worth outlining this directly in proposed change documentation.

Frequently Asked Questions

I cannot patch my environment. Is there a workaround for this?

As the VMSA states there are no workarounds. There may be compensating controls, drawing on any defense-in-depth your environment has.

When you say “compensating controls” what do you mean?

As the PCI Security Standards Council defines it , “compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other controls.”

In short, they are other, more roundabout ways of achieving the same security goal without using the specific control that’s listed. In this case, using isolation techniques (network segmentation, firewalling, etc.) might be a compensating control, but that is a discussion between you and your information security staff.

When you say “isolation” what do you mean?

Isolation is where you use technologies like network segmentation, VLANs, firewalls, and such to separate assets based on the function of the asset. For instance, the VMware Validated Design is the documentation for a reference implementation of VMware vSphere and other products like the vRealize Suite, and outline using VLANs to separate hypervisor management traffic from workload traffic. This would be further enforced with firewalls. Implementing controls like this is a discussion between you and your information security staff.

How do I create firewall rules on the vCenter Server Appliance?

Please refer to the documentation, Edit the Firewall Settings of the vCenter Server Appliance , or contact VMware Global Support Services. Please test this in a dedicated test environment, and ensure you create a rule ALLOWING access for yourself prior to creating rules that deny access.

What network port does this affect?

389/tcp.

Does this affect vCenter Server instances with SSH? If I disable SSH will that fix it?

This vulnerability affects the Platform Services Controller functions operating on port 389/tcp. We always recommend disabling SSH because, in most cases, it is not needed for management and configuration and disabling it eases compliance audits and improves security. However, in this case changing the state of SSH will not affect this vulnerability.

What services use the affected network port? What do I need to allow?

This will depend on your environment’s design, what other products are installed, and how everything is configured. As such, this question cannot be answered by VMware. At the very least, vCenter Server and the Platform Services Controllers interact with that service.

Does this affect Windows installations of vCenter Server?

Yes, the VMSA describes the versions affected.

Does this affect vCenter Server 6.0?

The VMSA describes the versions affected.

Does this affect vCenter Server 6.5?

The VMSA describes the versions affected.

What if I migrated from Windows vCenter Server 6.5 to the appliance version of vCenter Server 6.7? Do I still need to patch?

Yes. The VMSA describes the versions affected.

How can I get the fix for this issue without updating all of vCenter Server?

As the VMSA states there are no workarounds. As such, the patch for this vulnerability is only found in the complete update to the version of vCenter Server listed in the VMSA.