How to Protect Yourself Against the Text4Shell Security Vulnerability

By Guest Author Teja Myneedu, Director—Product Security Engineering and Research, TripActions

Following the Log4Shell exploit discovered in Java logging library Log4j in December 2021, it is the latest trend to sensationalize all new Java library vulnerabilities with the name ‘4shell’. After Spring4Shell earlier this year the latest vulnerability is Text4Shell. Text4Shell is the nickname for CVE-2022-42889 which is similar to the other vulnerabilities in a few ways. But is it as detrimental to the security of software as Log4j? Let’s find out. 

What is Text4Shell? 

Text4Shell is a vulnerability within versions 1.5 to 1.9 of Apache Commons Text Java library. The vulnerability was originally reported in March 2022 by Alvaro Munoz, and was announced on October 13, 2022 within the Apache developer mailing list. 

The Text4Shell exploit enables an attacker to get shell or code execution access within a system that runs a Java program which uses the affected version of the Apache Commons Text library. 

Who is impacted?

Any software program written in Java which uses versions 1.5 to 1.9 of the Apache Common Text library has the potential to be impacted. Specifically, if the StringSubstitutor interpolator object is used in the program and if user input is passed to the interpolator object, it is possible to exploit it. Therefore this vulnerability is not as critical as Log4j because exploitation requires a vulnerable pattern in application code in addition to a vulnerable version of Apache Commons Text being present.

How do you find out if you are impacted?

Having a Software Bill of Materials (SBOM) across the inventory of all your products will help you quickly identify whether the affected library versions are used in your business or personal context. However, this is not sufficient because this doesn’t text you if the vulnerable pattern within application code exists within your software. To determine whether a vulnerable pattern in application code exists, you can use static analysis tools, but they cannot always detect all patterns, especially within large applications with complex code flow. The best and fastest way to validate whether your applications are affected is by using tools like Deepfactor Developer Security to see if the exploit is successful at runtime. Deepfactor observes the program execution for stack traces that indicate the usage of the StringSubstitutor interpolator object. 

What steps should you take to protect yourself against Text4Shell?

The first step should be to determine whether you are affected. If you are, it is important to upgrade your Apache Commons Text library to at least version 1.10 or later right away. In addition, there are a few runtime indicators of compromise you might want to examine in order to determine if there were any exploitation attempts. While Application Logs help with this, most developers don’t turn on debug logging in production. Deepfactor can help set up a quick custom alert to detect exploit attempts if you have it deployed in your production environment. 

Quick Clip: Learn about Deepfactor Developer Security’s Software Bill of Materials