Is ArcGIS affected by CVE-2022-42889 (Apache Commons Text versions 1.5 through 1.9)

[DominikWyroba]

Hello,

Is there any info if ArcGIS is affected by new vulnerability CVE-2022-42889 (Apache Commons Text versions 1.5 through 1.9)?

[George_Thompson]

@RandallWilliams 

[RandallWilliams · Accepted solution]

There's a lot of undue media hype regarding this issue floating around. This is NOT a Log4j type event. 

Some less sensational writeups of this issue are available that provide good context that describe the low likelihood of  this issue being exploitable in software, eg:

https://portswigger.net/daily-swig/apache-commons-text-rce-resemblance-to-log4shell-but-exposure-ris...

https://www.rapid7.com/blog/post/2022/10/17/cve-2022-42889-keep-calm-and-stop-saying-4shell/

To that end, Esri is aware of and is in the process of performing the due diligence to evaluate any impact of the recently announced Apache Commons-Text vulnerability traded as CVE-2022-42889 in the context of our products.

Esri is unaware of any instance of ArcGIS Software being exploited by CVE-2022-42889 at this time, and as of this writing there have been no reports of CVE-2022-42889 exploited in the wild reflected in the CISA Known Exploited Vulnerabilities Catalog.

We will provide additional details regarding our findings to our customers as we complete our validation.

[AnnetteFarrell]

Our security department have asked us to patch our public facing ArcGIS Enterprise 10.9.1 environments.  Will a patch be released and if so when will it be available?

[Mark_Verlaat]

I'm getting the same question. The security department saw that there is an issue on an ArcGIS Enterprise environment. I would like to know, for sure, that AGE is not being the one causing the Apache Vulnerability. 

[RandallWilliams]

I think it's important for users and security teams to have context into how commons-text version 1.10 was updated in order to address CVE-2022-42889. I'll pull heavily from Apache's blog describing this issue. 

https://blogs.apache.org/security/entry/cve-2022-42889

Key take aways (emphasis mine):

• If you rely on software that uses a version of commons-text prior to 1.10.0, you are likely still not vulnerable: you are only affected when this software uses the StringSubstitutor API without properly sanitizing any untrusted input.
• If your own software uses commons-text, double-check whether it uses the StringSubstitutor API without properly sanitizing any untrusted input. If so, an update to 1.10.0 could be a quick workaround, but the recommended solution is to also properly validate and sanitize any untrusted input.

More:

"Apache Commons Text is a low-level library for performing various text operations, such as escaping, calculating string differences, and substituting placeholders in the text with values looked up through interpolators. When using the string substitution feature, some of the available interpolators can trigger network access or code execution. This is intended, but it also means an application that includes user input in the string passed to the substitution without properly sanitizing it would allow an attacker to trigger those interpolators."

"For that reason the Apache Commons Text team have decided to update the configuration to be more "secure by default", so that the impact of a failure to validate inputs is mitigated and will not give an attacker access to these interpolators. However, it is still recommended that users treat untrusted input with care."

"We're not currently aware of any applications that pass untrusted input to the substitutor and thus would have been impacted by this problem prior to Apache Commons Text 1.10.0."

What does this mean?

It means that in commons-text 1.10 (the "patched version" of this component, the vulnerable feature is disabled by default. But...what happens if a vendor actually USES that feature (hint: everyone using commons-text uses this feature)? The vendor still MUST sanitize the input in the first place - and that's always been heavily emphasized in the Apache commons documentation - nothing changes there. 

We are in the process of finalizing our evaluation of Esri software and will post the results of this analysis. Like all of our security advisories and notifications, you'll find it soon on the front page of the ArcGIS Trust Center. 

[JoëlHempenius3]

Hi Randall,

Thanks for this response. The technical perspective to this issue is totally clear to me now.

However, there is this organization perspective as well. And there things work a little different, at least for the company I work as consultant right now.

They have these Tenable.io security checks which they run every weekend and I'm pretty sure that the affected file will be found this next weekend. So there is no check whether Esri or any other company did some proper programming or not, the file is there, high CVE score, so people start asking questions. And these people happen to be security officers and managers, so they don't know all the details from a specific software. They have this Tenable.io dashboards and see all these high CVE warnings popping up and they simply want to get rid of them. The most easy way to do so is to ask everybody to apply a patch. But if there isn't a patch available, somebody has to take the decision to accept that this isn't a real threat and that no further action has to be taken. Problem here is that this person will also be held accountable for this decision, and they don't want to, because there is no direct benefit for them, because they're not responsible for the application themselves and in the unlikely situation, when they agreed to accept it, and things go south, it's their head which will get chopped off (which they don't want). So that's why I would like to see a patch from Esri. Not because patching would make the application better or more secure, but because it keeps the security dashboards in green, security managers happy and I can continue building GIS apps which help the organization achieve its goals instead of having endless technical discussions about whether this vulnernability is a real threat or not and that they should make an ignore rule on the Tenable dashboard.

[JoëlHempenius3]

My security department isn't asking questions yet, but I after the Nessus Security scan which is performed every weekend, I think they will. 

The context you provided is very helpful. Impact shouldn't be there, when other hardening actions are taken, especially whitelisting on the outbound http proxy should mitigate any possible vulnerability.

Nevertheless, I think it should be patched to the 1.10.0 version, it's easier to explain that the vulnerability isn't there than it is to explain that the vulnerability cannot  be exploited. So please patch this to 1.10.0 if possible. 

[DominikWyroba]

Thank you for quick answer. 

[Chaitanya_Ganjam]

Is there any update in this.