Log4j 1.x Enterprise Dependency Requirement

[DeanMoiler]

Hi Everyone,

I'm just following on from the fun, excitement that was and continues to be the Log4j Vulnerabilities and the following cyber security team scanning of additional risks relating to this.

As raised by @Pei-SanTsai in this incredibly useful thread there are also 1.x versions of log4j showing up on security scans as it achieved End Of Life (EOL) back in 2015. @RandallWilliams indicated there are dependencies within Enterprise components, such as "Zookeeper" and "ElasticSearch" that may still require these libraries in order to function as expected.

I've not been able to find any official word from Esri relating to this as the focus has rightly been on the exploit discovered in version 2, only in the Esri vulnerability guidance that:

"Base ArcGIS Enterprise components do not utilize and are therefore not vulnerable to:
–  Log4j 1.2 JMSAppender – CVE-2021-4104"

From what we've been advised there may still be an exploit in the version that exists within zookeeper (we're on AGS 10.8.1):

It does seem to still be relevant for versions 1.2 --> 1.2.17 as in Apache's EOL reference and the associated CVE-2019-17571.

Are there any mitigations known for this that could be implemented, without affecting Enterprise environments? Current requests from security team are to delete or rename these files, but hopefully there is a better solution out there.

Thanks!

Dean

[JeffSmith]

Hi Dean,

No, Esri has not released an official mitigation script to address any of these log4j 1.x vulnerabilities.  That being said, we are actively working on patches for all components of ArcGIS Enterprise that will update the log4j 2.x jar files to 2.17.1 and remove the vulnerable classes from the log4j 1.x jar files.  We can't provide a release date for them but they are taking the highest priority right now.

As you and Randall have mentioned, there are dependencies on some of the log4j 1.x so those jar files cannot just be deleted and replaced with the 2.x jar files.  

[DeanMoiler]

Hi @JeffSmith,

Thanks for the response, that's very helpful. I have let the cyber security team know that there is a patch being developed to deal with all log4j 1.x 'critical' issue, with the caveat on timeframe as you mentioned.

Do you have any idea as to whether there will be a python script for 1.x mitigation like there was with 2.x prior to the patch being officially rolled out?

Thanks!

Dean

[JeffSmith]

No, as of right now there are no plans to release a python script for the 1.x mitigation similar to what was done for 2.x.

[DeanMoiler]

Thank you for the clarification Jeff. I will pass to the CS team.

Thanks,

Dean

[RandallWilliams · Accepted solution]

All, note that customers with IA teams concerned about Log4J issues in 2.x or 1.2.x) that we do not explicitly target in our mitigation scripts can consider using a tool like Logpresso's log4j-scan tool. This tool is endorsed by CIS, is frequently updated, and well documented. While it does not update Log4J, it does remove vulnerable classes - and the vulns it doesn't address are documented. 

[DeanMoiler]

Thanks for pointing us towards this @RandallWilliams , I'm sure it will come as very welcome to those with CS teams that do not wish to wait for the official patches!

This fix looks as though it operates in a similar fashion to the log4j 2.x python scripts provided previously, and removes the offending classes within the libraries for particular vulnerabilities, rather than removing the packages themselves.

I would imagine upgrades could be performed on the "fixed" versions themselves without issue.

Does this sound reasonable, or would the classes need to be "unfixed" prior to upgrading?

[RandallWilliams]

@DeanMoiler Our patches will handle this, but I've been telling people to not delete the backup files that the Logpresso tool created in case they need to be restored. Logpresso provides a command for restoring.