19.9 C
Thursday, June 13, 2024

How to Detect and Fix the “Text4Shell” Vulnerability

What is Text4Shell

Similar to the Spring4Shell and Log4Shell vulnerabilities, Text4Shell is a new vulnerability reporter by Alvaro Munoz, in the Apache Commons Text library. Read further to learn how to detect and fix the Text4Shell vulnerability.

It is a remote code execution vulnerability and has a very high rating of 9.8 under CVE-2022-42889 and could permit an attacker to execute arbitrary code on the machine and compromise the entire host.

- Advertisement -

How dangerous is Text4Shell really?

Despite the high CVSS score assigned to this vulnerability, it should be noted that the use of the vulnerable component of the Apache Commons Text library is unusual in the processing of untrusted user-controlled inputs.

This situation means that the probability of exploitation of this vulnerability CVE-2022-42889 is quite low compared to Log4Shell, but you still need to take action to detect and fix the Text4Shell vulnerability.

How to check if you are vulnerable to the Text4Shell vulnerability

To be vulnerable, you must:

  1. Use Apache Commons Text version 1.5-1.9 inclusive
  2. Have code using the StringSubstitutor class with variable interpolation
  3. Have a mechanism of accepting input and passing it into the StringSubstitutor class

Docker vulnerability scanning tools including the docker scan CLI and Docker Hub Vulnerability Scanning, powered by Snyk, will detect the presence of the vulnerable versions of the library and flag your image as vulnerable (see below).

Note that you may not be vulnerable even if you’re using these versions, as your code paths may already mitigate this by either not using the vulnerable methods, or by not passing in user input into them (see the Mitigations section below). This may be difficult to validate, however, without understanding all the code paths in detail and where they may get input from. So the easiest fix is simply to upgrade all applications depending on vulnerable versions.

You can use docker scan to check if the image has the vulnerability. If Text4Shell is present you will see a message in the output log like this:

  Upgrade org.apache.commons:[email protected] to org.apache.commons:[email protected] to fix
 ✗ Arbitrary Code Execution (new) [High Severity][https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-3043138] in org.apache.commons:[email protected]
 introduced by org.apache.commons:[email protected]

To test this, you can check a vulnerable image, for example, this neo4j image contains a vulnerable version of commons-text at /var/lib/neo4j/lib/commons-text-1.9.jar:

docker scan neo4j:latest@sha256:17334cbc668d852ca8a3d8590f66c4fda64d9c7de7d93cc62803f534ae7dbce6

Scanning with BurpSuite for Text4Shell

You can also use a new BurpSuite plugin that has been developed by SilentSignal to aid in the detection of the Text4Shell vulnerability.

text4shell apache

If you’d like to scan only for CVE-2022-42889 (and not other things such as XSS or SQLi), this plugin makes it possible.

By following the instructions below, the scanner will only perform Text4Shell checks on all insertion points if the scan configuration created as a result is used.

  1. When creating a new scan, click Select from library on the Scan configuration tab
  2. Pick Audit checks - extensions only which is built into Burp Suite Pro 2.x
  3. Disable every other extension (if applicable) that has an active scan check registered (such as ActiveScan++, Backslash powered scanning, Burp Bounty, etc.) so that only the Text4Shell scanner runs

How to fix the Text4Shell vulnerability

To fix this vulnerability, you should update the application to version 1.10.

The fix applied by the Apache team was the removal of the DNS, script, and URL lookups from the default interpolator behavior.

In the StringLookupFactory.createDefaultStringLookups() method the DefaultStringLookup.DNS, DefaultStringLookup.URL and DefaultStringLookup.SCRIPT is now not added by default. In the previous versions, all the DefaultStringLookup instances were added by default.

In case an upgrade is not possible, the StringSubstitutor can be initialized with safe StringLookup configurations.

If dangerous lookups are necessary for the application, all user input should be sanitized before being interpolated. A possible solution can be the use of a whitelist in the input validation phase.

Website | + posts

Also Read