Die erste anstehende Aufgabe vor dem nächsten Sicherheitsrelease von Node.js besteht darin, jede Anwendung zu finden, die es benötigen wird.
Das Node.js-Projekt plant, am Mittwoch, dem 11. November, oder kurz danach Sicherheitsupdates für seine Zweige 22.x, 24.x und 26.x zu veröffentlichen. Die am 3. November veröffentlichte Vorabinformation führt für jeden Zweig „hoch“ als höchste Einstufung auf.
Für Sicherheitsteams bietet das Vorbereitungsfenster die Gelegenheit, eingesetzte Runtimes zu identifizieren, Verantwortliche für Updates zu benennen und Tests zu organisieren, bevor Details zu den Schwachstellen öffentlich werden. Der Patchplan sollte festhalten, wie die Node.js-Runtime jeder Anwendung installiert und aktualisiert wird.
Drei Zweige sind betroffen
Die offizielle Sicherheitsmitteilung führt 22.x, 24.x und 26.x für Updates am oder kurz nach dem 11. November auf; für jeden Zweig ist „hoch“ die höchste Einstufung.
Die Mitteilung enthält noch keine CVE-Kennungen, technischen Beschreibungen, Angaben zur Anzahl der Schwachstellen oder Nummern der behobenen Patchversionen. Sie enthält auch keine Aussage, die eine aktive Ausnutzung bestätigt.
Das schränkt ein, was sich über die Gefährdung von Anwendungen sagen lässt. Die Einstufung als schwerwiegend allein sagt nicht aus, ob ein Problem die Ausführung von Code aus der Ferne ermöglicht, eine Authentifizierung erfordert oder eine bestimmte Konfiguration betrifft. Diese Fragen lassen sich erst anhand der vollständigen Sicherheitsmitteilung beantworten.
Die aktuelle Node2Shell-Schwachstelle verdeutlicht, warum diese Bedingungen wichtig sind: Die Gefährdung hing davon ab, dass Anwendungen von Angreifern kontrollierte, mit Brotli komprimierte Daten verarbeiteten. Die Vorabinformation für November stellt keinen Zusammenhang mit dieser früheren Schwachstelle her.
Die Runtime finden, die die Anwendung tatsächlich bedient
Beginnen Sie mit einem Inventar, das jede Node.js-Bereitstellung ihrer Version, dem Anwendungsbesitzer, ihrer Gefährdung und der Update-Methode zuordnet. Berücksichtigen Sie Produktionsdienste, Container-Images, Entwicklungs- und CI-Systeme sowie von externen Anbietern betreute Anwendungen.
Dies entspricht den Phasen Bewertung und Priorisierung im Lebenszyklus des Schwachstellenmanagements: Identifizieren Sie Anlagen und ihren geschäftlichen Kontext, bevor Sie die Reihenfolge der Behebung festlegen.
Vor dem Eintreffen der Updates sollten Teams:
- Eingesetzte Versionen erfassen. Prüfen Sie dies innerhalb der jeweiligen Anwendungs- oder Containerumgebung; die lokale Version eines Entwicklers belegt nicht, welche Version in der Produktion ausgeführt wird.
- Den Verantwortlichen für das Update identifizieren. Stellen Sie fest, ob die Runtime aus einem Betriebssystempaket, einem Container-Image, einer direkten Installation oder einem von einem Anbieter verwalteten Produkt stammt.
- Einen Bereitstellungsweg vorbereiten. Organisieren Sie Staging-Tests, gegebenenfalls den Neubau von Containern, Neustarts von Diensten und Prüfungen auf Anwendungsausfälle.
- Die Zuständigkeiten des Anbieters klären. Fragen Sie bei verwalteten Diensten, wer Runtime-Fixes einspielt, wann sie verfügbar werden und was Kunden neu bereitstellen müssen.
Wenn die Organisation automatisierte Patch-Management-Dienste nutzt, überprüfen Sie deren Abdeckung für diese Bereitstellungen. Die Existenz einer zentralen Patch-Plattform belegt nicht, dass die gebündelte Runtime jeder Anwendung abgedeckt ist.
Nicht mehr unterstützte Versionen erfordern eine Migrationsentscheidung
Node.js weist ausdrücklich darauf hin, dass Versionen am Ende ihres Lebenszyklus weiterhin betroffen sind, wenn Sicherheitsreleases erscheinen. Ihr Fehlen in der Liste des bevorstehenden Releases sollte nicht als Beleg dafür gewertet werden, dass sie sicher sind.
Der Releaseplan des Projekts führt Node.js 20 als am Ende seines Lebenszyklus auf und empfiehlt für Produktionsanwendungen Releases mit Active LTS oder Maintenance LTS.
Teams, die nicht unterstützte Installationen finden, sollten einen unterstützten Upgradepfad festlegen und die Kompatibilität der Anwendungen testen. Besteht eine Vereinbarung über kommerziellen Support, sollten sie mit dem Anbieter den Umfang und Zeitplan der Sicherheitsupdates bestätigen.
Den Abschluss des Patchings messbar machen
Sobald die Releases verfügbar sind, vergleichen Sie die veröffentlichten Bedingungen der Schwachstellen mit dem Inventar. Nutzen Sie die offengelegten Angriffswege, die Gefährdung und die geschäftlichen Auswirkungen, um die Bereitstellung zu priorisieren, und installieren Sie anschließend das zutreffende behobene Release über den unterstützten Updateprozess der Anwendung.
Bewahren Sie für jeden Dienst Nachweise über die nach der Bereitstellung laufende Version, erfolgreiche Zustandsprüfungen und verbleibende Ausnahmen auf. Eine Build-Definition zu aktualisieren ist nur ein Teil der Aufgabe; überprüfen Sie, dass die Ersetzung die Instanzen erreicht hat, die reale Workloads verarbeiten.
Für jedes verzögerte Update sollte es einen benannten Verantwortlichen, eine Frist und auf die tatsächliche Schwachstelle abgestimmte Kontrollen geben. Solange die technischen Details nicht veröffentlicht sind, gibt es keine Grundlage für die Annahme, dass eine bestimmte Firewallregel oder Konfigurationsänderung diese Probleme beheben wird.
Das nützliche Ergebnis vor dem 11. November ist ein Inventar mit verantwortlichen Eigentümern und einem getesteten Bereitstellungsprozess. Nach der Veröffentlichung sind es Nachweise dafür, dass betroffene Dienste behobene Versionen ausführen, wobei noch nicht erfolgte Bereitstellungen bis zum Abschluss nachverfolgt werden.
Mehr dazu: GitLabs zweiter kritischer RCE-Patch im Oktober zeigt, warum kürzlich gepatchte Systeme weiterhin anhand jeder neuen Sicherheitsmitteilung überprüft werden müssen.