Open-Source-Projekte sehen sich zunehmend mit Sicherheitswarnungen konfrontiert, deren mediale Inszenierung in keinem Verhältnis zur tatsächlichen Bedrohung steht. Die Entdecker statten die Lücken mit CVE-Nummern, eingängigen Namen und eigenen Websites aus, um maximale Aufmerksamkeit zu erzeugen, obwohl die Schwachstellen oft nur theoretischer Natur sind.
Die Maintainer der betroffenen Projekte können die Alarmmeldungen aufgrund der künstlich erzeugten Publicity nicht ignorieren. Sie müssen jede Meldung aufwendig prüfen, was immense Kosten verursacht. Neue Evaluierungen werden fällig, und Unternehmen, die die betroffene Bibliothek einsetzen, müssen reagieren. Der finanzielle Schaden kann schnell in die Zehntausende Dollar gehen.
Wenn Sicherheitsforschung zur Show wird
Der australische Sicherheits- und Kryptografieexperte Peter Gutmann, bekannt durch seine Arbeit an PGP und dem Open-Source-Toolkit cryptlib, warnt eindringlich vor den negativen Folgen dieser Entwicklung. Auf der OpenSSL-Konferenz in Prag hält er im Oktober einen Vortrag zu diesem Thema. Gegenüber heise developer erklärte er die Mechanismen hinter diesem Phänomen, das er als „Stunt Cryptography“ bezeichnet.
Laut Gutmann ist dies keine organisierte böswillige Kampagne, sondern ein natürlicher Nebeneffekt des Publikationssystems in der Sicherheitsforschung. Ein normaler Buffer Overflow in Apache erhält eine CVE-Nummer, wird gepatcht, und niemand nimmt groß Notiz. Wer jedoch als Forscher oder Akademiker wahrgenommen werden will, braucht etwas Ausgefallenes. Der Unterschied sei wie zwischen einem Zauberer, der ein ganzes Gebäude verschwinden lässt, und jemandem, der ein Stück Kuchen verschwinden lässt – über Ersteres redet jeder. Um ein Konferenzpaper unterzubringen, sind außergewöhnliche, kreative Angriffe nötig, deren Nutzen als tatsächlicher Angriff sich jedoch umgekehrt proportional zu ihrer Cleverness verhält. Echte Angreifer suchen nicht nach einer Methode, die drei Tage Vorbereitung und drei Tage Laufzeit benötigt, um zehn Bit Daten zu stehlen; sie wollen einen simplen Buffer Overflow, der zu Remote Code Execution führt.
Hier liege auch der entscheidende Unterschied zu echten Bedrohungen wie Heartbleed oder Stuxnet. Diese waren reale, ausnutzbare Probleme, die von Angreifern tatsächlich verwendet wurden. Bei „Stunt Cryptography“ ist das Gegenteil der Fall: Der Angriff ist wissenschaftlich clever, doch ein realer Angreifer, der ihn nutzt, ist nicht bekannt.
Drei exemplarische Fälle: Clever, aber nutzlos
Gutmann nennt konkrete Beispiele für diese Art von Kampagnen. SWEET32 etwa setzt voraus, dass das Opfer den Code des Angreifers im eigenen Browser ausführt und dabei 785 Gigabyte an Web-Traffic verschlüsselt – nur um am Ende ein einziges HTTP-Cookie zu erbeuten. Der Angriff besitzt ein eigenes Logo und eine eigene Website, ist aber völlig unpraktikabel. EFAIL ermöglichte die Rekonstruktion verschlüsselter E-Mails, allerdings nur unter exakt passenden Bedingungen. Auch hier: griffiger Name, Logo, Website – das volle Programm. Ein weiteres Beispiel ist CVE-2023-51767, ein akademisches Paper, das als Schritt eins vorsieht, als Root ein SIGSTOP an sshd zu senden. Darauf folgen mehrere Seiten komplexer Kryptografie. Das Problem: Wer bereits Root-Zugriff hat, benötigt den zweiten Schritt nicht.
Die Motivation hinter diesen Kampagnen ist nicht finanziell. Es geht um Reputation, um „CV-Enhancements“. Das Publikationssystem belohnt das Ungewöhnliche und Kreative, nicht das Praktikable.
Die Rechnung: Zehntausende Dollar pro unbegründeter Meldung
Die finanziellen Auswirkungen sind gravierend. In einem konkreten Fall musste ein Open-Source-Projekt zwischen 30.000 und 50.000 US-Dollar sowie drei bis sechs Monate Entwicklerzeit aufwenden, um auf eine unbegründete CVE-Meldung zu reagieren. Es handelte sich um FIPS-140-validierten Code. Eine erneute FIPS-Validierung wegen einer CVE kostet typischerweise diesen Betrag und dauert so lange. Das Problem pflanzt sich fort: Eine CVE-Nummer ist plattformunabhängig und entzieht die Zertifizierung allen Projekten gleichzeitig, die auf dem validierten Code aufbauen. Viele FIPS-Evaluierungen sind lediglich ein Rebranding fremder Evaluierungen.
Warum kann man eine solche Lücke nicht einfach ignorieren? Sobald eine CVE existiert, taucht sie in jedem Schwachstellen-Scanner und auf jeder Compliance-Checkliste auf. Die Projekte befinden sich in einer kafkaesken Situation: Es gibt eine CVE, also muss sie behoben werden – aber es gibt keine tatsächliche Schwachstelle. Die Behebung muss jedem Anwender einzeln erklärt werden. Allein GnuPG benötigte rund drei Personenwochen, um die GPGFail-Behauptungen zu widerlegen, von denen sich keine als ausnutzbare Schwachstelle erwies. Die einfache Abkürzung, die Sache als behoben zu deklarieren, wälzt die Kosten auf alle nachgelagerten Nutzer ab.
Die Gesamtkosten können noch drastischer ausfallen. Bei einer weitverbreiteten Bibliothek wie libcurl, die in rund 30 Milliarden Instanzen installiert ist, kann eine einzige unbegründete CVE zu Kosten von Hunderttausenden US-Dollar und Jahren an kumulierter Arbeitszeit führen. Große Organisationen brauchen für das Ausrollen eines regulären Fixes fünf bis sechs Monate, für einen hoch eingestuften Sicherheitsfehler drei Monate. Compliance-Vorgaben wie PCI DSS setzen feste Fristen von 30 Tagen für kritische Funde, unabhängig davon, ob das Problem real ist. Die Folgeschäden können die vermeintliche Schwachstelle sogar übertreffen: Als Scanner eine niedrig eingestufte CVE in der mit Windows ausgelieferten curl.exe meldeten, löschten Anwender die Datei aus System32, woraufhin Windows Update eine Manipulation erkannte und den Dienst verweigerte.
Wie Projekte sich wehren können – und warum es schwierig ist
Gutmann plädiert für eine grundlegende Änderung des Systems. Sein Vorschlag, den er in Prag vorstellen wird: Den Schweregrad einer CVE-Meldung sollte das betroffene Projekt festlegen, nicht der Einreicher. Dies müsste Optionen wie „nicht zutreffend“ oder „vanity“ (Eitelkeit) umfassen. Größere Projekte können selbst zur CVE Numbering Authority werden und so unbegründete Einreichungen abfangen, bevor sie veröffentlicht werden. Für kleinere Projekte, die von einer einzelnen Person betrieben werden, ist dies nicht machbar.
Eine Anfechtung einer unbegründeten CVE ist langsam und undankbar. OpenSSH hat dies bei CVE-2023-51767 versucht. Selbst eine eindeutig falsche CVE wie 2016-2427 steht seit Jahren im Status „disputed“, da es für Einsprüche keinen Zeitrahmen gibt. Eine branchenweite Initiative gegen diese Entwicklung existiert nicht. Die eigentliche Lösung, so Gutmann, wäre ein Wandel in der akademischen Welt, die auch unpraktikable, aber clevere Angriffe als solche anerkennen würde – eine Perspektive, die er jedoch für unwahrscheinlich hält. Die verstreuten Reaktionen auf Projektebene, wie curl mit der Einstufung „lower-than-LOW severity“, sind daher nur ein erster, wenn auch wichtiger Schritt.
