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,

[DharaniM]

This suggestion is workaround not a solution. 
ArcGIS and Apache Log4j Vulnerabilities (esri.com)

[DEWright_CA]

The issue here is that the ESRI platform is using a lot of tools/components from other groups (ElasticSearch) that have this as a nested dependency. So they are in the place to wait for that component to be patched/upgraded to then upgrade their versions.

This is a much bigger issue than anyone really sees in this scramble.

[SimonSchütte_ct]

The latest blog posts provides Log4Shell mitigation scripts that are strongly recommended.

[RexRobichaux]

I just ran these scripts in our Dev environment and all worked well...now moving on to our other environments. Huge thanks to @RandallWilliams  and the rest of the dev and security teams for making these scripts available so quickly!

[ThomasIllingworth]

Quick question regarding the python 3 requirement we are running twin 10.6.1 servers I can see the directory specified for python 3 in the article do we need to actually run the executable to install python or is it already installed? When we do the CMD I can tell we call the exe just wanting to making sure we didn't need to run it separately beforehand.

Sorry if this seems a silly question

Thanks

Tom

[RexRobichaux]

Hey Tom, 

 Python 3.x is already installed with ArcGIS Server and the executable resides in that directory. So, all you are doing in command prompt is pointing the python executable in that location, to the python script file you downloaded, and providing a command for the script(--list or --delete) for example (assuming you have CD'd to the same folder/directory where Esri's log4shellmitigation.py script resides): 

List the .jar files:

"C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\bin\Python\envs\arcgispro-py3\python.exe"  log4shellmitigation.py  --list  "c:\Program Files\ArcGIS\Server" 

Delete the offending code in the identified .jar files: 

"C:\Program Files\ArcGIS\Server\framework\runtime\ArcGIS\bin\Python\envs\arcgispro-py3\python.exe" log4shellmitigation.py  --delete "C:\Program Files\ArcGIS\Server"

I hope this helps!

Example of the list command being run via the script: 

[ThomasIllingworth]

Hey Rex 

Thanks for confirming thought was the case just wanted to make sure 🙂

Thanks for the helpful comments and images above as well 🙂

Thanks

Tom

[RandallWilliams]

Thanks @RexRobichaux and others! No-sleep Randall is still trying to keep up. 

I'm sure inquiring minds and IT departments want to know and are asking:

"WAIT WAIT WAIT - the version numbers on those files have NOT CHANGED! WHERE'S MY LOG4J 2.16 ERMAGERD!!""

Here's the deal:

A. check out Apache's statement: https://logging.apache.org/log4j/2.x/security.html

Log4j 2.x mitigation: Implement one of the mitigation techniques below.

• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For expediency, we have elected to take the third option. It eliminates the source of the vuln - which is the fact that JNDILookup was enabled by default. The fix Apache provided in Log4J 2.15 was to make this an OPTIONAL tool. We have eliminated this class altogether. 

Like I mentioned in an earlier reply, we'd dearly love to just upgrade Log4j and make everyone's vuln scanners test clean. That's just not realistic this early in the game. 

Think about this in term of other vendor patches - a Microsoft patch for any give issue might go through multiple iterations before an issue is fully fixed. It's easily possible that even if we could patches for all upstream vendors aligned, Apache will release Log4J 2.17 to fix a whole different but similar issue. None of us have time to chase that. So we've provided what we can provide NOW based on the Log4J docs to mitigate this issue and help make you safe while this continues to shake out.

This won't be the last issue to shake the internet - that's the only thing I can promise without any doubt. 

[MullaiManickavalli]

The bash script for linux throws error,

-bash: ./log4shellmitigation.sh: /bin/bash^M: bad interpreter: No such file or directory

works when edited with "sed -i -e 's/\r$//' log4shellmitigation.sh". 

[RandallWilliams]

@MullaiManickavalli Yes, we're aware. There's a windows linebreaks issue in the file, It should be fixed very soon. Good catch and fix.