ArcGIS Enterprise Log4j Vulnerability (CVE-2021-44228) Patch or Mitigation?

[Carl_Flint]

Good afternoon, is there any patches in the works or potential mitigation steps for the latest java log4j vulnerability (CVE-2021-44228)?  I know that GeoEvent server uses log4j and can assume some other enterprise server's or portal potentially do as well.  Any help would be appreciated in resolving this zero-day.

Thanks,

[AndrewFarrar]

Ran these scripts against our 10.6 Portal, Data Stores, and Server installs today, and the process went smoothly.  I had to install python 3 on our Datastores, but it was a very easy process to follow.  I uninstalled python on those machines after it was finished. Just wanted to say thank you to the ESRI team for the fix,  documentation, and transparency.  

[TonyCollins]

Hi, could I ask what Python 3 package you installed as we need to do this. Was it a full version or a cutdown version?

[Scott_Tansley]

I've been using the Winpython64-3.10.0.1dot libraries:

https://github.com/winpython/winpython/releases/tag/4.6.20211106

https://github.com/winpython/winpython/releases/download/4.6.20211106/Winpython64-3.10.0.1dot.exe

[AndrewFarrar]

I just used the standard Python 3.10 install package from python.org.  Its the full install, just used all of the defaults, and then pointed the script to the python.exe as mentioned in the docs. 

https://www.python.org/downloads/release/python-3101/

I uninstalled it from our Data Store servers after I was done. 

[mfresali]

I just run on client Enterprise version 10.8.1, unfortunately, we have some issue with Web App that several items cannot be loaded to the application. Is the any way to rollback again the script mitigation?

Thanks

[randoodlydingdangdodlyWilliams]

This it is possible to roll back the script, we don't document it publicly because there really should be no reason. It doesn't impact anything other than removing a class from the log4j jar. 

Instead, perform some troubleshooting:

Review the GIS Server log files

Make sure the password for your ArcGIS process owner (the ArcGIS Account) hasn't expired

Check your licenses

Give the Server and Datastore windows services a restart

etc...

Rolling back these changes should be the last thing you consider - not the first.

[Lu-chiaChuang]

Just want to give a warning on applying this patch for a multi-machine ArcGIS Enterprise environment. 

We are unable to publish hosted feature layer after applying this patch to our company's multi-servers ArcGIS Enterprise 10.8 environment. We have been working with Esri support today and without much progress.

We don't have any issue with our single-machine ArcGIS Enterprise 10.9.1 or other standalone ArcGIS Servers. 

Luke

[RandallWilliams]

This isn't related to the Log4j scripts we've provided. I've seen something similar. Try restarting the datastore service. I believe there's a bug out there support logged. 

[RexRobichaux]

Hello @RandallWilliams I just wanted to confirm that the current mitigations scripts don't remedy the newly discovered CVE-2021-45105 ?

Does Esri plan to update the current scripts to perform the mitigation measures for this new DOS vulnerability? 

It looks like the mitigation options (aside from upgrading to the new 2.17 version is): 

In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).

Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

This hits just keep coming with this one don't they? Hope you and others are getting a little sleep at least! https://logging.apache.org/log4j/2.x/security.html

[RandallWilliams]

We are aware of this new issue and are investigating. I'm not yet sure we set those non-default patterns and if we do, where.