Open-Source-Maintainer zieht bei den npm-Paketen colors und faker den Stecker – was nun?

Am 8. Januar 2022 veröffentlichte der Open-Source-Maintainer des äußerst beliebten npm-Pakets colors die Versionen colors@1.4.1 und colors@1.4.44-liberty-2, in die absichtlich ein problematischer Commit mit einer Endlosschleife im Quellcode eingebaut wurde. Die Endlosschleife wird unmittelbar bei der Initialisierung des Paketquellcodes ausgelöst und ausgeführt. Sie würde bei jedem Node.js-Server, der das Paket verwendet, zu einem Denial of Service (DoS) führen.

Kurzfassung: Snyk hat eine Denial-of-Service-Sicherheitslücke für colors@1.4.1 gemeldet, die auf diesen anfälligen Code zurückgeht. Wir empfehlen dringend, auf colors@1.4.0 zurückzugehen und die Versionen Ihrer Abhängigkeiten festzuschreiben, um unbemerkte Upgrades auf die problematische Version zu vermeiden. Außerdem empfehlen wir Ihnen, zu einem anderen Paket zu wechseln. Lesen Sie weiter, um mehr über Umfang, Auswirkungen und empfohlene Gegenmaßnahmen zu erfahren.

Über colors

Das Open-Source-npm-Paket colors wird über 20 Millionen Mal pro Woche heruntergeladen. Es ist ein wichtiges Projekt im JavaScript- und Node.js-Ökosystem und bildet die Grundlage für zahlreiche Projekte. GitHub-Daten zufolge wird das Projekt colors in mehr als 4 Millionen anderen Projekten verwendet. Laut npmjs.org ist dieses npm-Paket außerdem eine Abhängigkeit von 18.962 anderen Paketen.

Hier sind einige Projekte, die von colors abhängen:

• Das prompt-Befehlszeilen-Hilfsprogramm (ca. 500.000 Downloads pro Woche)

• Unicode-Tabellenformatierung mit cli-table3 (ca. 7 Millionen Downloads pro Woche)

• AWS-eigenes aws-cdk (ca. 2 Millionen Downloads pro Woche)

Die fehlerhafte Version colors@1.4.1 betrifft tatsächlich sehr viele Nutzerinnen und Nutzer und sollte nicht auf die leichte Schulter genommen werden. Den Statistiken auf der npmjs-Paketseite zufolge wurde diese Version zum Zeitpunkt der Veröffentlichung dieses Blogbeitrags bereits 95.397 Mal heruntergeladen:

Der fehlerhafte Code

Der folgende problematische Code wurde in die anfällige Bibliothek colors aufgenommen:

1for (let i = 666; i < Infinity; i++;) {
2   if (i % 333) {
3       // console.log('testing'.zalgo.rainbow)
4   }
5   console.log('testing testing testing testing testing testing testing'.zalgo)
6}

Dieser Code für eine Endlosschleife befindet sich in der Datei index.js des Paketquellcodes. Er unterbricht jede Nutzung des Pakets und gibt dabei verstörenden Zalgo-Text im Terminal aus:

Ich bin auf das Paket colors angewiesen. Was sollte ich tun, um die Auswirkungen zu begrenzen?

Wenn Sie derzeit vom colors-Vorfall betroffen sind, weil Sie die fehlerhafte Version 1.4.1 verwenden, empfehlen wir Ihnen, zur letzten bekannten sicheren Version colors@1.4.0 zurückzukehren, die den problematischen Code mit der Endlosschleife nicht enthält. Um beispielsweise die stabile und sichere Version des Pakets colors in Ihrer Datei package.json festzuschreiben, ersetzen Sie Folgendes:

1"colors":"^1.4.0"

durch:

1"colors":"1.4.0"

Für die Zukunft empfehlen wir Ihnen die folgenden Best Practices für die Verwaltung von Open-Source-Bibliotheken in Ihren Projekten:

1. Schreiben Sie Ihre Abhängigkeiten entweder in Ihrer Datei package.json oder mithilfe einer Lockdatei fest. So vermeiden Sie, dass bei der Installation neuere Versionen aufgelöst werden, und verhindern, dass Sie die gepatchte Version 1.4.1 von colors installieren, die das Problem eingeführt hat.

2. Dieser Vorfall sollte Sie dazu veranlassen, einen Wechsel zu einem alternativen Paket für die Farbverarbeitung in Betracht zu ziehen, etwa zu chalk.

3. Prüfen Sie die Wartung und Nachhaltigkeit der Open-Source-Pakete, die Sie verwenden möchten, und stellen Sie sicher, dass sie über ein angemessenes Governance-Modell verfügen, beispielsweise mit mehreren Mitwirkenden.

Faker.js: Derselbe Maintainer, dieselbe Geschichte?

Dieser Vorfall folgt auf einen ähnlichen Vorfall mit dem beliebten npm-Paket faker (allgemein bekannt als Faker.js), das von derselben Person gepflegt wird. Viele Entwickler nutzen Faker, um große Mengen fiktiver Daten zu generieren, wie sie häufig beim Testen von Software zum Einsatz kommen.

Faker wird 2 Millionen Mal pro Woche heruntergeladen und ist ebenfalls eine beliebte Abhängigkeit in JavaScript- und Node.js-Projekten. Am 5. Januar 2022 wurde jedoch im Open-Source-Repository dieses Pakets auf GitHub ein erzwungener Commit vorgenommen, der den ursprünglichen Quellcode des Pakets vollständig rückgängig machte:

Die Version des npm-Pakets faker wurde entsprechend auf 6.6.6 angehoben und als leeres Paket ohne Quellcode im öffentlichen npmjs-Register veröffentlicht.

Der Maintainer erstellte ein Issue und erklärte, dass er das Paket nicht länger kostenlos warten werde:

Später entfernte der Autor das GitHub-Repository, aus dem das Projekt bezogen wurde. Das führte wahrscheinlich zu erheblichen Beeinträchtigungen für Tausende von Entwicklern, die das Paket verwenden und nun möglicherweise nach Möglichkeiten für eine Migration suchen.

Später veröffentlichte der Autor einen Artikel zu diesem Thema in seinem persönlichen Blog. Darin schilderte er die gescheiterten Versuche, das Projekt zu monetarisieren oder Sponsoren zu finden, und erklärte, dass die aktuelle Spendensituation nicht nachhaltig sei: „Wie die meisten von uns habe ich Menschen, die auf mich angewiesen sind, und Rechnungen, die ich bezahlen muss“.

Da derselbe Maintainer an rund 170 weiteren npm-Paketen beteiligt ist, könnte diese Geschichte durchaus weitergehen.

Risiken durch Governance- und Finanzierungsmodelle für Open Source

Dieser Vorfall fügt sich in einen allgemeinen Trend in der Open-Source-Community ein: Es geht um die Verantwortung von Unternehmen und Organisationen, die in der Produktion auf Open-Source-Code angewiesen sind, um ihre Produkte zu entwickeln.

Nach der Veröffentlichung des problematischen Codes in colors eröffnete der Maintainer selbst ein GitHub-Issue zu dem Vorfall. Darin machte er sich im Allgemeinen darüber lustig, dass er die Ursache dieses „Bugs“ nicht finden könne und keine Zeit habe, sich darum zu kümmern.

Marak bat anschließend weitere äußerst aktive Node.js-Entwickler um Hilfe, indem er sie markierte. Keiner von ihnen hatte jedoch tatsächlichen Zugriff auf das Projekt-Repository:

Diese Vorfälle entsprechen einem aktuellen Diskussionstrend in der Open-Source-Community: Immer mehr Maintainer äußern ihre Unzufriedenheit darüber, dass Unternehmen und Organisationen Open-Source-Software monetarisieren und in ihren Produkten einsetzen.

Als Reaktion auf die Kritik an Open Source nach Log4Shell haben wir kürzlich die Schwierigkeiten von Maintainerinnen und Maintainern beleuchtet, ohne Finanzierung nachhaltige Open-Source-Software zu pflegen.

Möglicherweise zeichnet sich ein anhaltender Trend ab, bei dem Maintainer den Zugriff auf ihre Pakete vollständig sperren. Die Beweggründe sind durchaus verständlich und die Argumente berechtigt. Dennoch sollte man bedenken, dass eine solche Sperrung des Zugriffs auf Open-Source-Pakete auch anderen Open-Source-Entwicklern und -Maintainerinnen schadet.

Best Practices für Open-Source-Sicherheit umsetzen

Wer Open-Source-Software verwendet, muss die Risiken solcher Vorfälle sowie weitere Sicherheits- und Rechtsfragen angemessen bewerten und gut darauf vorbereitet sein, mit ihnen umzugehen. Noch besser ist es, Best Practices einzuführen, um potenzielle Sicherheitsprobleme in der Supply Chain zu vermeiden und ihre Auswirkungen zu begrenzen.

Wir empfehlen Ihnen die folgenden Maßnahmen und weiterführenden Inhalte, damit Sie für künftige Situationen wie diese besser aufgestellt sind:

1. Sie sollten den Wartungs- und Nachhaltigkeitsstatus von Open-Source-Projekten prüfen. Der Snyk Advisor ist ein solches Tool, mit dem Sie den Zustand eines Pakets einschätzen können.

2. 10 npm-Sicherheits-Best-Practices erläutert, wie wichtig die Aktivierung der Zwei-Faktor-Authentifizierung, das Festschreiben von Abhängigkeiten mit geeigneten Lockdateien und weitere Maßnahmen sind.

3. Informieren Sie sich darüber, wie Sie Ihre moderne Software-Supply-Chain absichern – etwa gegen Dependency Confusion, Typosquatting und schädliche Pakete.

4. Praktische Tipps dazu, wie Snyk Ihnen hilft, schädliche Pakete und Supply-Chain-Angriffe zu verhindern