Sicherheitslücken mit Sicherheitspatches einen Schritt voraus sein

Traditionell veröffentlichen Teams im Rahmen des Softwareentwicklungsprozesses in der Regel neue Versionen ihrer Pakete oder Apps, um auftretende Sicherheitsprobleme zu beheben.

Bei Open-Source-Projekten kann es jedoch dauern, bis korrigierte Paketversionen veröffentlicht werden, da Maintainerinnen und Maintainer meist ehrenamtlich arbeiten und durch ihre üblichen Verpflichtungen abgelenkt sein können. Dadurch kann eine erhebliche Lücke zwischen der Entdeckung einer Sicherheitslücke und ihrer Behebung und öffentlichen Bekanntgabe entstehen. Ohne eine offiziell veröffentlichte Version mit einem Fix für die betreffende Softwarekomponente steigt leider das Risiko, dass die Sicherheitslücke ausgenutzt wird.

Um solche Fälle abzufangen, kuratiert Snyk Sicherheitspatches für Open-Source-JavaScript-Projekte im npm-Ökosystem. So helfen wir Maintainerinnen und Maintainer, ihre Pakete sicher zu halten und Sicherheitsrisiken einen Schritt voraus zu sein – auch wenn sie nicht sofort selbst Zeit haben, Sicherheitsprobleme zu beheben. Snyk spielt in Abstimmung mit den Maintainerinnen und Maintainern einen Sicherheitsfix direkt in jedes betroffene npm-Paket ein. So sind Sie geschützt, auch wenn es noch keine offizielle Version gibt, die das Problem behebt – oder eine solche Version Ihren Build beeinträchtigen könnte.

Warum sind Sicherheitspatches wichtig?

Die Zeit bis zur Veröffentlichung eines Sicherheitsfixes durch Open-Source-Maintainerinnen und -Maintainer kann schwerwiegende Folgen haben. Deshalb sind Sicherheitspatches unverzichtbar. Ein Beispiel dafür sind Prototype-Pollution-Sicherheitslücken, die kürzlich in der beliebten JavaScript-Bibliothek lodash entdeckt wurden.

Das Sicherheitsteam von Snyk entdeckte Prototype-Pollution-Sicherheitslücken in lodash (CVE-2019-10744), die alle Versionen betrafen. Nach der Entdeckung arbeiteten wir im Rahmen eines Responsible-Disclosure-Prozesses mit John Dalton, dem Maintainer von lodash, zusammen, um die Erkenntnisse mitzuteilen und Sicherheitsfixes für die Sicherheitslücken bereitzustellen.

Sobald die Fixes als Pull Request zur Behebung der Sicherheitslücke im lodash-Repository öffentlich waren, begann der Countdown bis zur offiziellen lodash-Version mit diesen Fixes.

Die Informationen zur Sicherheitslücke wurden am 2. Juli 2019 veröffentlicht. Die offizielle Version ließ jedoch eine Woche auf sich warten und erschien erst am 9. Juli 2019.

Der von Snyks Mechanismus bereitgestellte Sicherheitspatch ist für alle Nutzerinnen und Nutzer kostenlos. Wir eröffnen proaktiv Pull Requests, um den Patch einzuspielen, die Sicherheitslücke zu beheben und Ihre Projekte zu schützen.

Wie spielt Snyk Sicherheitspatches ein?

Snyks Mechanismus zum Patchen von Modulen nutzt die Unterstützung von npm package.json-Skripten für Lifecycle-Ereignisse. Der npm-Prozess ermöglicht es Behebungsprogrammen, sich während verschiedener Phasen Ihres Builds nahtlos in die npm-Lifecycle-Verwaltung einzufügen – etwa bei der Installation von npm oder beim Veröffentlichen in einer Registry.

Die npm-Dokumentationsseite enthält ausführliche Informationen zu allen verfügbaren npm-Lifecycle-Ereignissen sowie dazu, wie und wann sie ausgeführt werden.

Snyk nutzt das Lifecycle-Ereignis prepublish in package.json, um Patches anzuwenden, bevor das Paket gepackt und veröffentlicht wird. Es wird außerdem ausgeführt, wenn npm install lokal ohne zusätzliche Argumente gestartet wird._._Um besser zu verstehen, wie das funktioniert, können wir lokal einige Pakete erstellen und verdaccio als lokale npm-Registry verwenden, um das Veröffentlichen und Installieren von Modulen auszuprobieren.

Mit npm init -y und einer Aktualisierung unseres Testmoduls aaa, sodass es ein prepublish-Skript enthält, sieht der Code so aus:

1
2{
3  "name": "aaa",
4  "version": "1.1.0",
5  "description": "",
6  "scripts": {
7    "test": "echo \"Error: no test specified\" && exit 1",
8    "prepublish": "echo hello little green world"
9  },
10  "main": "index.js",
11  "keywords": [],
12  "author": "",
13  "license": "ISC"
14}

Wenn wir an der Eingabeaufforderung npm install ausführen, wird Folgendes angezeigt:

Unser npm-Lifecycle-Ereignis wurde ausgeführt. Dabei wird dieser kurze Text in der Konsole ausgegeben und Snyk spielt außerdem die erforderlichen Patches ein.

Snyk aktualisiert Ihre Konfiguration für das pre-publish-Ereignis wie folgt:

1
2"scripts": {
3  "snyk-protect": "snyk protect",
4  "prepublish": "npm run snyk-protect"
5}

Wird npm install ausgeführt, ermittelt Snyk, welche Sicherheitslücken in Ihrem Code vorhanden sind, lädt einen Patch aus unserer Datenbank herunter und behebt damit die Sicherheitslücke. Anschließend wird der Patch auf das anfällige Modul im Ordner node_modules angewendet.

Das bedeutet: Wenn Sie ein Projekt klonen, alle Abhängigkeiten installieren und es ausführen, wird Snyk während der Modulinstallation gestartet, um die Sicherheitslücke zu patchen.

Bei Node.js-Projekten ist die Anwendung bereits geschützt, wenn Sie sie ausführen. Bei einer typischen JavaScript-Bibliothek, die Code transpiliert, etwa mit einem Modul-Bundler wie webpack, babel oder typescript, ist die gepatchte Sicherheitslücke auch im Bundle-Ergebnis enthalten, das häufig unter dist/ zu finden ist.

Wie funktioniert npm prepublish?

Vielleicht verwenden Sie andere Abläufe als ein einfaches npm install für Ihr Projekt und überspringen dabei das prepublish-Ereignis. In solchen Fällen werden Snyk-Patches nicht angewendet.

Um besser zu verstehen, wie das npm-Skript-Ereignis prepublish aufgerufen wird, sehen wir uns den Ablauf an:

• npm install

• npm install --dev

• npm ci

• yarn

• yarn install

• yarn install --frozen-lockfile

Wann wird das npm-Ereignis prepublish nicht aufgerufen?

• npm install --prod

• yarn install --prod

Wie bereits erwähnt, wird prepublish nicht einbezogen, wenn npm install mit zusätzlichen Argumenten ausgeführt wird. Wenn Sie also in Ihrem Workflow zur Installation von npm-Modulabhängigkeiten npm install --prod ausführen, können Sie stattdessen direkt snyk protect von Snyk aufrufen.

Betrachten Sie zum Beispiel die folgende Travis-CI-Konfiguration:

1
2install:
3  - npm install --prod
4  - snyk protect

Snyk-Sicherheitspatches für Bibliotheken

Bei unseren npm-Paketversuchen haben wir diese beiden Bibliotheken verwendet:

• aaa – weist Sicherheitslücken in seinen Abhängigkeiten auf. Die Maintainer haben keine neueren Versionen mit einem offiziellen Fix veröffentlicht. Snyk-Patches beheben diese Sicherheitslücken.

• bbb – verwendet aaa als eigene Abhängigkeit

In unserem Anwendungsfall wird aaa also vom Projekt bbb verwendet. Wenn bbb seine Abhängigkeiten installiert, beispielsweise mit npm install, wird das Lifecycle-Ereignis prepublish für aaa nicht ausgeführt.

Das bedeutet: Wenn aaa nicht als transpiliertes Bundle mit all seinen Abhängigkeiten in der Registry veröffentlicht wurde – was nur bei Frontend-Bibliotheken üblich ist –, enthalten die verschachtelten Bibliotheken von aaa nach der Installation von aaa in bbb weiterhin dieselben bekannten Sicherheitslücken.

In solchen Fällen sollte der Maintainer der übergeordneten Bibliothek bbb die Sicherheitslücken beheben, indem er Patches bereitstellt, die dann auch die verschachtelten Abhängigkeiten von aaa korrigieren.

Zusammenfassung

Zusammenfassend lässt sich sagen: Wenn Maintainerinnen und Maintainer neue Versionen mit Sicherheitsfixes nicht schnell genug veröffentlichen können – oder im schlimmsten Fall nicht mehr an den Projekten mitarbeiten und überhaupt nicht mehr reagieren –, steigt das Risiko, dass Sicherheitslücken über längere Zeit bestehen bleiben. Deshalb sind gezielte Sicherheitspatches ein wichtiges Mittel, um noch nicht behobenen Sicherheitslücken einen Schritt voraus zu sein.