Headline
Why Log4Text is not another Log4Shell
Categories: Exploits and vulnerabilities Categories: News Tags: Log4Text
Tags: Apache
Tags: Commons Text
Tags: CVE-2022-42889
Tags: Log4j
Tags: Log4Shell
Tags: interpolators
Log4Text is a recently found vulnerability in Apache Commons. Log4Text provoked a knee jerk reaction because it reminds us of Log4Shell. So should we worry?
(Read more…)
The post Why Log4Text is not another Log4Shell appeared first on Malwarebytes Labs.
Posted: October 19, 2022 by
The Apache Software Foundation has acknowledged a vulnerability in Apache Commons Text, a library focused on algorithms for string manipulation.
The vulnerability has been assigned CVE-2022- 42889, but security researchers have dubbed it Log4Text. The name provides an immediate association with Log4Shell which had quite the impact and ranked #1 in the CISA top 5 most routinely exploited vulnerabilities of 2021.
Apache Commons Text is a library that focuses on algorithms for string manipulation, which means it is used for various text operations, such as escaping, calculating string differences, and substituting placeholders in the text with values looked up through interpolators.
The problems lies in those interpolators. You can compare these interpolators to environmental variables. When called, an interpolator will return the value of that variable, and in order to do that they sometimes have to execute commands.
Vulnerability
The full description of the vulnerability is:
“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.”
Quickly summarized, this means an attacker with a successful exploit could extract information from the memory, set up internet connections, and execute arbitrary commands.
Similarities
Log4Shell and Log4Text are both vulnerabilities in widely used Apache libraries and they do have some things in common, so it’s understandable that people are worried.
Both of the vulnerabilities rely on un-sanitized input, which means that the input provided by users is not checked, cleaned, and filtered before it reaches the application.
The possible implications of a successful exploit are very similar to those of Log4Shell. Both of the vulnerabilities are found in a widely used Apache library and both depend on variable substitution, which look for patterns like ${something}, and replace them with other pieces of information.
The difference
The big difference lies in the use-case for the two Apache libraries. Apache Commons Text is specifically designed for this kind of text manipulation while Log4j was built for logging only. This also has implications for where the libraries are used. IT and security folk want to log as much as they can, so Log4j shows up in more online applications than we would ever expect Apache Commons Text to.
It also means that the interpolators are used in a library where they are expected and they’ll usually be there on purpose. It also limits the options that it provides an attacker. Where Log4Shell was very easy to exploit, Log4Text requires a lot more effort and advanced knowledge of the target to be successfully exploited.
Mitigation
Users should upgrade to Apache Commons Text 1.10.0, which disables the problematic interpolators by default.
Make sure that user input gets sanitized before it reaches your application, service, or server. This will also help to prevent abuse as a result of vulnerabilities that haven’t been found or published yet.
RELATED ARTICLES