SBN

Log4Shell, Spring4Shell, and Now Text4Shell?

The CVE-2022-42889 that was dubbed as Text4Shell or ACT4Shell created a lot of noise on social media when it was published (on October 13th), mainly because of the comparison to Log4Shell.

For those who are not familiar with Log4Shell and Spring4Shell you are welcome to visit our previous blog posts.

What is Text4Shell?

CVE-2022-42889 is a 9.8 Critical Remote Code Execution (RCE) vulnerability that abuses the Apache Commons Text interpolation functionality in String Substitution, discovered by Alvaro Muñoz in March 2022.

The Apache Commons Text is a java open-source library that performs algorithm operations on text.

The attacker can access the DNS, URL, and Script lookup keys using the String Substitution function.

Via accessing these lookups and keys, the attacker can map the entire network, access sensitive files, or remotely execute commands.

String Substitution

The basic idea of ​​the String Substitution feature in Apache Commons Text is reminiscent of the format string feature in Python.

The purpose of this feature is to allow inserting different values into a string using variables.

Example of format string (Python):

variable_one = ‘people’

variable_two = ‘table’

f‘The {variable_one} are sitting at the {variable_two}’

The Output

The people are sitting at the table

Example of string substitution (commons-text)

In the Apache Commons Text, an instance of string substitution is created and initialized with the map that sets the values of the variables.

Map<String, String> valuesMap = new HashMap<>();

valuesMap.put(“variable_one”, “people”);

valuesMap.put(“variable_two”, “table”);

Then the variables are substituted in the text.

String templateString = “The ${variable_one} are sitting at the  ${variable_two}.”;

StringSubstitutor sub = new StringSubstitutor(valuesMap);

String resolvedString = sub.replace(templateString);

The Output

The people are sitting at the table

The string substitution also supports default value for unresolved variables, recursing instances for example a variable value that contains a variable and using interpolations.

String Substitution Interpolator

When using the string interpolator, you can access the following string lookups like this (the bold section is the lookup part):

final StringSubstitutor interpolator = StringSubstitutor.createInterpolator(); 

final String text = interpolator.replace(

“Base64 Decoder: ${base64Decoder:SGVsbG9Xb3JsZCE=}\n” +

“Base64 Encoder: ${base64Encoder:HelloWorld!}\n” +

“Java Constant: ${const:java.awt.event.KeyEvent.VK_ESCAPE}\n” +

“Date: ${date:yyyy-MM-dd}\n” +

“Environment Variable: ${env:USERNAME}\n” +

“File Content: ${file:UTF-8:src/test/resources/document.properties}\n” + “Java: ${java:version}\n” +

“Localhost: ${localhost:canonical-name}\n” +

“Properties File: ${properties:src/test/resources/document.properties::mykey}\n” +

“Resource Bundle: ${resourceBundle:org.apache.commons.text.example.testResourceBundleLookup:mykey}\n” +

“System Property: ${sys:user.dir}\n” +

“URL Decoder:           ${urlDecoder:Hello%20World%21}\n” +

“URL Encoder:           ${urlEncoder:Hello World!}\n” +

“XML XPath: ${xml:src/test/resources/document.xml:/root/path/to/node}\n”);

The interpolator format is “${prefix:name}”, in the Resource Bundle, the prefix represents the lookup and the name represents the key.

The lookup and the key can be replaced with any of the existing default lookups and keys (will be covered below).

Fix

The fix for the vulnerability was in the Apache Commons Text 1.10.0 version which was released on September 24th.

In the fix, the maintainer created the DEFAULT_STRING_LOOKUPS_PROPERTY and did not include the affected string lookup keys (dns, url, script).

When installing the 1.10.0 and above versions of Apache Commons Text library, the affected string lookup keys (dns, url, script) will not be available to use.

The only way to use these keys in the new form is to either explicitly enable the key lookup as a default lookup using the “org.apache.commons.text.lookup.StringLookupFactory.defaultStringLookups” property OR add it programmatically.

Here you can see the description of the default String Lookups and the additional String Lookups (not included by default):

The DEFAULT_STRING_LOOKUPS_PROPERTY was added by the addDefaultStringLookups(Map) method.

The definition of the default String Lookups:

The initialization of the new default String Lookups property:

Maintainer Instructions

In their security.xml file, the maintainer of the Apache Commons Text package wrote the following:

“If you rely on software that uses a version of commons-text prior to 1.10.0, you are likely still not vulnerable: only if this software uses the <code>StringSubstitutor</code> API without properly sanitizing any untrusted input.”

Remediation

Since the vulnerability was fixed in the 1.10.0 version, it is recommended to upgrade the Apache Commons Text to 1.10.0 version and later.

When upgrading to the following versions after 1.10.0, make sure not to enable string lookups (dns, url, script).

Mitigations

  • Remove the affected string lookups (dns, url, script) from the StringLookupFactory.
  • Sanitize any untrusted input when using APIs, which is important regardless of this vulnerability.

Am I Exploitable (MI-X)?

You are affected by the Text4Shell only if these conditions are met:

  • Your system has an application that uses the string substitution of the Apache Commons Text versions 1.5 through 1.9.
  • The DNS, URL, and Script String Lookup keys are set.
  • You are not sanitizing user control input which uses the StringSubstitutor API.

The Comparison to Log4Shell

Log4Shell and Text4Shell were both discovered in java open-source projects.

However, the String Substitution is not as common as Log4j, there are 2,591 projects that use the affected Apache Commons Text library versions, but apparently, there are not many projects that use the Substitution method and not sanitizing untrusted input.

Multiple pre-conditions have to be inplace in order for Text4Shell to be exploitable.  Adding the fact that the String Substitution method without sanitizing the input is not a very common practice, makes the comparison to Log4Shell unjustified.

That said, it is important to check whether your system is affected and remediate or mitigate the vulnerability in case it is.

The post Log4Shell, Spring4Shell, and Now Text4Shell? appeared first on Rezilion.

*** This is a Security Bloggers Network syndicated blog from Rezilion authored by Ofri Ouzan. Read the original post at: https://www.rezilion.com/blog/log4shell-spring4shell-and-now-text4shell/