How to protect against CVE-2022-42889

A new Common Vulnerability and Exposure (CVE) — CVE-2022-42889, aka Text4Shell — was recently released, adding to the pile of more than 20,050 that have already been released so far this year. 

Text4Shell has garnered a lot of attention (and, at least preliminarily, caused more than its share of anxiety). If successfully exploited, it could allow attackers to remotely execute arbitrary code on a machine and to compromise the entire host. You can see why it’s caused some people to worry, given the possibility of remote-code execution (RCE) and the fact that CVE-2022-42889 is rated a 9.8 out of 10 — Critical — on the CVSS severity rating scale. 

However, Contrast Security’s got you covered: Users can scan, detect and protect against Text4Shell with Contrast Protect and Contrast Software Composition Analysis (SCA) solutions. Read on for more about the vulnerability and how to protect against it. 

Text4Shell ≠ freak-out worthy

As research from Contrast Security Labs Teams quickly revealed, Text4Shell isn’t nearly as exploitable as initially perceived, given that very few people use the interpolator function of the Apache Commons Text library — the exploitable function at the heart of the vulnerability. 

To be clear, Text4Shell isn’t like the notorious Log4j. While it’s true that both Log4j and Text4Shell involve serious vulnerabilities in ubiquitous open-source libraries, the Log4j issue was far more exploitable than Text4Shell. Log4j entailed ubiquitous applications accepting and logging user-controlled input that could easily trigger the Log4j exploit far more easily than Text4Shell can be triggered. 

And while it’s true that the commons-text library at the heart of Text4Shell is ubiquitous, the vulnerable component isn’t commonly used. In fact, Contrast’s data shows that 21% of Java applications package the commons-text library. Out of that number, only 11% of Java applications package a vulnerable version of commons-text. The kicker: Exactly ZERO% of those applications are using the vulnerable class.

TL;DR: How much damage can attackers do if they find a vulnerable version of the commons-text library? It’s moot: There’s a 0% chance of it happening, because 0% of applications are running the vulnerable class. 

One thing to bear in mind: The only thing that the Commons text fix did was to disable the problematic functionality by default. It's still there, since it’s a feature, specifically built in with a default setting of “on.” The only difference now is that developers would have to enable the feature for it to be an issue. 

Although Text4Shell is nowhere near as critical as Log4Shell, it’s still essential for security and development teams alike to be aware of this vulnerability and to have concrete rules in place to scan, detect and protect against it. 

How to protect yourself from Text4Shell

First things first: Throw Contrast Protect at it. We know it works. We know that Protect — which detects and blocks run-time attacks on known and unknown code vulnerabilities — blocks Text4Shell, just as it blocks attacks against other vulnerabilities before they’ve been fixed or patched. Contrast Protect blocked the Text4Shell attack, providing zero-day protection without any changes. That means that users’ systems were safe, without any tuning or reconfiguration, with Object-Graph Navigation Language (OGNL) rules enabled. Unlike perimeter defenses, Protect’s instrumentation and sensors accurately detect and block runtime application attacks. As well, it doesn’t leave you guessing whether zero days managed to reach their target: You can get a firm yes or no on that point. What’s more, Protect can fend off many zero-day attacks without tuning or reconfiguration.

We could tell that an application was vulnerable to Text4Shell because of Contrast’s runtime SCA: It can tell what users are running and can present all the details, making it easy to dig in and see if you’re running a vulnerable version of a given component — in this case, the Apache Commons Text library. Contrast SCA can also let you know if you’re using the actual vulnerable component. Customers using SCA can update their libraries and look for the vulnerable classes to determine if they may have a vulnerable path by examining the class usages within the Contrast Platform for the commons-text library, as shown below. It’s extremely easy.

Don’t freak out/don’t relax

Just because Text4Shell turned out to be a non-event doesn’t mean that we can relax. The vulnerabilities keep coming, and you need to be ready for them — not by waiting for announcements and scary headlines, nor by merely scanning perimeter defenses, but rather by detecting risky behavior before apps get released. 

With just two months left in the year, Contrast is forecasting that 2022 will peak in terms of the total number of CVEs released when compared with prior years. In fact, year over year, the total number of CVEs released per year has skyrocketed since 2017, as shown in the graph below: a trend that’s likely to continue. 

Source: CVE.ICU 

They’re not just increasing in number; they’re also increasing in severity. This year alone, we’ve seen an uptick in the release of ever-more critical CVEs such as Spring4Shell and Log4j that have garnered worldwide attention, affecting organizations and governments around the world. 

The average CVSS score of CVEs this year has been high, at 7.2. It’s like a disastrous hurricane picking up speed. As such, these CVEs are gaining the wrong type of attention from bad actors: the kind of attention that could be dangerous to companies, their brands and their data. 

These trends pose a great question: With more storms ahead, do organizations have the right protection to ensure they’re blocking attacks in order to forestall damage? Most companies aren’t prepared to weather the storm of future CVEs. In fact, most are unprepared to even understand which applications might be vulnerable to begin with, increasing their risk now and in the future. 

But the fact that CVEs are coming in harder and faster doesn’t mean that you have to jump on fixing all these issues, because the reality is that there are tools like Contrast that can help you mitigate and that can stop things before they start. That’s not just a bunch of marketing-speak: It’s what customers have experienced in scenarios such as Log4j and Spring4Shell. "With Contrast, we were able to find where Log4j was in seconds,” said one customer in the financial services industry. “It took days and was painful ([we had to] run scripts, advanced searches) with the open-source vendors we use for SCA — and that's their ONE job. Glad to have Contrast Protect to avoid that [patching] cycle on some apps, at least.”

Don’t be like most companies. The strategic approach isn’t to sit on your hands. It’s to use the tools that exist to help you deal with these things. Be like the companies that keep an eye on CVE trends, that understand that more critical CVEs are inevitable, and to batten down the hatches before they get hammered. If you’re running Protect, you know you’re protected. You also can — and should — check SCA to see where the vulnerable elements are. 

Then, once you determine that you’re not vulnerable, you can prioritize properly. You don’t have to keep your software engineers working over the weekend, and you know you don’t have to freak out over every single reported detection of a vulnerability in something like Commons text. 

See how to stop vulnerabilities before they flatten you: Get in touch to arrange a demo of Contrast Protect and SCA today.