Interview: Zehntausende US-Dollar Schaden durch aufgeblähte Sicherheitswarnungen

Open-Source-Projekte erhalten immer häufiger Sicherheitswarnungen, die von den Herausgebern übermäßig stark beworben werden: Die gemeldeten Lücken bekommen CVE-Nummern, spannend klingende Namen und eigene Werbe-Webseiten. So wollen die Herausgeber eine größtmögliche öffentliche Aufmerksamkeit erzielen. Von der Sache her haben die gemeldeten Schwachstellen oft aber nur eine geringe Relevanz und sind eher theoretischer Natur.

Peter Gutmann ist Wissenschaftler am Department of Computer der University of Auckland und beschäftigt sich mit dem Entwurf und der Analyse kryptografischer Sicherheitsarchitekturen, der Usability von Sicherheitssystemen und der Sicherheit eingebetteter Systeme. Er war an der Entwicklung des bekannten Verschlüsselungspakets PGP beteiligt und hat zahlreiche Artikel sowie RFCs zu den Themen Sicherheit und Verschlüsselung verfasst, insbesondere maßgeblich das weltweit am längsten bestehenden Sicherheits-RFC 8894. Jetzt ist er Entwickler des Open-Source-Toolkits cryptlib und Autor des Buches „Cryptographic Security Architecture: Design and Verification“. Demnächst wird sein neues Werk „Engineering Security“ erscheinen.

Die Maintainer der betroffenen Projekte können sie jedoch wegen der künstlich erzeugten Bekanntheit nicht ignorieren und müssen sie aufwendig prüfen. Der Schaden geht oft in die Zehntausende, weil neue Evaluierungen fällig werden und Unternehmen, die die betroffene Bibliothek im Einsatz haben, regieren müssen.

Der australische Sicherheits- und Kryptografieexperte Peter Gutmann (PGP und crytlib) warnt vor den negativen Folgen und Kosten dieser Kampagnen, da sie die Open-Source-Teams unnötig belasten. Auf der OpenSSL-Konferenz im Oktober in Prag wird er einen Vortag zu diesem Thema halten, heise developer hat im Vorfeld dieses schriftliche Interview mit ihm geführt.

Am 22. und 23. September findet die heise devSec 2026 statt. Im Fokus der Konferenz zu sicherer Softwareentwicklung stehen dieses Jahr unter anderem die sichere Software Supply Chain und der Security-Aspekt bei Agentic AI in der Softwareentwicklung.

Gutmann spricht darin über neben Stunt Cryptography auch über den allgegenwärtigen AI Slop, der Maintainer zusätzlich belastet.

Du nennst solche künstlich aufgeblähten Sicherheitswarnungen Stunt Cryptography. Wie unterscheiden sie sich von früheren Fällen, die ja auch schmissige Namen hatten wie Stuxnet oder Heartbleed?

Das ist keine organisierte Kampagne und auch nichts Böswilliges – es ist ein natürlicher Nebeneffekt der Art, wie Publikationen in der Sicherheitsforschung funktionieren. Wer normalerweise einen Buffer Overflow in Apache entdeckt, bekommt eine CVE-Nummer, die Lücke wird gepatcht, und alle gehen wieder ihrer Arbeit nach, ohne dass es groß jemand bemerkt.

Wer als Forscher oder Akademiker wahrgenommen werden will, braucht dagegen etwas Ausgefallenes. Das ist wie der Unterschied zwischen mir, der ein Stück Kuchen verschwinden lässt – das interessiert niemanden – und einem Zauberer, der ein ganzes Gebäude verschwinden lässt: Darüber reden alle. Um ein Konferenzpaper unterzubringen, muss man also etwas sehr Kreatives und Ungewöhnliches machen, und das ist in der Regel umgekehrt proportional zu seinem Nutzen als tatsächlichem Angriff. Echte Angreifer wollen etwas Einfaches: einen Buffer Overflow, der auf jedem angegriffenen System zu Remote Code Execution führt – nicht etwas, das drei Tage Vorbereitung und weitere drei Tage Laufzeit braucht, um auf einem einzigen System zehn Bit an Daten zu erbeuten.

Darin liegt auch der Unterschied zu Heartbleed oder Stuxnet: Das waren echte, ausnutzbare Probleme, die Angreifer tatsächlich verwendet haben. Bei Stunt Cryptography ist es umgekehrt – der Angriff ist sehr clever, aber bis heute konnte niemand einen realen Angreifer benennen.

Kannst du ein paar Beispiele für solche Stunt-Cryptography-Kampagnen beschreiben?

Ein gutes Beispiel ist SWEET32. Der Angriff setzt voraus, dass das Opfer den Code des Angreifers im eigenen Browser ausführt und dabei 785 Gigabyte an Web-Traffic für den Angreifer verschlüsselt – um am Ende ein einziges HTTP-Cookie zu bekommen. Sehr clever, mit eigenem Logo und eigener Website und völlig unpraktikabel: alle Zutaten eines Stunt-Cryptography-Angriffs.

Zwei weitere Beispiele aus dem Vortrag, den ich im Oktober auf der OpenSSL-Konferenz in Prag halte: EFAIL, mit dem sich der Inhalt verschlüsselter E-Mails rekonstruieren ließ – allerdings nur, wenn die Bedingungen exakt stimmten. – aber: griffiger Name, Logo, eigene Website – das volle Programm. Oder CVE-2023-51767, ein Paper auf einer akademischen Sicherheitskonferenz: Schritt eins, als Root ein SIGSTOP an sshd schicken. Schritt zwei – nun folgen mehrere Seiten Stunt Cryptography – Schritt drei, veröffentlichen. Aber: Wer bereits Root-Zugriff hat, braucht Schritt zwei gar nicht.

Steckt hier eine systematische oder finanziell motivierte Masche dahinter?

Nicht im Sinne eines gezielten Vorgehens einer bestimmten Gruppe. Es ist ein Nebeneffekt davon, wie das Publizieren in der Sicherheitsforschung funktioniert: Um ein Paper angenommen zu bekommen, braucht man etwas Kreatives und Ungewöhnliches – und genau das belohnt das System. Es geht um Reputation – CV-Enhancements sozusagen, nicht um Geld.

Steigende Kosten für die Projekte

Du hast in einem konkreten Fall geschätzt, dass ein Open-Source-Projekt 30.000 bis 50.000 US-Dollar und drei bis sechs Monate Entwicklerzeit aufwenden musste, um auf eine unbegründete CVE-Meldung zu reagieren. Hast Du da weitere Details, um was für eine Lücke und Meldung es sich gehandelt hat?

Das stammt aus einem Gespräch mit einem Contributor eines großen Open-Source-Projekts. In diesem Fall ging es um FIPS-140-validierten Code. Die Zahlen sind für diese Situation nicht ungewöhnlich: Eine erneute FIPS-Validierung wegen einer CVE kostet typischerweise 30.000 bis 50.000 US-Dollar und dauert drei bis sechs Monate. Und es bleibt nicht bei einem Projekt – eine CVE-Nummer ist plattformunabhängig, sie entzieht die Zertifizierung also überall gleichzeitig, auch all jenen, die ihre eigene Zertifizierung auf diesem validierten Code aufgebaut haben. Sehr viele FIPS-Evaluierungen sind genau das: ein Rebranding einer fremden Evaluierung, weil eine eigene von Grund auf schwer zu stemmen ist.

Lässt sich eine Lücke mit nur geringer Relevanz nicht schneller abfertigen?

Das Problem ist, sobald eine CVE existiert, kann man sie nicht einfach ignorieren. Sie taucht in jedem Schwachstellen-Scanner und auf jeder Compliance-Checkliste der Kunden auf. Man landet in einer kafkaesken Situation: Es gibt eine CVE, also muss sie behoben werden – aber es gibt keine tatsächliche Schwachstelle, also kann sie nicht behoben werden. Das muss man dann jeder einzelnen Person erklären, die die CVE-Meldung gesehen hat.

Eine fundierte Gegendarstellung zu schreiben, ist echte Arbeit – GnuPG brauchte rund drei Personenwochen, um die GPGFail-Behauptungen zu beantworten, von denen sich keine als ausnutzbare Schwachstelle erwies. Die Abkürzung, die Sache einfach als behoben zu deklarieren, damit sie verschwindet, wälzt die Kosten auf alle nachgelagerten Nutzer ab, die dann für nichts aktualisieren müssen.

Ist bei Vorfällen dieser Art der finanzielle Schaden allgemein so hoch? Lässt sich das verallgemeinern?

Eine feste Zahl gibt es nicht – das skaliert damit, wie verbreitet der Code ist und welche Compliance-Regime greifen. Bei einer weitverbreiteten Bibliothek kann eine einzige unbegründete CVE zu Kosten von Hunderttausenden UD-Dollar und Jahren an kumulierter Arbeitszeit anwachsen, weil jeder nachgelagerte Nutzer reagieren muss. Allein libcurl ist in rund 30 Milliarden Instanzen installiert. Große Organisationen brauchen für das Ausrollen eines regulären Fixes typischerweise fünf bis sechs Monate, für einen hoch eingestuften Sicherheitsfehler drei Monate, und selbst die Überholspur für Notfälle dauert sechs Wochen bis drei Monate und ist so teuer, dass sie selten genutzt wird.

Compliance-Vorgaben wie PCI DSS setzen feste Fristen obendrauf – 30 Tage für kritische und hohe Funde, 90 Tage für den Rest – unabhängig davon, ob das Problem real ist. Und die Folgeschäden können schlimmer sein als die vermeintliche Schwachstelle selbst: Als Scanner eine niedrig eingestufte CVE in der mit Windows ausgelieferten curl.exe meldeten, haben Leute die Datei aus System32 gelöscht – woraufhin Windows Update eine Manipulation erkannte und den Dienst verweigerte.

Wie können sich Projekte vor Stunt-Cryptography-Kampagnen schützen?

Mein Vorschlag, und den werde ich auch in Prag machen: Den Schweregrad einer CVE-Meldung sollte das betroffene Projekt festlegen, nicht derjenige, der sie einreicht – einschließlich Optionen wie „nicht zutreffend“ oder, noch besser, „vanity“, also Eitelkeit.

Größere Projekte können darüber hinaus selbst zur CVE Numbering Authority werden und so unbegründete Einreichungen abfangen, bevor sie veröffentlicht werden. Für ein Projekt, das man allein betreibt, ist das aber nicht machbar. Man kann auch versuchen, eine unbegründete CVE anzufechten – OpenSSH hat das bei CVE-2023-51767 getan –, aber das ist langsam und meist undankbar. Selbst eine eindeutig falsche CVE wie 2016-2427 steht seit Jahren im Status „disputed“, weil es für Einsprüche keinen Zeitrahmen gibt. Sie bleiben einfach in der Schwebe.

Die eigentliche Lösung wäre, dass die akademische Welt Papers akzeptiert, die sagen: Hier ist ein cooler Angriff, völlig unpraktikabel, aber ein netter Trick. Das sehe ich allerdings nicht kommen.

Haben sich in der Open-Source-Szene gemeinsame Bestrebungen gegen solche Kampagnen entwickelt?

Nicht, dass ich wüsste – nichts Koordiniertes. Es sind verstreute Reaktionen auf Projektebene: curl bezeichnet manche Funde inzwischen als „lower-than-LOW severity“, einige Projekte wehren sich oder fechten CVEs auf eigene Faust an, und etliche Projekte sind allein wegen besonders haarsträubender CVEs zur eigenen Numbering Authority geworden. Eine branchenweite Initiative gibt es bislang nicht.