Der Sicherheitsforscher Alvaro Muñoz warnte kürzlich vor einer kritischen Schwachstelle in den Versionen 1.5 bis 1.9 von Apache Commons Text. Der als „Text4Shell“ bezeichnete und als CVE-2022-42889 identifizierte Fehler kann die Remote-Code-Ausführung über die StringSubstitutor-API ermöglichen. Als Reaktion wurde Version 1.10 veröffentlicht, die die Skriptinterpolation standardmäßig deaktiviert.
Während die Schwachstelle einen sehr hohen Schweregrad von 9,8 aufweist und ihr Name eine Ähnlichkeit mit der gefürchteten Log4Shell-Schwachstelle nahelegt, hielt der Rapid7-Forscher Erick Galinkin den Vergleich für unfair. „Aufgrund der Art der Schwachstelle ist es im Gegensatz zu Log4Shell selten, dass eine Anwendung die anfällige Komponente von Commons Text zur Verarbeitung nicht vertrauenswürdiger, potenziell schädlicher Eingaben verwendet“, schrieb er.
Das auf WordPress-Sicherheit spezialisierte Unternehmen Wordfence hat böswillige Akteure entdeckt, die nach anfälligen Installationen suchten, stimmte aber zu, dass Text4Shell ein deutlich geringeres Risiko als Log4j darstellt: „Die Apache-Commons-Text-Bibliothek wird weitaus seltener auf unsichere Weise eingesetzt, und die Wahrscheinlichkeit einer erfolgreichen Ausnutzung ist deutlich geringer.“
Auf Text4Shell reagieren
Varun Badhwar, CEO und Mitgründer von Endor Labs, erklärte, die Schwachstelle sei besorgniserregend, aber nicht überraschend. „Es ist natürlich und zu erwarten, dass Entwicklern bei der Entwicklung von Code Fehler unterlaufen – insbesondere Open-Source-Maintainern und -Mitwirkenden, für die dies keine Vollzeitbeschäftigung ist“, sagte er.
Das größte Problem, das Text4Shell für die meisten Unternehmen verursachen werde, sei laut Badhwar der Zeitaufwand für die Untersuchung und Behebung des Problems. „In erster Linie fehlt den meisten Organisationen das nötige Werkzeug, um schnell herauszufinden, wo diese Abhängigkeit eingesetzt wird“, sagte er.
Zumindest in dieser Hinsicht sei der Vergleich mit Log4Shell laut Badhwar angemessen – der jüngste Bericht [PDF] des U.S. Cyber Safety Review Board zu Log4Shell stellte fest, dass ein Ministerium der US-Regierung auf Kabinettsebene 33.000 Stunden für die Untersuchung und Reaktion auf den Fehler aufgewendet hatte.
„Während wir von den Maintainerinnen und Maintainer das Beste hoffen, müssen Endnutzer von Open-Source-Software in Lösungen für das Management des Abhängigkeitslebenszyklus investieren. Diese können ihnen dabei helfen, geeignete Abhängigkeiten auszuwählen, sie effizient abzusichern und darauf vorbereitet zu sein, solche Vorfälle mit einem hohen Automatisierungsgrad schnell zu untersuchen und darauf zu reagieren“, fügte Badhwar hinzu.
Siehe die wichtigsten Tools für Code-Debugging und Codesicherheit
Abhängigkeiten von Abhängigkeiten
Der Sicherheitsforscher von Endor Labs, Henrik Plate, teilte eSecurity Planet mit, dass die geringe Bekanntheit der betroffenen Abhängigkeit die zentrale Herausforderung darstellt. „Das allgemeine Problem bei Schwachstellen in Open-Source-Komponenten besteht darin, dass die Mehrheit keine Komponenten (Abhängigkeiten) betrifft, die Softwareentwickler direkt verwenden“, sagte er. „Stattdessen betreffen diese Schwachstellen Abhängigkeiten von Abhängigkeiten, die sie verwenden. Dadurch ist es für Entwickler äußerst schwierig einzuschätzen, ob eine bestimmte Schwachstelle für die von ihnen entwickelte Software tatsächlich relevant ist.“
Im Fall von Log4Shell sei laut Plate die Popularität von Log4j entscheidend für die Bedrohung, da man es „buchstäblich überall finden kann“.
Erschwerend kommt hinzu, dass der Fehler Systeme beeinträchtigen kann, die nicht direkt dem Internet ausgesetzt sind. „Eine schädliche Zeichenkette oder ein schädlicher Text, die bzw. der die Schwachstelle auslöst, könnte von einem Angreifer an ein System übermittelt werden und anschließend verschiedene Datenbanken und Systeme durchlaufen, bis ein anfälliges System tief im Netzwerk einer Organisation ausgenutzt wird“, sagte er.
„Log4j macht deutlich, dass der Aufwand für die Reaktion auf eine weitverbreitete Schwachstelle oft gefährlicher ist als die Schwachstelle selbst“, fügte Plate hinzu.
Lesen Sie auch: Software-Lieferkette: Eine riskante Zeit für Abhängigkeiten
Die Angriffsfläche verwalten
Badhwar merkte in einem kürzlich veröffentlichten Blogbeitrag an, dass ein durchschnittliches Unternehmen mehr als 40.000 Open-Source-Abhängigkeiten hat, die direkt von Entwicklern heruntergeladen werden – und jede dieser Abhängigkeiten durchschnittlich 77 weitere Abhängigkeiten mitbringt. „Dies führt zu einer massiven und unkontrollierbaren Ausuferung, die die Entwicklung verlangsamt und gleichzeitig die Angriffsfläche vergrößert“, schrieb er.
Darüber hinaus haben Sicherheitsteams oft nur sehr wenig Einblick darin, wo und wie dieser Code verwendet wird. Wenn eine Schwachstelle bekannt gegeben wird, kann es daher der Suche nach der Nadel im Heuhaufen gleichen, festzustellen, ob man betroffen ist oder nicht.
Plate sagte, die Vorgehensweise seines Unternehmens bei der Reaktion auf solche Probleme sei relativ einzigartig. „Das Unterscheidungsmerkmal von Endor Labs besteht darin, mittels statischer Codeanalyse zu prüfen, ob der in einer Open-Source-Komponente enthaltene anfällige Code im Kontext einer bestimmten Software ausgelöst werden kann – unabhängig davon, wie tief die anfällige Komponente im Abhängigkeitsstapel verborgen ist“, sagte er.
„Diese Kontextinformationen sind entscheidend, um den Dutzenden von Schwachstellen, die wöchentlich bekannt gegeben werden und zu Hunderten oder Tausenden von Warnmeldungen führen, Priorität einzuräumen. Viele davon sollten den Entwicklern gar nicht erst zur Kenntnis gebracht werden“, fügte Plate hinzu.
Weiterführende Lektüre: