As of yesterday, VMware released the vCenter Log4j fixes for releases 6.5 and 6.7 of both their vCenter Server Appliance and vCenter Server (for Windows). Combined with the previously released vCenter 7.0 patch, VMware now offer complete protection against the currently disclosed Log4j vulnerabilities within the VMware vCenter product.

What version do I need?

Depending on whether you’re using vCenter 6.5, 6.7 or 7.0, and whether you’re using the vCenter Server Appliance or vCenter Server (6.5 & 6.7 only) you’ll need one of the following:

• VMware vCenter Server Appliance 7.0 U3c
• VMware vCenter Server Appliance 6.7 U3q
• VMware vCenter Server 6.7 U3q
• VMware vCenter Server Appliance 6.5 U3s
• VMware vCenter Server 6.5 U3s

What CVE’s does this resolve? Weren’t there more Log4j Vulnerabilities announced?

It’s probably worth a brief timeline to make this easier:

CVE-2021-44228, AKA the ‘original’ Log4j vulnerability

Impacted all Log4j versions between 2.0beta9 through to 2.15.0, with a few exclusions. In 2.15.0 the default behaviour of Log4j was changed and the exploited functionality was removed completely in 2.16. 2.16 is the minimum version required to be protected against this CVE completely.

CVE-2021-45046, AKA another JNDI exploit angle

When Log4j 2.15.0 was released, people believed that as the exploitable behaviour was mitigated, however it had failed to account for certain non-default configurations, giving rise to this secondary exploit. VMware vCenter and other VMware products were impacted by this, and so workarounds were still required to mitigate this behaviour.

CVE-2021-45105, AKA is this ever going to end?

With Log4j 2.16.0 released, the exploited functionality from the original Log4j vulnerability removed entirely and lessons learned from the other JNDI exploit angle, hopes were high this would be the real fix. Unfortunately it was incomplete, and leveraging uncontrolled recursion could enable the same exploitation as CVE-2021-45046 again. Even worse this exploit was able to impact older versions of Log4j, all the way back to 2.0-alpha1. This was resolved in Log4j 2.17.0, but VMware products were not affected by this vulnerability regardless.

CVE-2021-44832, AKA Log4j-FOREVER

With a slightly less exploitable scope of 2.0-beta7 through to 2.17.0 (Yes, the release that fixed the other three known Log4j exploits), a remote code execution (RCE) was discovered in a far more complicated attack that had additional dependencies including requiring the victim to be using an JDBC Appender and control of the target LDAP server. Thankfully fixed in 2.17.1 and VMware again wasn’t impacted by this.

CVE Conclusion – VMware vCenter 7.0

VMware have upgraded VMware vCenter 7 to 2.17.0, which when combined with the invulnerability to the last two CVEs, provides complete protection against all known Log4j exploits. VMware have committed to upgrading to the latest Log4j release in a future release of vCenter 7.0 to have complete protection against the currently deemed “unexploitable” Log4j vulnerabilities.

CVE Conclusion – VMware vCenter 6.7 & 6.5

VMware have a more complicated upgrade path with VMware vCenter 6.7 & 6.5. As there is the use of both JDK 7 and JDK8. Within the JDK8 framework, Log4j has been patched to 2.17.0, which protects against the first two Log4j vulnerabilities detailed above on this framework, whilst the remaining two CVEs are unexploitable on the VMware vCenter configuration. But vCenter 6.7 & 6.5 also use the JDK7 framework, which doesn’t support Log4j 2.17.0, instead however there is an update that mitigates these vulnerabilities that does support JDK7, Log4j 2.12.4, which is the version that VMware have upgraded to, this offers complete protection against all four CVEs detailed above, even the ones that VMware is vulnerable to in 2.17.0 but is not exploitable.

Closing Comments

This isn’t the end for Log4j vulnerabilities, but at least VMware have patched most of their products, and have workarounds for the ones without a patch currently. If you have any other VMware products and want to check if you’re on a vulnerable version, see the full list here.