Karfreitag war für die weltweite IT-Community dieses Jahr besonders spannend. Details zu CVE-2024-3094 (XZ Utils) ließen die Security-Fachleute aufhorchen: Eine absichtlich installierte Schwachstelle in einer bedeutenden, weil weit verbreitenden, Open Source Komponente wurde per Zufall entdeckt und hätte zu katastrophalen Auswirkungen führen können. Die Bedrohungslage ist nicht so enorm, wie bei log4j, welche heute noch in begrenztem Maße eine Rolle spielt. Wie es zur Schwachstelle in XZ Utils gekommen ist, ist jedoch viel spannender und beginnt schon 2021.
Doch schauen wir zuerst auf Ähnlichkeiten und Unterschiede.
Ähnlichkeiten
Weite Verbreitung
Sowohl XZ Utils als auch log4j sind weit verbreitete Softwarekomponenten. XZ Utils wird in vielen Linux-Distributionen verwendet, während log4j bis heute eine beliebte Logging-Bibliothek für Java-Anwendungen ist. Ihre weite Verbreitung bedeutet, dass eine Schwachstelle oder Backdoor potenziell Millionen von Geräten oder Anwendungen betreffen kann. Weil die Schwachstellen in XZ Utils nach aktuellem Kenntnisstand jedoch „nur“ in den unstable Versionen veröffentlicht wurden, ist die Verbreitung vermutlich bedeutend geringer als bei log4j.
Remote Code Execution (RCE)
Beide Sicherheitslücken ermöglichen unter bestimmten Umständen die Ausführung von Remote-Code. Bei log4j erlaubte die Schwachstelle Angreifern, beliebigen Code auf Servern auszuführen, die die anfällige Version der Bibliothek verwendeten, indem sie speziell gestaltete Eingaben an eine Anwendung sendeten. Die Backdoor in XZ Utils ermöglichte ebenfalls Remote-Code-Ausführung, allerdings durch eine spezifisch gestaltete Backdoor, die aktiviert werden konnte, wenn bestimmte Bedingungen erfüllt waren.
Schwierigkeit der Entdeckung und Behebung
Sowohl die log4j-Schwachstellen als auch die Backdoor in XZ Utils waren zunächst schwer zu entdecken und zu beheben. Bei log4j lag dies vorrangig an der Komplexität und Verbreitung der Bibliothek in zahlreichen Java-Anwendungen, nicht immer war dies hinreichend dokumentiert. Im Falle von XZ Utils war die Backdoor absichtlich verborgen und in einer Weise implementiert, die ihre Entdeckung erschwerte. Log4j ließ sich größtenteils auch von extern erkennen, anders als bei den XZ Utils, hier sind die installierten Pakete entscheidend, die sich tendenziell nur innerhalb des Systems erkennen lassen aber von außen ausgenutzt werden können.
Bedeutung von Software-Supply-Chain-Sicherheit
Beide Vorfälle unterstreichen die Bedeutung der Sicherheit in der Software-Lieferkette. Sie zeigen, wie Angreifer Schwachstellen in weit verbreiteten Bibliotheken ausnutzen können, oder wie in diesem Fall sogar einfügen konnten.
Hoher Schweregrad
Beide Sicherheitsprobleme wurden als äußerst kritisch eingestuft. Die log4j-Schwachstellen erhielten ebenfalls die höchstmögliche CVSS-Bewertung von 10.0, was auf das hohe Risiko hinweist, welches sie für betroffene Systeme darstellen.
Unterschiede
Art der Schwachstelle
Die Probleme bei log4j waren auf spezifische Schwachstellen in der Art und Weise zurückzuführen, wie die Bibliothek Eingabestrings verarbeitet und interpretiert, insbesondere im Zusammenhang mit JNDI (Java Naming and Directory Interface). Im Gegensatz dazu ist die Sicherheitslücke in den XZ Utils ein absichtlich eingeführtes Backdoor, was auf eine böswillige Absicht hindeutet, der durch gut ausgebildete Experten implementiert wurde.
Entdeckung und Ausnutzung
Während die log4j-Schwachstellen relativ schnell nach ihrer Entdeckung weit verbreitet ausgenutzt wurden, was zu einer schnellen und breiten Reaktion der Gemeinschaft führte, gibt es zu dem Backdoor in den XZ Utils zum aktuellen Zeitpunkt keine belastbaren Erkenntnisse was eine Ausnutzung angeht.
Reaktion und Behebung
Beide Fälle erfordern schnelle Reaktionen, um die Sicherheitslücken zu schließen. Bei log4j führte dies zu mehreren aufeinanderfolgenden Veröffentlichungen von Patches, da zunächst nicht alle Aspekte der Schwachstelle vollständig adressiert wurden. Bei XZ Utils setzt man momentan eher auf ein Rollback zu früheren, nicht kompromittierten Versionen und das Deaktivieren von Repository-Spiegelungen.
Fazit
Der Krimi um XZ Utils zeigt erneut: Der Einsatz fremder Software, gleichgültig ob Closed oder Open Source, birgt Risiken. Diese Risiken haben unterschiedliche Ursachen, die Auswirkungen für Unternehmen (oder auch Verbraucher, Privatpersonen) sind ähnlich und können kritisch werden. Für alle Anwendungsfälle eigene Software zu entwickeln ist schlicht und ergreifend unmöglich.
Dieses Dilemma lässt sich nur schwer beheben, geeignete Lösungsansätze sind mehrschichtig und mehrstufig, angefangen von der Transparenz bis hin zu einem wirksamen Patch- und Schwachstellenmanagement. Formalien wie SBOM (Software Bill of Material) würden in Sachen Transparenz unterstützen, sofern die Qualität und Detailtiefe ausreichend wären.
Es zeigt auch, dass die Open Source Community durchaus angreifbar ist, unter anderem weil sie naturgemäß angreifbare Schwachpunkte besitzt: Hier kann förmlich jeder beitragen, auch mit böswilliger Absicht. Das Vertrauen durch eine Form von Schwarmintelligenz, die sich gegenseitig prüft, unterstützt, kritisiert und optimiert hat Grenzen. Heartbleed und Poodle litten ebenfalls unter dem blinden Vertrauen, den Open Source im Allgemeinen genießt. Oft lasten Open Source Projekte auf den Schultern von nur wenigen Personen, teilweise sogar nur Einzelpersonen, die sich ehrenamtlich, unbezahlt Open Source Projekten widmen, die buchstäblich die Welt am Laufen halten.
Darüber hinaus stellt sich die Frage, inwieweit Nachrichtendienste oder diesen nahe stehende Gruppierungen und Individuen bereits in ähnlicher Weise andere Open Source Projekte unterwandert haben könnte. Der bei XZ Util aufgedeckte Modus Operandi lässt sich hinreichend gut skalieren und die nötigen Ressourcen und Fachkenntnisse kann man staatlichen Akteuren zutrauen. Selbstverständlich hat auch Closed Source Angriffspunkte für professionelle Angreifer, jedoch unterliegt hier der SDLC (Software Development Lifecycle) häufiger unterschiedlichen Prozessen. Eine Transparenz, wie sie bei XZ Utils zu finden war (die auch zufällig zum Fund der Schadhaftigkeit führte), fehlt bei Closed Source in den meisten Fällen vollständig.
Die gute Nachricht: Die Diskussionen um Open Source, Closed Source und den damit einhergehenden Problemen ist nicht neu. Es gibt deshalb Möglichkeiten mit solchen und anderen Risiken geeignet umzugehen, auch für Herausforderungen rund um XZ Utils gibt es adäquate Lösungsansätze.
Sprechen Sie uns hierfür gerne unverbindlich an.
Weiterführende Weblinks:
Kritische Backdoor in XZ für Linux (bund.de)
Urgent security alert for Fedora 41 and Fedora Rawhide users (redhat.com)
https://boehs.org/node/everything-i-know-about-the-xz-backdoor