|
12.09.2026 08:33 Uhr |
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.
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, reagieren 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.
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.
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.
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.
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.
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.