Vulnerability (Text4Shell) (CVE-2022-42889)

[#1]

Greetings Cloudera Community!!

Text4shell vulnerability is impacting the apache application which is using commons-text version 1.5 to 1.9 and our application Nifi version 1.16.2 hosted on linux server (Red Hat Enterprise Linux Server 7.9) is using commons-text version 1.8 jar file in lib folder.

Can anyone please help to figure out the best solution to handle this vulnerability in our production servers: We have few queries for the vulnerability:

1:Is the nifi version 1.16.2 application is affected by this vulnerability? 

2: In Nifi configuration files, we are not using any calls related to StringSubstitutor API. Are we still     vulnerable to test4Shell? 

3: If nifi version 1.16.2 vulnerable then can we just replace the commons-text jar file from 1.8 to 1.10 in nifi 1.16.2. Is there any impact of this in our prod servers?

Please do let us know on this vulnerability for nifi 1.16.2. If it is impacting nifi 1.16.2 version then what would be the best solution to mitigate this vulnerability.

Vulnerability Details:

Release Date: 18th October 2022

CVE Detail: CVE-2022-42889

CVSS Score: Critical (9.8)

Affected Products:

* Apache Commons Text versions 1.5 through 1.9

* This vulnerability is a remote code execution (RCE) vulnerability, that arises from insecure implementation of Commons Text's variable interpolation functionality, where some default lookup strings could potentially accept untrusted input from remote attackers, such as DNS requests, URLs, or inline scripts and can allow an attacker to execute arbitrary scripts passed to the created interpolator object.

* This vulnerability exists in the StringSubstitutor interpolator object.

Recommendation:

* Upgrade immediately to Apache Commons Text version 1.10.0

Ref: https://www.imperva.com/blog/apache-commons-text-vulnerability-cve-2022-42889/

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

Thank you!

Girish

[#2]

@Girish007  do you have any update on this CVE-2022-42889 Vulnerability?

[#3]

@hanumanth I'm just curious as to exactly how you or @Girish007 have determined that a specific release of NiFi is vulnerable to the aforementioned CVE?

[#4]

@ask_bill_brooks not only for NIFI ,this vulnerability has been raised for below path also..

/opt/hadoop/yarn/nm/filecache

/opt/hadoop/yarn/nm/usercache

[#5]

@hanumanth, Exactly how are you determining that the file path you've identified is exposed to the CVE-2022-42889 vulnerability?

[#6]

@ask_bill_brooks  Our application went through a security scan for this vulnerability which scans for "commons-text" library versions. If "commons-text" library version from 1.5 to 1.9 is present in your Application Lib folder then it would raise a security vulnerability alert. But we  are yet to figure out if nifi 1.16.2 is actually vulnerable to this Text4Shell or not. 

Because our application is not using StringSubstitutor API. 

[#7]

@Girish007 

The reason I was asking is because what kind of "security scan" you performed matters a great deal. Certain security scan applications are pretty basic and only look at a list of vulnerabilities and the libraries exposed to them and then compare that to a list of libraries using specific version numbers found on/retrieved from the deployed system in question. Many times, this will lead to "false positives" because the system is not actually vulnerable due to the specific way the library is used. Other times, the system vendor will have addressed the vulnerability by changing the code included in the library, without changing the name of major release number denoted in the filename.

In the specific case you're interested in, Apache Commons Text is a very popular library, so there are just going to be widespread references to vulnerable versions across anything that uses Apache code. For Apache NiFi, authoritative sources tell me that on initial investigation, NiFi had no direct uses of the vulnerable class, but had many transitive references to the library and that this was patched last month in the open source repository, so updates will be making their way to new versions.

You can view the upstream Jira issue here:
NIFI-10648

[#8]

I did not find anything under the Knowledge Base, and I have not seen a TSB recently.

It does not look like this is specifically a nifi issue, as CDH 7.1.7 SP1 (even p1057) seems to include 1.6-1.9.

This is the announcement from Apache ->

https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om

=====
CVE-2022-42889: Apache Commons Text prior to 1.10.0 allows RCE when applied to untrusted input due to insecure interpolation defaults
Severity: important
Description: Apache Commons Text performs variable interpolation, allowing properties to be dynamically evaluated and expanded. The standard format for interpolation is "${prefix:name}", where "prefix" is used to locate an instance of org.apache.commons.text.lookup.StringLookup that performs the interpolation. Starting with version 1.5 and continuing through 1.9, the set of default Lookup instances included interpolators that could result in arbitrary code execution or contact with remote servers. These lookups are: - "script" - execute expressions using the JVM script execution engine (javax.script) - "dns" - resolve dns records - "url" - load values from urls, including from remote servers Applications using the interpolation defaults in the affected versions may be vulnerable to remote code execution or unintentional contact with remote servers if untrusted configuration values are used. Users are recommended to upgrade to Apache Commons Text 1.10.0, which disables the problematic interpolators by default.
Mitigation: Upgrade to Apache Commons Text 1.10.0.
=====

Is there a time frame for using 1.10?  If not, that's fine too.

From a recently-updated cluster:

=====
/opt/cloudera/parcels/CDH-7.1.7-1.cdh7.1.7.p1057.32088321/jars/commons-text-1.6.jar
/opt/cloudera/parcels/CDH-7.1.7-1.cdh7.1.7.p1057.32088321/jars/commons-text-1.7.jar
/opt/cloudera/parcels/CDH-7.1.7-1.cdh7.1.7.p1057.32088321/jars/commons-text-1.9.jar
...
/opt/cloudera/parcels/CDH-7.1.7-1.cdh7.1.7.p1057.32088321/lib/solr/server/solr-webapp/webapp/WEB-INF/lib/commons-text-1.6.jar
/opt/cloudera/parcels/CDH-7.1.7-1.cdh7.1.7.p1057.32088321/lib/streams_messaging_manager/libs/commons-text-1.9.jar
/opt/cloudera/parcels/CDH-7.1.7-1.cdh7.1.7.p1057.32088321/lib/streams_replication_manager/lib/commons-text-1.9.jar#
=====

[#9]

@ask_bill_brooks Thanks for the updates:)

So, apart from upgrading from nifi 1.16.2 to newer nifi version, Can you please suggests any other fix that we can implement in our production environment to mitigate Log4shell vulnerability.

But before that we just need to confirm:

Do we really need to upgrade our current nifi version 1.16.2 to newer version ?

As it is mentioned in NIFI-10648 , under worklog that apache nifi does not include any direct references to the vulnerability instance. Please refer to the attached screenshot and let us know your suggestions.  

Thank you!

[#10 · Accepted solution]

@Girish007 Sorry, no.

I can't suggest any other fix that you can implement in your production environment to mitigate the  Log4shell vulnerability. And I would go further and say that I seriously doubt that anyone in a responsible position is going to tell you that you don't "really need to upgrade [y]our current nifi version 1.16.2 to a newer version" in spite of the fact that this specific situation is a great example of how a supposed "important" vulnerability brought to light by certain security scan applications really isn't actually relevant due to the specific way the library is used in a delivered system (which was the point I was trying to make earlier in this thread).

I have no doubt at all as to the accuracy of the assessment in the aforementioned Jira, and I also would strongly recommend that you plan to upgrade your current nifi version. My current understanding is that NiFi 1.19.0 included the library upgrade, and the forthcoming CFM 2.1.5.0 version will also include Apache Commons Text 1.10.0.