Skip to main content

Responsible Disclosure: Die Auswirkungen von Schwachstellenmeldungen auf die Open-Source-Sicherheit

Artikel von
Headshot of Asaf Biton

Asaf Biton

7. April 2020

0 Min. Lesezeit

Es ist ein weitverbreiteter Irrtum, dass es verantwortungsvoll wäre, eine Schwachstelle sofort allgemein bekannt zu machen, sobald sie entdeckt wurde. Tatsächlich ist das Gegenteil der Fall.

Responsible Vulnerability Disclosure ist ein in der Cybersicherheit verbreitetes Modell für Schwachstellenmeldungen. Dabei werden Zero-Day-Schwachstellen zunächst vertraulich gemeldet. So haben Code- und Anwendungsbetreuer ausreichend Zeit, einen Fix oder Patch bereitzustellen, bevor die Schwachstelle schließlich öffentlich gemacht wird. Andernfalls würden wir die Sicherheit der Endnutzer gefährden. Wie immer kommt es auf die richtige Balance an: Ziel ist es, sowohl die Zeit, in der die Schwachstelle vertraulich behandelt wird, als auch die Zeit, in der die Anwendung ohne Fix verwundbar bleibt, möglichst kurz zu halten.

Dieses Modell gibt es schon seit Jahren. Softwareunternehmen stellen häufig ein Dokument mit ihren Offenlegungsrichtlinien bereit, in dem ihr eigener Responsible-Disclosure-Prozess beschrieben wird – also, was sie tun, wenn jemand eine Schwachstelle in ihrer Anwendung entdeckt. In der Open-Source-Welt läuft es jedoch etwas anders.

Herausforderungen bei der Einhaltung eines Responsible-Disclosure-Prozesses

Eine neue Schwachstelle zu entdecken, ist wirklich aufregend. Es ist verständlich, dass Forschende ihre Arbeit so schnell wie möglich veröffentlichen und sich der nächsten Herausforderung widmen möchten. Doch meistens ist dieser Prozess umständlich:

  • Für Open-Source-Pakete gibt es nicht immer offizielle Offenlegungsrichtlinien.

  • Selbst wenn es eine Richtlinie gibt, unterscheidet sie sich meist von Paket zu Paket.

  • Der Prozess ist oft lang und kompliziert und umfasst mehrere Schritte.

  • Zu den weiteren Schritten kann die Vergabe einer CVE-ID gehören. Ohne eine zentrale Stelle – auch CNA (CVE Numbering Authority) genannt – kann das eine ziemlich mühsame Aufgabe sein.

Das sind einige Gründe dafür, dass viele Forschende heutzutage keinen Responsible- oder Coordinated-Disclosure-Prozess befolgen. Die „einfache“ Alternative besteht darin, die Schwachstellen stattdessen öffentlich zu machen und so Dringlichkeit zu erzeugen. Unter Zeitdruck und in kurzer Zeit veröffentlichte Fixes sind häufig unvollständig oder fehlerhaft – die Schwachstelle bleibt dadurch bestehen oder es entstehen neue Angriffsvektoren im Paket.

Warum sollten Sie einen ordnungsgemäßen Schwachstellenmeldeprozess befolgen?

Ein angemessener Offenlegungsprozess gibt den Betreuern die Möglichkeit, die Schwachstelle ohne Zeitdruck sorgfältig zu bewerten. Anschließend können sie entscheiden, ob sie einen Fix bereitstellen, und bei Bedarf Backports vorbereiten. Sobald die neuen Versionen verfügbar sind, können sie die Schwachstelle schließlich sicher öffentlich bekannt geben. Während des gesamten Prozesses bleiben die Details der Schwachstelle vertraulich, sodass sie nicht missbraucht werden können.

Meldung von Open-Source-Schwachstellen bei Snyk

Snyk hat sein Schwachstellenmeldeprogramm 2019 ins Leben gerufen, um diese Lücke zu schließen und Forschenden eine einfache Möglichkeit zu bieten, Schwachstellen zu melden – selbstverständlich mit voller Anerkennung ihrer wertvollen Arbeit bei der Entdeckung.

Unser Sicherheitsteam prüft jeden einzelnen Schwachstellenbericht sorgfältig. Dafür sind spezifische Kenntnisse und ein genaues Verständnis der jeweiligen Programmiersprache, des Pakets und seines Kontexts erforderlich. Sobald die Details der Schwachstelle verifiziert sind, arbeitet das Team eng mit den Betreuern zusammen, um sie zeitnah zu beheben. Als CNA (CVE Numbering Authority) unterstützen wir schließlich bei der Vergabe einer CVE-ID und der Veröffentlichung einer ausführlichen Sicherheitsmeldung.

2019 haben wir bei der Offenlegung von über 130 Schwachstellen geholfen. Zu den bemerkenswerten Fällen zählen RCE in mongo-express und beliebiges Schreiben von Dateien in yarn.

Wir haben mit unabhängigen Forschenden, Sicherheitsexperten und der akademischen Gemeinschaft zusammengearbeitet! Das Jahr 2020 begann für uns mit einer umfangreichen Partnerschaft mit dem Security-Lab-Team der Johns Hopkins University. Gemeinsam halfen wir bei der Offenlegung von über 50 Schwachstellen.

Das Team der Johns Hopkins University entwickelte eine neue Methode, um die Suche nach Schwachstellen zu automatisieren. Gemeinsam haben wir eine maßgeschneiderte Lösung entwickelt, die bei der Bearbeitung einer großen Anzahl von Schwachstellen hilft. Freuen Sie sich auf einen kommenden Artikel, der die Einzelheiten dieses Projekts näher beleuchtet.

Wie können Sie loslegen?

Am besten reichen Sie Ihren Bericht über das dafür vorgesehene Formular hier ein. Alternativ können Sie uns auch eine E-Mail an report@snyk.io senden. Bitte lesen Sie vor dem Einreichen eines Berichts unsere Richtlinie zur Offenlegung von Schwachstellen.