Ein erstaunlicher Vorfall der vergangenen Tage macht die Risiken der weitverbreiteten Abhängigkeit von Open-Source-Software deutlich – und zeigt zugleich, von welcher kostenlosen Arbeit Unternehmen durch den Einsatz von Open-Source-Software profitieren.
Marak Squires, Open-Source-Entwickler und Maintainer, sabotierte sein Repository, um gegen unbezahlte Arbeit und seine gescheiterten Versuche zu protestieren, faker.js und color.js, zwei bedeutende NPM-Pakete, die von einer großen Zahl anderer Pakete und Projekte verwendet werden.
Die Softwarebranche stützt sich auf verschiedene voneinander abhängige Ökosysteme und Ressourcen. Dieser Vorfall zeigt ein bekanntes und ungelöstes Problem der Software-Lieferkette: die „Dependency Hell“. Das gilt besonders für die Welt von Nodes.js und JavaScript, ist aber auch bei Open-Source-Software im Allgemeinen ein häufiges Problem.
Bei einem Angriff auf die Lieferkette versuchen Hacker, legitime Anwendungen zu infizieren, um Malware zu verbreiten. Im Fall von faker.js und color.js haben wir es mit einer ziemlich seltenen Variante zu tun, die den höchstprivilegierten Zugriff nutzt.
Siehe auch: Open-Source-Sicherheit: Ein großes Problem
Beliebte NPM-Pakete vom Autor beschädigt
NPM ist der Paketmanager für Node.js. Es ist das weltweit größte Software-Register mit Hunderttausenden Paketen.
Die Nutzung ist kostenlos, und man muss sich nicht einmal registrieren oder anmelden, um Unmengen von Skripten und Bibliotheken von Drittanbietern herunterzuladen.
Colors ist ein ziemlich beliebtes Paket mit Millionen von Downloads und wird von JavaScript- und Node.js-Entwicklern genutzt, um benutzerdefinierte Farben und Stile in ihrer Konsole zu erhalten. Laut GitHub verwendeten es 4,3 Millionen Projekte, darunter viele andere beliebte Pakete.
Daher werden neue Versionen von unzähligen Installationen heruntergeladen, sobald sie verfügbar sind, wodurch das Paket für die Lieferkette geradezu unverzichtbar wird.
Nur wenige Tage zuvor hatte Squires ein weiteres bekanntes Repository namens faker.js, das von 168.000 Projekten genutzt wird, mit einer eindeutigen Commit-Nachricht „beendet“: endgame.
Die Hauptdateien sind verschwunden; nur einige Konfigurationen sind übrig geblieben.
Squires veröffentlichte Folgendes in seinem GitHub-Repository:
„Wir sind darauf aufmerksam geworden, dass die Version v1.4.44-liberty-2 von colors einen Zalgo-Fehler enthält.“
Der Name des in den Kern integrierten Branches war merkwürdig, und der zugehörige Commit mit dem Namen „fix bug“ enthielt schädliche Anweisungen, um eine Endlosschleife auszulösen:
for (let i = 666; i < Infinity; i++) {
if (i % 333) {
// console.log('testing'.zalgo.rainbow)
} console.log('testing testing testing testing testing testing testing'.zalgo)
}Der oben stehende Code befindet sich in der Datei index.js, die automatisch ausgeführt wird, wenn die Bibliothek verwendet wird. Zalgo-Text bezeichnet spezielle Nicht-ASCII-Zeichen, die nicht wie erwartet dargestellt werden und Fehler in der Benutzeroberfläche auslösen.
Bei der Ausführung endet der Code nie. Es handelt sich um ein Logikproblem, das als „Endlosschleife“ bekannt ist. Alles – von der zur Initialisierung der Schleife verwendeten Ganzzahl (666) bis zum vom Autor festgelegten Grenzwert (Infinity) – deutet darauf hin, dass dies beabsichtigt war.
Auf den ersten Blick wirkt es wie ein Scherz für jeden, der schon einmal mit JavaScript gespielt hat. Für Projekte, die auf diese bekannte Bibliothek setzen, hatte es jedoch Folgen: Zahlreiche CI/CD-Pipelines und Terminal-Eingabeaufforderungen wurden beeinträchtigt:
Squires ist nicht der einzige Maintainer des Repositorys, aber er entzog den anderen Maintainer den Zugriff, um sicherzustellen, dass niemand seine Aktion rückgängig machen konnte. Eine anschließend von ihm auf Twitter veröffentlichte Nachricht löste eine heftige Debatte über das Open-Source-Modell aus. Einige zeigten Verständnis, während andere sagten, die Open-Source-Vereinbarung sei schon immer eindeutig gewesen.
Nutzer könnten möglicherweise auf frühere Softwareversionen zurückwechseln, was im Fall von colors einfacher zu sein scheint. Die faker.js-Seite scheint vollständig gelöscht worden zu sein, doch es gibt immer archive.org als mögliche Lösung. Eine solche Lösung sollte allerdings nur vorübergehend sein, da diesen Repositorys nicht mehr vertraut werden kann. Es gibt alternative Pakete, und im Fall von faker ist bereits eine Alternative aufgetaucht.
Github hat im Fall von colors eine Sicherheitsempfehlung veröffentlicht.
Siehe auch: Die besten Tools für Code-Debugging und Codesicherheit
Der Stand der Open-Source-Welt
In seinem Blog erklärte der Entwickler, dass kein Unternehmen faker.js und color.js finanziell unterstützt habe. Er habe lediglich einige wenige Spenden über GitHub Sponsorships erhalten, und bei den Spendern habe es sich um andere Entwickler gehandelt.
Er versuchte, seinen Code zu monetarisieren, indem er einen Cloud-Dienst mit monatlichen Abonnements startete, erreichte jedoch nicht genügend Nutzer. Seiner Aussage nach übernahm einer seiner GitHub-Sponsoren, der offenbar auch als Abonnent registriert war, seine Idee und startete dasselbe Angebot.
Eine Sackgasse bei Open Source ist nicht völlig ungewöhnlich und kann in Extremsituationen zu heftigen Reaktionen führen – wie im schlimmsten Fall zu dem Vorgehen von Squires mit seinen Repositorys.
Dies könnte weitere Open-Source-Maintainer inspirieren und sogar zu einem Trend werden, wenn niemand nachhaltige Wirtschaftsmodelle findet – insbesondere weil viele private und gewinnorientierte Organisationen öffentliche Ressourcen nutzen oder forken.
Auch wenn GitHub und NPM schnell reagiert, die Pakete entfernt und das Konto des Autors vorübergehend gesperrt haben, ist der Schaden bereits entstanden.
Entwickler sollten sich mit einem besseren Abhängigkeitsmanagement auf solche Vorfälle vorbereiten.
So lassen sich Vorfälle mit Abhängigkeiten eindämmen
Auch wenn sich solche radikalen Aktionen nicht vorhersehen lassen, können Sie Ihre Vorbereitung möglicherweise verbessern. Es gibt Best Practices für die Open-Source-Sicherheit, die Sie zur Eindämmung solcher Vorfälle anwenden können, darunter:
- Tests durchzuführen, bevor etwas in einer Remote-Umgebung bereitgestellt wird
- Feste Versionen festlegen: Verwenden Sie in der package.json-Datei, in der die Pakete aufgeführt sind, keine Symbole wie “^” oder “~” für Abhängigkeiten, da dies großzügiger ist und bei der Ausführung von npm update automatische kleinere (oder größere) Aktualisierungen zulässt
- Besonders wachsam sein bei falsch geschriebenen Paketen, um Typosquatting-Angriffe zu verhindern
Weiterführende Lektüre: Die besten Tools für das Schwachstellenmanagement