CVE-2022-42889 im Überblick: Die Schwachstelle zur Ausführung beliebigen Codes in Apache Commons Text

Eines vorweg: Dies ist KEINE neue Log4Shell- oder Spring4Shell-Schwachstelle. Zwar handelt es sich um ein Problem, das die Remote-Ausführung von Code ermöglicht, doch die Auswirkungen sind weder so schwerwiegend noch lässt sich die Schwachstelle so leicht ausnutzen wie die Log4j-Schwachstelle vom Dezember 2021.

Ähnlich wie beim Log4j-Problem besteht der Kern der Schwachstelle darin, dass eine Suche durchgeführt werden kann, die sich anschließend missbrauchen lässt. Die Log4Shell-Schwachstelle war jedoch sehr leicht auszunutzen – was diesmal nicht unbedingt der Fall ist. Tatsächlich ähnelt dieses Problem sehr stark CVE-2022-33980, über das wir Anfang dieses Jahres einen Artikel geschrieben haben.

Die Sicherheitsprobleme in Apache Commons Text erklärt

In der Apache-Commons-Text-Bibliothek können Sie Variablen interpolieren. Dadurch lassen sich Eigenschaften laden, deren Werte dynamisch ausgewertet werden können.

Das Problem liegt in StringLookup, das die Suchvorgänge ausführt. Bei diesen Suchvorgängen handelt es sich um Ausdrücke, die DNS-Einträge auflösen, Werte von URLs laden und Skripte mithilfe einer JVM-Skriptausführungs-Engine ausführen können. URLs und Skripte können aus Remote-Quellen stammen und die Remote-Codeausführung auslösen, wenn nicht vertrauenswürdige Werte verwendet werden. Die Schwachstelle wird in CVE-2022-42889 als schwerwiegend eingestuft und betrifft die Versionen 1.5.x bis einschließlich 1.9.x.

Beispiele für CVE-2022-42889

Im Folgenden sehen Sie zwei Beispiele für solche Skripte, die entweder die Nashorn- oder die JavaScript-Engine verwenden. Ob Sie interpolatorStringLookup direkt oder über StringSubstitutor verwenden (was wahrscheinlich häufiger vorkommt), führt zum selben Ergebnis.

Beachten Sie, dass die Nashorn-Skript-Engine in Java 15 und späteren Versionen standardmäßig nicht mehr verfügbar ist. Diese Skripte werden daher nur ausgeführt, wenn Sie selbst eine Skript-Engine bereitstellen. Da viele Unternehmen jedoch weiterhin auf älteren Versionen wie Java 8 basieren, kann dies ein ernstes Problem darstellen. Wenn Sie die aktuelle LTS-Version Java 17 verwenden, werden weder das JavaScript- noch das Nashorn-Skript ausgeführt, da standardmäßig keine Engine verfügbar ist.

Behebung von CVE-2022-42889

Ich möchte noch einmal betonen: Das ist kein erneutes Log4Shell. Wahrscheinlich verwenden Sie StringLookup nicht selbst, aber Sie wissen nicht, ob eine Ihrer transitiven Bibliotheken darauf zurückgreift. Am einfachsten beheben Sie das Problem, indem Sie auf commons-text Version 1.10 (oder höher) aktualisieren. Dadurch werden die Präfixe URL, DNS und script standardmäßig deaktiviert – und eine Ausführung beliebigen Codes über diesen Weg unmöglich gemacht.

Mit einem Snyk-Scan können Sie feststellen, ob diese Schwachstelle in Ihrem Stack vorhanden ist. Wird sie gefunden, aktualisieren Sie auf Version 1.10 und führen Sie snyk monitor in der CLI aus, um Ihre Produktionsumgebung weiterhin zu überwachen.