CVE-2021-44228 -- Apache Log4j - Remote code execution vulnerability

[osheehy]

VMware has released a critical security advisory, VMSA-2021-0028. This advisory is for multiple VMware products that use the popular open source log4j Java logging component, which was discovered to have a critical vulnerability.

Due to the 0-day nature of this disclosure, this will be a developing situation. Please subscribe to our Security Advisories mailing list and ensure that you revisit the VMSA-2021-0028 advisory periodically to get the latest information. 

First, if you haven’t read the original advisory or are a returning visitor here are some links to the different resources available:

VMware Security Advisory VMSA-2021-0028 (descriptions of the issues and workarounds)
VMSA-2021-0028 Questions & Answers (common questions & answers hosted in VMware Tech Zone)
Tips for Patching VMware vSphere (practical advice for ensuring patching success)
VMware vSphere Security Configuration Guide (baseline security best practices for vSphere)
VMware Ransomware Resource Center (discussion around tactics to help prevent, deter, and recover from attacks)
VMware Ports & Protocols Firewalling Guidance (ports.vmware.com)

The current expectation is that we will be publishing a number of product specific KBs with a workaround which is designed to be a temporary solution, pending the release of an upgrade/patch for the impacted product.

As such, the current recommendation is that you review the advisory and implement any workarounds or product updates as soon as possible.

If your product is pending an update, the advisory will be updated with the workaround/upgrade details as they become available 

Please fell free to post any questions you may have here and we will be happy to help in any way we can.

[behrent]

---

@casaub wrote:

... 

So one of these is not correct. Is there an error in KB87081 or is our vCSA having an issue?

(We did not run the workaround for 'Analytics Service' because it says: applicable for vCSA 6.7 Update 3o and older versions only.)

---

Your result is -as far as I can tell- perfectly fine:

The workaround-part you did not apply (Analytics Service) is responsible for "zeroing" out the grep result (deleting the JndiLookup.class from the jar) - but this is not needed on U3p, since the jar-file /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar is no longer used in this release (Hello? Housekeeping anyone?)

Nevertheless, the "Verify the changes"-section does not reflect the fact, that there are different approaches for <= U3o and U3p.
The workaround KB-article is a living document and VMware started out without these insights, so step 2 in the verification process is only relevant for VCSA 6.7.50000 (U3o) or less and does not take the version-differentiation in account.

Step 2 of the verification instruction for 6.7.x should sound:

2. Verify the Analytics Service changes (ONLY if you are on U3o or older)

BTW: This is exactly what @markus101 noted here, but the instruction was not clarified since.

[baijup]

@EWensell Details mentioned in the Related Information section in the KB https://kb.vmware.com/s/article/87123 would help to address your query. You may search for keyword SRM 8.1.x in this KB.

[casaub]

For vCSA 6.7.0 U3p, the answer was given indirectly by VMware today by corrected version of KB87081,  see Note:

2. Verify the Analytics Service changes:

grep -i jndilookup /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar | wc -l
 

Note: This should return 0 lines. This does not apply to vCenter 6.7 U3p.

[Dan_Johnson]

According to this https://kb.vmware.com/s/article/87123

"Note: Products older than SRM 8.3 are beyond End of General Support date, so patches will not be made available for these older versions. As there may be other non-validated exposure, VMware recommends updating EOGS versions to a supported release as a priority.
SRM 8.1.x and 8.2.x on Windows or Photon Appliances were shipped with log4j 1.x. Based on https://logging.apache.org/log4j/2.x/security.html we believe these versions are not exposed to CVE-2021-44228 because the product uses log4j 1.x and does not have JMSAppender configured in its log4j configuration. Customers are urged to monitor https://logging.apache.org/log4j/2.x/security.html as guidance from the Apache Logging team may change.  It is important to note that Log4j 1.x has reached end of life and is no longer supported by the Apache Logging team. As per https://logging.apache.org/log4j/2.x/security.html "Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed". VMware strongly recommends upgrading to a supported version of SRM to minimize exposure."

[thomasicbcs]

Hi, my setup for vCenter 6.5 is that the PSC functionality is separated from the vCenter Appliance itself.

I assumed that the PSC appliance were affected by Log4j and thus need to be rectified like the vCenter appliance but my team disagree with me for some reason.

Am i right on this?

[baijup]

@thomasicbcs You are absolutely right, you need to apply the steps on PSC as well.

Execute both the scripts :
- remove_log4j_class.py attached to KB 87081 and
- sctipt vmsa-2021-0028-kb87081.py attached to KB87088