Here is latest VMware Advisory:
VMware Response to Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
VMware VMSA-2021-0028: Questions & Answers for Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
This vulnerability is an industry-wide one, in a component called “log4j” that is used to log information from Java-based software. This vulnerability is critical, rated 10 out of 10 on the CVSS 3.1 scoring scale, because it is an unauthenticated remote code execution (RCE) vulnerability, allowing attackers to run commands on affected systems by simply getting them to log a specific string.
Generally speaking, every piece of software that has ever used log4j is potentially vulnerable. VMware uses log4j as well, which is why we are reacting to this. However, this vulnerability also affects customer workloads, too. Customers need to assess their entire environment for use of log4j, in infrastructure and workloads, and remediate it as soon as possible either through patches or workarounds.
The vulnerability was announced by the Apache Foundation suddenly, as a “0-day” or “zero day” vulnerability, taking everybody by surprise. Normally a vulnerability is reported privately to the software maintainers who then have time to repair the issue and release an update so attackers don’t have a temporary advantage. That isn’t the case this time. Regardless of the timing, the ubiquitous use of log4j means that no matter when this vulnerability surfaced it was likely to have a huge impact. While disclosure going into a weekend is bad timing, it’s good that it did not happen later in the calendar year.
VMware Customers should subscribe to the VMSA mailing list and continue to monitor the VMSA page itself, as well as the linked resources like the QandA/FAQ. They also should be assessing everything else in their environment, because lots of other software incorporates log4j. This issue isn’t a VMware-specific problem, it’s an “everything everywhere” problem.
Lately I’ve been looking into virtualizing latency sensitive applications like the ones used in a lot of financial institutions. In vSphere 6 and below, configuring SR-IOV to hardware accelerate network traffic for latency sensitive VM’s would limit the vSphere features per the SR-IOV Support documentation. This is also true with DirectPath I/O. However, the good news is that vSphere 7 has a new feature called Assignable Hardware that has two consumers; The new Dynamic DirectPath I/O and NVIDIA vGPU. Dynamic DirectPath I/O helps by providing the same functionality as ‘legacy’ DirectPath I/O, but does not pin a workload/VM to a host. This brings back HA and DRS Initial placement to VM’s configured for latency sensitive applications. vMotion is not supported because vSphere cannot live migrate a VM that is directly tied to a physical device. SR-IOV devices are also supported by Assignable Hardware when used as pure passthrough devices.
The VMware High Performance Compute team has been working with our vSphere development teams to bring more capabilities to high performance compute and latency sensitive virtualized workloads without sacrificing bare metal performance.
For more details on Assignable Hardware, check out:
vSphere 7 – Assignable Hardware
vSphere 7 – Using Assignable Hardware with Dynamic DirectPath IO