In case you haven’t heard, Apache Log4j is arguably the biggest vulnerability found across the board since Spectre/Meltdown vulnerabilities were disclosed, due to the sheer scope of the vulnerability. It is found everywhere and unfortunately, is found across a large swath of VMware solutions, including VMware vCenter Server. Let’s take a look at VMware vCenter Server Log4j patch script remediation process and see how you can remediate your vCenter Server.
***Update*** The screenshots below show the script as vmsa-2021-0028-kb87081.py. This has been superceded by the vc_log4j_mitigator script. However, the process to run the script is the same.
VMware vCenter Server Log4j patch script remediation process
The great thing about VMware is they have been extremely transparent on all the solutions where the vulnerability is found and the workaround or patches (if these exist) with links to relevant KB articles. You can find the link to all of these in my blog post initially covering the Log4j vulnerability and is VMware affected.
Since vCenter Server is a critical part of the vSphere infrastructure, getting it patched is extremely important. However, at this time, an official patched version of vCenter Server has not been released as of yet. Unfortunately, the manual process to remediate the Log4j vulnerability in vCenter Server is nasty and involves editing many low-level files in vCenter Server.
You can see the full list of files that need to be changed in the official VMware KB 87081 here:
- Workaround instructions to address CVE-2021-44228 in vCenter Server and vCenter Cloud Gateway (87081) (vmware.com)
Thankfully, a Python script has been written that automates the process to remediate your vCenter Server from the Log4j vulnerability.
VMware vCenter Log4j workaround Python script
Since there is no official patch for vCenter Server as of yet, we will need to rely on the workaround that is found in the VMware KB article. The Python script makes the process a whole lot easier than it would be with the manual edits, and also helps to ensure these edits are performed correctly and consistently.
First, to download the Python script, check out the official link to the KB here:
- Python script to automate the workaround steps of VMSA-2021-0028 vulnerability on vCenter Server Appliance (87088) (vmware.com)
The steps are simple:
- Download the script
- Upload the script to your vCenter Server appliance
- Run the Python script
1. Download the script
Visit the official link, linked above to download the Python script. You will need to save this locally on your client and then upload to your vCenter Server.
2. Upload the script to your vCenter Server appliance
You will want to use SSH or a GUI tool like WinSCP to upload the Python script to your vCenter Server appliance. The KB article mentions you can upload to the /tmp directory. However, I simply used the root home directory as this directly has much less “noise” than the /tmp directory.
3. Run the Python script
Once you have the script uploaded, the last step is to simply run the Python script on your VCSA appliance. To do that, use the command:
You will see a request to restart services on your VCSA.
Below, you see the initial python command to run the script, the prompt to restart services, and the output as the script runs through remediating your vCenter Server appliance.
After the VMware vCenter Server Log4j patch script remediation process, I didn’t see any ill effects on the lab vCenter Server used to test. Again, the Python script makes the remediation process much easier than the manual edits required for implementing the Log4j remediation manually.
Video showing the Log4j patch remediation process for vCenter Server
The Log4j vulnerability and remediation process is a continually evolving situation and VMware is definitely helping customers to get their environments remediated quickly. While official patches are yet to be released across the vCenter Server landscape, these are no doubt coming soon. It is great to know though that we have a remediation process to mitigate the vulnerability in the meantime. Stay tuned for further updates and information on the Log4j saga.