First things first, let’s be clear that this is NOT a new Log4Shell or Spring4Shell vulnerability. Although it is a remote code execution issue, the impact is neither as severe nor as easily exploitable as the issue in Log4j from December 2021.
Similar to the Log4j issue, the essence of the problem is that you can perform a lookup that can then be misused. However, the Log4shell vulnerability was very easy to exploit — which is not necessarily the case this time. In reality, this issue is very similar to CVE-2022-33980, which we wrote an article about earlier this year.
Explaining the Apache commons-text security issues
In the Apache Commons Text library, you can perform the variable interpolation. This allows you to load properties that can be dynamically evaluated.
The issue is in StringLookup, which performs the lookups. These lookups are expressions that can resolve dns records, load values from urls, and execute scripts using a JVM script execution engine. These urls and scripts can originate from remote sources triggering remote code executions if untrusted values are used. This is reported as a high severity vulnerability in CVE-2022-42889, and occurs in versions 1.5.x through 1.9.x.
CVE-2022-42889 examples
Below, you see two examples of these kinds of scripts using either the Nashorn or JavaScript engine. Using the interpolatorStringLookup directly, or via the StringSubstitutor (which is probably more common), will give the same result.
Note that the Nashorn scripting engine is no longer available by default in Java 15 and later versions. So, these scripts will only be executed if you provide a script engine yourself. However, because many enterprises still depend on older versions like Java 8, this can be a serious problem. If you are on the latest LTS version Java 17, neither the JavaScript nor the Nashorn script will execute, as there is no engine available by default.
Remediation for CVE-2022-42889
Let me again emphasize that this is not Log4Shell all over again. You probably don’t use StringLookup yourself, but you do not know if any of your transitive libraries are. The easiest way to resolve this issue is upgrading to commons-text version 1.10 (or later), which disables the prefixes URL, DNS, and script by default — and making arbitrary code execution impossible via this route.
Scanning with Snyk can help determine if this vulnerability is present in your stack. If detected, update to version 1.10 and run snyk monitor in the CLI to continue monitoring in production.
Scan your code for free
Create a Snyk account today to protect your code from CVE-2022-42889 and millions of other vulnerabilities.
Top comments (0)