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.
Hi
In the workaround section for 6.7 VCSA the following statement is made:
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
6.7 P05 is Build 17700523. That means your Build is after P05.
see the following KB:
https://kb.vmware.com/s/article/2143832
@vMakeITWork we need vCenter Server Appliance 6.7 P05 build number not ESXi 6.7 P05. 😉
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
@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.
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)
Hi, now it is more clear. 😉
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
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
The version of vCenter Server was changed. From 6.7 u3m to 6.7u3o.
Hi, Please go here https://www.vmware.com/security/advisories/VMSA-2021-0028.html for the latest updates.
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.)
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 ... 🙂
Hi, If today I do the workaround when release the fix, do I update normally or should I undo the workaround first? Thank you!
@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
Thanks a lot!
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.)
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?