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,

[RexRobichaux]

Hello @RandallWilliams, 

I was wondering if it'd be feasible to include language that Esri is still investigating this issue (45105) (and/or any relevant updates) in the public-facing bulletin? In particular in regards to Enterprise components? Our IT oversight agency is becoming more alarmed as we approach the holiday weekend and it would be ideal to provide them some sort of update for our GIS servers for this CVE. I noticed the WAF language, however that's not managed at our level (actually by the oversight agency). Thanks as always for any updates you can provide!

[RandallWilliams]

@RexRobichaux we plan to update again later today. 

[RexRobichaux]

Fantastic- thanks Randall! 

[Lu-chiaChuang]

Here an update on the issue. Esri supports weren't able to resolve this issue. So we restored the Datastore server from VMWare backup. The restored Datastore works just fine.

We decided to try the patch again (Installed ArcGIS Pro, ran the patch, and uninstalled ArcGIS Pro). Merry Christmas. It works this time. Thanks for all of your suggestions. 

[BrianParker2]

So just to confirm does removing the JNDIlookup class remedy https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105 ?

[RandallWilliams]

We’re in the process of finalizing our review if this new CVE.

We also provided a significant update to our advisory on the Trust center today.

[BrianParker2]

Just looking at the Red Hat Solution https://access.redhat.com/security/cve/cve-2021-45105 

They mention Replace $${ctx:loginId} pattern with %X{loginId} in the Context Map Lookup https://logging.apache.org/log4j/2.x/manual/lookups.html#ContextMapLookup 

Where on the ESRI System would I find the application log mentioned?

[RandallWilliams]

You wouldn't - we don't use this pattern for contextLookup and that's why this CVE isn't exploitable in our software. 

[MattFancher1]

I ran the Esri mitigation script for GeoEvent on a 10.7.1 server. Following execution of the script a security scan still found the JNDI class here:

C:\Program Files\ArcGIS\Server\GeoEvent\data\cache\bundle8\version0.0\bundle.jar

Any advice? TIA

[RandallWilliams]

The reason you’re potentially seeing that file is that GeoEvent Server effectively has two copies of the contents of the Jar files when running. One copy, which the script is specifically targeting for GeoEvent Server in the System folder path, and a second unpacked version within the data folder. As a part of the script guidelines for GeoEvent Server we instruct users to delete the contents of the Data folder (including subfolder) which the Windows & Linux services/daemons are stopped. Once the script finished running and the services restarted, GeoEvent Server will unpack PAX jar (and all others we’re using) and store them in the cache bundles. Within a given release those will consistently be in the same location (e.g. bundle8) but with each release those could get unpacked into different locations. Again for that reason we instruct users to delete all of the contents in the data folder as opposed to searching in specific bundles. It will add a minute or so to the initial start-up time, but is the best way to ensure nothing remains of the vanilla/unmodified files.