Einen passenden Titel für diesen Beitrag zu finden war eine unerwartete Herausforderung, weil es mehrere interessante Aspekte gibt, die bei der Betrachtung von CVE-2022-42889 in's Auge stechen.

Das Wichtigste jedoch vorweg, hinter der CVE-Nummer versteckt sich folgende Sicherheitslücke:

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.

Falls die Details dieser Schwachstelle jemandem bekannt vorkommen sollten: Zurecht, eine starke Ähnlichkeit zu CVE-2022-33980 besteht (was auch in den sozialen Medien nicht unbemerkt geblieben ist).

Apache Commons Configuration 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.configuration2.interpol.Lookup that performs the interpolation.

Somit reiht sich diese Sicherheitslücke nahtlos ein in die Serie an Verwundbarkeiten in verschiedensten Java-Applikationen und Frameworks, die mit dem letztjährigen "Vergnügen" (im Nachhinein betrachtet bin ich sehr froh, dass ich erst mit Jänner meinen Weg - zurück - zum CERT gefunden habe) rund um die Probleme mit Log4j begonnen hat.

Die erste wirklich öffentliche Erwähnung fand CVE-2022-42889 letzte Woche auf der Mailingliste des Apache Projektes, bevor die Schwachstelle dann diesen Montag auf Twitter und Konsorten rasch massiv an Aufmerksamkeit gewonnen hat, auch weil ein PoC bereits öffentlich verfügbar war und ist.

Initial war das Bekanntwerden der Sicherheitslücke durchaus besorgniserregend, "Remote Code Execution durch willkürlichen Input in einer verbreiteten Java-Bibliothek" ist gerne ein Rezept für schlaflose Nächte. Vergleiche zu Log4Shell wurden rasch gezogen, und vor allem initial gerne unreflektiert akzeptiert und verbreitet.

Glücklicherweise hat die Community inzwischen leider (.. eine wunderbare Verkettung von Worten) durchaus etwas Erfahrung mit dieser Art von Schwachstellen, weswegen schnell Stimmen laut wurden, welche die Vergleiche in Frage gestellt haben.

Ein Blogpost des Unternehmens Rapid7, den Entwicklern von Metasploit, fasst die Situation relativ gut zusammen. Kurz gesagt ist es, im Gegensatz zu Log4j, vergleichsweise unwahrscheinlich, dass Projekte die verwundbare Komponente nutzen um ungefilterte, potentiell bösartige Daten zu verarbeiten. Die Autoren dieses Posts ziehen Vergleiche zu CVE-2022-22965, einer weiteren ähnlichen Schwachstelle in einem Java-Framework aus diesem Jahr: Die Ausnutzung ist nicht so trivial, wie sie auf den ersten Blick erscheinen mag, in der Praxis gibt es hier einiges an Einschränkungen.

Ein weiterer bitterer, aber dennoch relevanter Einwand aus der Community war, dass die Sicherheitslücke erst 2018 im Code entstanden sei, und die meisten Projekte wohl sowieso nicht auf so eine aktuelle Version setzen würden.

Meine auf Webserver-Logs basierende Telemetrie ist geographisch auf Europa und die USA limitiert, und es ist nicht immer leicht herauszufiltern, welche Schwachstelle mit seltsam anmutenden HTTP-Requests nun ausgenutzt werden soll. Aber es wirkt auf mich auch nicht so, als hätte die Veröffentlichung der Informationen zu dieser Lücke nicht zu einem merklichen Anstieg an Scans oder automatisierten Angriffsversuchen geführt. Anscheinend wird die Welt noch nicht untergehen. Zumindest nicht aufgrund von CVE-2022-42889.

Schlussendlich gibt es in meinen Augen zwei "lessons identified":

• Auch wenn eine gewisse Effekthascherei wohl ihren Platz haben kann, wir täten alle gut daran, reisserische Berichte über neue Sicherheitslücken mit potentiell gravierenden Auswirkungen kritisch zu betrachten.
• Auch wenn die praktischen Auswirkungen diesmal nicht ganz so katastrophal waren, der Strom an Schwachstellen, welche "Log4" ähneln, reisst nicht ab. Das ist ein Indiz dafür, dass wir hier ein grundlegendes, strukturelles Problem haben. Ich kann nicht sagen, was genau das Problem ist. Es könnten Designprobleme sein, es könnten Qualitätsprobleme im Code sein, es könnte  mangelnde Qualitätssicherung sein - oder etwas gänzlich Anderes. Aber die Tatsache, dass wir uns bei kritischen Komponenten moderner Computernetzwerke oftmals auf motivierte Einzelpersonen verlassen um Sicherheitslücken zu finden (anstatt, beispielsweise, konzertierter Maßnahmen durch Projekte oder Hersteller selbst), kann langfristig nichts Gutes verheissen.

Beschäftigen wird uns diese Schwachstelle, auch wenn es nicht zu massenhafter Ausnutzung kommen sollte, wohl dennoch noch eine Weile. Laut den Kollegen vom DFN-CERT ist Apache Commons Text eine Abhängigkeit für über 20.000 Repositories auf Github, was für meine Kollegen in der Medienbeobachtung wohl eine Vielzahl von Advisories mit sich bringen dürfte.

Oh, und natürlich gilt das obligatorische Mantra von CERT.at auch im Fall dieser Sicherheitslücke:

Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen.

Schlaflose Patchnächte sind aber nicht notwendig. Nachdem sich das Jahresende nähert hoffe ich doch, dass es Budgetfragen sind, die dem geneigten Leser den Schlaf rauben - so wie sich das für diese Jahreszeit gehört.