Hi,
Are any of the components included in any Horizon products vulnerable to CVE-2021-44228? Horizon comprises from many Java programs, so is there any of them using Log4j as their logging framework and if it is so, are the used versions vulnerable to this CVE?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
pretty sure that view horizon server 8.2 is affected, newer versions probably also...
C:\Program Files\VMware\VMware View\Server\broker\webapps\portal\WEB-INF\lib\log4j-core-2.13.3.jar
C:\Program Files\VMware\VMware View\Server\lib\log4j-core-2.13.3.jar
C:\Program Files\VMware\VMware View\Server\messagebus\kernel\sys$authentication\log4j-core-2.13.3.jar
VMware Response to CVE-2021-44228: Apache Log4j Remote Code Execution (87068)
Am told this KB is to be updated soon
I'm not sure if that KB covers all.
Attackers use ip:port to execute attack, not standard LDAP ports as there is answer in some of KB. Also they use no_dns_lookups also.
more on tag: CVE-2021-44228
Follow this security advisory for affected products https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Thanks.. I was following that.. I’m a bit confused though.
So VMware mentions UAG’s are effected, but does not talk about the security servers. However the remediation talks about the connection servers and the agent.
Feels like a disconnect. Under a standard setup the Connection servers wouldn’t be exposed right?
I suppose you remediate Security Servers as you would remediate Connection Servers as per kb 87073. Both are Windows Servers.
Here's a script to aid you and others with the remediation.
<#
.SYNOPSIS
CVE-2021-44228 – VMSA-2021-0028 - https://kb.vmware.com/s/article/87073 mitigation script
.NOTES
Author: Perttu
Contact: https://communities.vmware.com/t5/user/viewprofilepage/user-id/2180740
#>
$registryKeys = 'HKLM:\Software\VMware, Inc.\VMware VDM\plugins\wsnm\MessageBusService\Params',
'HKLM:\Software\VMware, Inc.\VMware VDM\plugins\wsnm\TomcatService\Params',
'HKLM:\Software\VMware, Inc.\VMware VDM\plugins\wsnm\TunnelService\Params'
$property = 'JVMOptions'
$fix = ' -Dlog4j2.formatMsgNoLookups=true'
foreach ( $regKey in $registryKeys )
{
try
{
$propertyValue = Get-ItemPropertyValue -Path $regKey -Name $property
} catch {
# Windows 2012 R2 with built-in PS version 4.x does not include Get-ItemPropertyValue cmdlet
$propertyObj = Get-ItemProperty -Path $regKey -Name $property
$propertyValue = $propertyObj.$property
}
if ( $propertyValue -notmatch $fix )
{
Write-Host "Fixing $regKey by appending$fix to its $property property value."
$newValue = $propertyValue + $fix
Set-ItemProperty -Path $regKey -Name $property -Value $newValue
}
else
{
Write-Host "$regKey has the fix already"
}
}
We utilized GPO to inject the instaclone agent machine registry key to the Horizon agent service. It applies Local Machine policy before the Horizon agent is started with the added Dlog4j2.formatMsgNoLookups key.
We verified by having our security team scan the Horizon desktop and found no apache log vulnerability to assure GPO applied the patch and passed validation. Hopefully, the updated agents will be released soon.
If GPO is used, just make sure it is in the VDI Active Directory OU and reboot the instant clones. (Tested for instant clones but linked clones you will need to recompose )
Thanks for posting.
The Connection servers need 3 reg keys modified with a reboot or Horizon broker service restart. The external UAGs have a patch released.
Does anyone know the status of App Volumes? I'm assuming that VMWare is indicating it's not impacted because it's not listed as a Horizon fix, but I did notice log4j components on the App Volumes Manager. Can anyone confirm?
I'm not absolute sure, but I think App Volumes is mostly written with Ruby. Hence if no Java, then no Log4j. However there might be some additional tools written in Java present on installations, but I would not be worried about those whenever they are not running services open to internet allowing user input.
@coreyberla Could you please clarify which specific log4j components are you referring to?
Advisory doesn't specify if Security Servers will need the same patches as the Connection Servers. Anyone know of any additional info regarding the Security Servers?
edit
@matthewgONCU vmware often doesn't consistently refer to registry keys and values correctly.
edit JVMOptions value that you have selected and append -Dlog4j2.formatMsgNoLookups=true to it. e.g. just follow the syntax of the other values. Presumably there may be different data for JVMoptions, but since yours appears to be the same as mine this reg illustrates the intent:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\Node Manager\JVM]
"JVMoptions"="-Xmx32m -Djdk.tls.ephemeralDHKeySize=2048 -Dlog4j2.formatMsgNoLookups=true"
YMMV
Can we get clarification, does -Dlog4j2.formatMsgNoLookups=true actually mitigate the vulnerability at all? From what our Security team is telling us with the second vulnerability in Log4j discovered, this mitigation is now worthless and easily bypassed. They are saying that the only true mitigation is updating the Log4j component to version 2.16, which was just released.
VMWare just release this statement
Notice: On December 14, 2021 the Apache Software Foundation notified the community that their initial guidance for CVE-2021-44228 workarounds was not sufficient. We believe the instructions in this article to be an effective mitigation for CVE-2021-44228, but in the best interest of our customers we must assume this workaround may not adequately address all attack vectors.
We expect to fully address both CVE-2021-44228 and CVE-2021-45046 by updating log4j to version 2.16 in forthcoming releases of vCenter Server, as outlined by our software support policies. VMSA-2021-0028 will be updated when these releases are available. In the interim, we will be updating this Knowledge Base article with revised guidance to remove all JndiLookup classes per Apache Software Foundation guidance. Please subscribe to this article to be informed when updates are published.
VMWare's way of saying - "Look to your own defenses"
Actually I'd intepret that more as patches are the only real option, and the unfortunalty will take time. They are frequently updating the information which is the best we can get right now, and to clarify I don't work for vmware.