VMware Cloud Community
osheehy
VMware Employee
VMware Employee

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

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.

Reply
0 Kudos
25 Replies
jwdg
Contributor
Contributor

Hi

In the workaround section for 6.7 VCSA the following statement is made: 

NOTE:- The below workaround is applicable for vCenter Server Appliance 6.7 P05 and Older versions only.

I'm not clear where that version naming fits into the numbers I'm familiar with - In my case I have build 18485185 (6.7U3o) - is this before or after P05? 

Thanks

John

 

Reply
0 Kudos
vMakeITWork
Contributor
Contributor

6.7 P05 is Build 17700523. That means your Build is after P05.

see the following KB:

https://kb.vmware.com/s/article/2143832

 

Reply
0 Kudos
MartinLucanskyU
Contributor
Contributor

@vMakeITWork we need vCenter Server Appliance 6.7 P05 build number not ESXi 6.7 P05. 😉

Reply
0 Kudos
behrent
Contributor
Contributor

I have to chime in with John (jwdg) here: the workarounds described in https://kb.vmware.com/s/article/87081?lang=en_US#vCenter6.7 are targeted towards vCenter Server Appliances - and there is no such thing as a "vCenter Server Appliance 6.7 P05": VCSA-naming-schemes are different (see: https://kb.vmware.com/s/article/2143838).

The suffix "6.7 P05" refers to the ESXi build 17700523, that's correct - but ESXi itself is not affected by the Log4j2-RCE-vulnerability.

So the note "The below workaround is applicable for vCenter Server Appliance 6.7 P05 and Older versions only." is confusing in different ways: what if you're running a vCenter Appliance 6.7 Update 3p (6.7.0.51000), VAMI-Build: 18831133? The Jndi-Lookup-Class exists in both jar-files (Analytics and CM, /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar, /usr/lib/vmware-cm/lib/log4j-core.jar), but it is totally unclear, what this note is referring to (Analytics only? both Analytics and CM service?)

What side effects are to be expected if you apply the workarounds to a "newer" VCSA (6.7.0.51000 U3p, 6.7.0.50000 U3o) or in other words: what's the reason for this warning note with no correct VCSA-Build-referral?

Please advice,
Nico

Reply
0 Kudos
baijup
VMware Employee
VMware Employee

@behrent @jwdg Thanks for posting the questions. vCenter Server Appliance 6.7 P05 is actually U3m (vCenter Appliance 6.7 Update 3m 6.7.0.47000). We agree to the concerns mentioned in this thread, just changed P05 to U3m in the VMSA workaround KB.

We will also look at the other questions mentioned in this thread and circle back with updates.

Reply
0 Kudos
vMakeITWork
Contributor
Contributor

Correct, P05 is a name for ESXi Patches (has been mistakenly used). If you look at the release date of this ESXi Patch P05 and then look for the same release date of the vCenter Patch on the according KB

https://kb.vmware.com/s/article/2143838

you can see that they actually meant vCSA 6.7 U3m (which has been corrected now)

Reply
0 Kudos
MartinLucanskyU
Contributor
Contributor

Hi, now it is more clear. 😉

NOTE:- The below workaround (Analytics service) is applicable for vCenter Server Appliance 6.7 Update 3m and Older versions only.

Reply
0 Kudos
dddlee77
Contributor
Contributor

Hi, I have a question.

Currently, I'm using the NSX for vSphere.

Does this issue also occur in NSX for vSphere Versions 6.3.x and 6.4.x ?

I can't see the NSX for vSphere in the list on this page.

https://www.vmware.com/security/advisories/VMSA-2021-0028.html

Reply
0 Kudos
osheehy
VMware Employee
VMware Employee

As per the above, this is a developing situation and the information in the VMSA will be updated with all the latest information. 

Please ensure that you revisit the advisory throughout the day. A number of products are still under investigation and updates will continue throughout the day

MartinLucanskyU
Contributor
Contributor

The version of vCenter Server was changed. From 6.7 u3m to 6.7u3o.

NOTE:- The below workaround (Analytics service) is applicable for vCenter Server Appliance 6.7 Update 3o and Older versions only.  The JAR is already updated to 2.11 on the later versions.

Reply
0 Kudos
SMcClure1
VMware Employee
VMware Employee

Hi, Please go here https://www.vmware.com/security/advisories/VMSA-2021-0028.html  for the latest updates. 

takedahideyuki
Contributor
Contributor

Hello, I have a question about workaround of vCenter and  vCenter server appliance.

Is there any disadvantage if we do workaround? (eg. the log level become down or certain log messages are not generated.)

Reply
0 Kudos
markus101
Contributor
Contributor

Concerns VCSA 6.7:

In my opinion, the section "verify the changes - step 2" is not 100% precise, if VCSA newer than Update 3o.
grep -i jndilookup /usr/lib/vmware/common-jars/log4j-core-2.8.2.jar | wc -l
returns "1"

but:
ps auxww | grep analytics | grep formatMsgNoLookups
returns that "-Dlog4j2.formatMsgNoLookups=true" IS used

That's logical, because analytics service on Update 3p works with log4j version 2.11, not 2.8. So "verify the changes - step 2" is ONLY important, if VCSA is on Update 3o or older and you have done the mitigation described under "Analytics Service". Here should be a note too, to prevent confusion. At least I was a bit confused ... 🙂

SMcClure1
VMware Employee
VMware Employee

Content is being update frequently  

For Tanzu you can find updated KBs and Answers here

For VMware Core you can find updates KBs and Answers here

Reply
0 Kudos
MrtnsPaul
Contributor
Contributor

Hi, If today I do the workaround when release the fix, do I update normally or should I undo the workaround first? Thank you!

Reply
0 Kudos
baijup
VMware Employee
VMware Employee

@MrtnsPaul Q7 in official Q&A for this VMSA-2021-0028 would help - https://core.vmware.com/vmsa-2021-0028-questions-answers-faq#sec19130-sub7

Reply
0 Kudos
MrtnsPaul
Contributor
Contributor

Thanks a lot!

Reply
0 Kudos
casaub
Enthusiast
Enthusiast

Hello,

reg. vCSA 6.7.0.51000 U3p (release 18831049).

 

We noticed one difference in the workaround KB87081, under 'Verify the changes' it is saying:

 

    2. Verify the Analytics Service changes:

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

                This should return 0 lines

 

But the output from our vCSA is:

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

                1

 

 

The output of the other query

 

    3. Verify the CM Service changes:

               grep -i jndilookup /usr/lib/vmware-cm/lib/log4j-core.jar | wc -l

                This should return 0 lines

 

is showing what it should:

                # grep -i jndilookup /usr/lib/vmware-cm/lib/log4j-core.jar | wc -l

                0

 

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.)

 

Reply
0 Kudos
EWensell
Contributor
Contributor

If a version is not listed, is it considered not vulnerable? 

Example: SRM 8.3, 8.4, 8.5 listed as vulnerable. What is the status of SRM 8.1?

Reply
0 Kudos