log4j - CVE-2021-45105

412
3
12-21-2021 11:24 AM
JoePlattner
New Contributor III

I've been asked to look into assisting with mitigating CVE-2021-45105 in our ARCGIS enterprise environment. Searching log4j, I did not find any other discussions relating to this specific CVE so I'm asking it here.

The python script only seems to address CVE-2021-44228 and CVE-2021-45046.

Anyone else working on this, or have a solution?

The ESRI blog referencing this reccomends applying Web Application Firewall rules to mitigate this. ESRI tech support (even our premium support tier) is unable to advise or assist us with these firewall rules.

So I've forwarded the Web Application Firewall doc included in the log4j blog post from ESRI  to our network team, and while I'm waiting for them to get back to me, I thought I'd see if anyone else has done anything on this specific CVE.

0 Kudos
3 Replies
RandallWilliams
Esri Regular Contributor

We are nearing our investigation regarding this issue and plan to update our Log4J statement later today to include information regarding CVE-2021-45105.

JoePlattner
New Contributor III

Thank you. I saw that the blog article had an update today. 

from the blog ... "Initial Post 12/12/21 – Last Updated 12/22/21 – 10:30am PT"

I saw that the guidance re: CVE-2021-45105 is still to implement a WAF. Hopefully other recommendations will be coming soon. 

Thanks,

Joe

 

 

0 Kudos
BrianParker2
New Contributor II

Just checking what other vendors have suggested.

The specific flaw exists within the StrSubstitutor class. The issue results from the lack of proper validation of user-supplied data, which can result in a resource exhaustion condition. An attacker can leverage this vulnerability to create a denial-of-service condition on the process.

recommends write-protecting Log4j configuration files.

My question would be for ESRI - Is removal of the StrSubstitutor class an option?

 

0 Kudos