KI durchbricht zwei Kulturen im Umgang mit Schwachstellen

• Nach der Offenlegung von Copy Fail kam Hyunwoo Kim zu dem Schluss, dass der bestehende Fix nicht ausreichte, und teilte noch am selben Tag einen Patch, doch das für Linux typische Verfahren stiller öffentlicher Fixes wurde durch eine externe Entdeckung offengelegt und führte zum Ende des Embargos
• Unter Linux, besonders im Networking-Bereich, ist es üblich, die Sicherheitsauswirkungen in einer privaten Liste zu teilen und Bugfixes öffentlich und schnell voranzutreiben, während die Existenz der eigentlichen Schwachstelle für einige Tage unter Embargo gehalten werden soll
• Nachdem jemand die öffentlichen Änderungen entdeckt, die Sicherheitsauswirkungen erkannt und sie veröffentlicht hatte, wurden anschließend die vollständigen Details offengelegt
• Da KI die Kosten dafür senkt, die sicherheitsrelevante Bedeutung einzelner Commits zu bewerten, wird es leichter, Schwachstellen in still öffentlich gemachten Fixes zu finden, und das Signal-Rausch-Verhältnis verbessert sich
• Auch die traditionelle koordinierte Offenlegung über 90 Tage verliert an Tragfähigkeit; in diesem Fall meldete Kuan-Ting Chen die ESP-Schwachstelle bereits 9 Stunden nach Kims Bericht unabhängig, was darauf hindeutet, dass sehr kurze Embargos die bessere Richtung sein könnten

---

Kollision zwischen Copy Fail und der Linux-Praxis für Sicherheitsfixes

• Nachdem die Schwachstelle Copy Fail öffentlich geworden war, kam Hyunwoo Kim zu dem Schluss, dass der bestehende Fix nicht ausreichte, und teilte noch am selben Tag einen Patch
• Kim folgte damit einem unter Linux, insbesondere im Networking-Bereich, üblichen Verfahren
  • Die Sicherheitsauswirkungen wurden mit einer privaten Liste von Linux-Sicherheitsingenieuren geteilt
  • Der Bugfix wurde öffentlich, aber still und schnell vorangetrieben
  • Ziel war es, die Existenz einer schwerwiegenden Schwachstelle für einige Tage unter Embargo zu halten, obwohl nur der eigentliche Fix öffentlich war
• Jemand anderes entdeckte die betreffende Änderung, erkannte die Sicherheitsauswirkungen und veröffentlichte sie
• Da die Schwachstelle damit als bereits öffentlich galt, endete das Embargo, woraufhin die vollständigen Details offengelegt wurden

Welchen Druck KI auf zwei Schwachstellenkulturen ausübt

• Kultur der koordinierten Offenlegung

  • Wer einen Sicherheitsbug findet, meldet ihn vertraulich an die Maintainer und gibt ihnen üblicherweise einen Zeitraum wie 90 Tage, um ihn zu beheben
  • Ziel ist, dass ein Fix ausgerollt wird, bevor die Schwachstelle allgemein bekannt ist

• „Ein Bug ist ein Bug“-Kultur

  • Dieser unter Linux besonders verbreitete Ansatz geht davon aus, dass jemand ein Verhalten, das der Kernel nicht zeigen sollte, in einen Angriff verwandeln kann
  • Man lenkt keine Aufmerksamkeit darauf, dass es sich um eine Schwachstelle handelt, und behebt sie so schnell wie möglich
  • Bei der Menge an Änderungen könnten Menschen den Fix übersehen, sodass in der Zwischenzeit noch Zeit bleibt, Systeme zu patchen

• Durch KI steigt das Risiko des öffentlichen Fix-Ansatzes

  • Schon ursprünglich funktionierte dieser Ansatz nicht perfekt, doch mit besserer KI für die Schwachstellensuche wird er zu einem größeren Problem
  • Weil viele Sicherheitsfixes erscheinen, ist das Prüfen von Commits attraktiver geworden, und das Signal-Rausch-Verhältnis steigt
  • Die Kosten dafür, jeden Commit beim Vorbeiziehen zu bewerten, sinken durch KI stetig, während die Wirksamkeit steigt

• Auch lange Embargos verlieren an Stärke

  • Früher war die Erkennung langsamer, sodass bei einer Meldung an den Vendor mit einem Offenlegungsfenster von 90 Tagen die Wahrscheinlichkeit hoch war, dass niemand sonst die Schwachstelle in dieser Zeit entdeckt
  • Diese Annahme wird nun schwächer, weil KI-gestützte Gruppen Software in großem Maßstab auf Schwachstellen scannen
  • In diesem Fall meldete Kuan-Ting Chen die ESP-Schwachstelle unabhängig bereits 9 Stunden nach Kims Bericht
  • Embargos können eine falsche Nicht-Dringlichkeit erzeugen und das Risiko erhöhen, indem sie die Zahl der Akteure begrenzen, die den Fehler beheben können

• Mögliche Richtung und ein kurzer Modelltest

  • Die Lösung ist nicht klar, doch sehr kurze Embargos scheinen ein guter Ansatz zu sein und müssten mit der Zeit womöglich noch kürzer werden
  • KI kann nicht nur Angreifer, sondern auch Verteidiger beschleunigen und dadurch Embargos praktikabel machen, die früher zu kurz und damit nutzlos gewesen wären
  • Als f4c50a403 an Gemini 3.1 Pro, ChatGPT-Thinking 5.5 und Claude Opus 4.7 gegeben wurde, erkannten alle drei Modelle sofort, dass es sich um einen Sicherheits-Patch handelte
  • Ohne Commit-Kontext und nur mit dem Diff war sich Gemini sicher, dass es ein Sicherheitsfix sei, GPT hielt es für wahrscheinlich, und Claude hielt es eher für unwahrscheinlich
  • Dieser Test war nur ein sehr schnelles Beispiel, bei dem jedes Modell mit dem Prompt "Without searching, does this look like a security patch?" genau einmal ausgeführt wurde; große Bedeutung für Modellvergleiche lässt sich daraus kaum ableiten

[GN⁺]

Hacker-News-Kommentare

• Diese Veränderung hat sich schon sehr lange angekündigt, und die Risse, die wir jetzt sehen, waren schon vorhersehbar, noch bevor man wusste, was ein LLM ist.
  Der Auslöser ist die zunehmende Transparenz von Software. Die Nutzung von Open Source und quelloffener Software hat stark zugenommen, und auch Reverse-Engineering- und Decompiler-Tools sind deutlich besser geworden. Die Zeit, in der übliche kommerzielle Closed-Source-Software für ernsthafte Angreifer noch sinnvoll verborgen war, ist bereits seit mehr als zehn Jahren vorbei.
  Seit BinDiff entwickelt sich dieses Problem langsam weiter. Wenn man Software patcht, legt man damit zwangsläufig auch die Schwachstelle offen. Bisher konnte man das leugnen, weil es ein gewisses Maß an Fachwissen brauchte, um zu erkennen, dass ein Patch zugleich eine Offenlegung der Schwachstelle ist, aber AI hat diese Ausrede beseitigt.
  Jedes Mal, wenn jetzt etwas in den mainline Linux gemergt wird, gibt es mehrere Organisationen, die den Diff in einen LLM-Prompt werfen, aggressiv prüfen, ob es sich um einen Security-Fix handelt, und Exploit-Guides erzeugen. Bei den meisten großen Open-Source-Projekten wie nginx, OpenSSL und Postgres wird es bald genauso sein.
  Die Praxis der koordinierten Offenlegung ist auf dieses Umfeld nicht abgestimmt, und eigentlich war sie das meiner Meinung nach schon in den letzten zehn Jahren nicht mehr.
  Seltsamerweise macht mir diese Situation nichts aus, denn ich denke, dass die Praxis der koordinierten Offenlegung schon immer unhinterfragt davon ausging, dass eine spätere Offenlegung besser für die operative Bequemlichkeit von Systemadministratoren sei. Diese Annahme darf man bezweifeln. Eine verzögerte Offenlegung nimmt selbst den Systembetreibern Informationen weg, die außer dem Einspielen von Patches noch andere Handlungsoptionen haben.

  • Die Aussage „Die Zeit, in der übliche kommerzielle Closed-Source-Software für ernsthafte Angreifer noch sinnvoll verborgen war, ist bereits seit mehr als zehn Jahren vorbei“ ist fast selbstverständlich, aber die letzte Verteidigungslinie ist, Software nicht öffentlich zu verteilen und sich auf eine Server-Client-Architektur zu stützen.
    Wenn Schwachstellen leichter gefunden und ausgenutzt werden, könnte diese Vorgehensweise häufiger werden. Natürlich ist das nicht immer möglich.
    In den letzten elf Jahren war es ziemlich ärgerlich, dass mit ProGuard obfuskierte Game-Client-Binaries mehrfach dekompiliert und auf GitHub hochgeladen wurden. Nur der nicht ausgelieferte Server-Code blieb privat.
    Interessanterweise hatten wir mit Angreifern, die das Netzwerkprotokoll reverse engineeren, kein Problem, solange wir es seltener als wöchentlich änderten. Jetzt scheint es aber so, als könnten Angreifer mit LLM-Unterstützung selbst dieses Tempo mithalten.
  • Die geschäftlichen Gründe für koordinierte Offenlegung von Schwachstellen habe ich immer verstanden, und im Job musste ich mich dieser Richtlinie auch fügen, aber persönlich war ich immer für Full Disclosure. Auf diesen Wandel habe ich sehr gewartet.

• Das wirkt eher wie ein altes Problem, das als AI-Problem neu verpackt wurde, als wie ein wirklich neues AI-Problem.
  Menschen haben schon lange vor dem Aufkommen von LLMs Kernel-Commit-Diffs verglichen, um herauszufinden, welche davon Security-Fixes sind. In dem Moment, in dem ein Patch öffentlich gepostet wird, hat das Wettrennen faktisch bereits begonnen.
  Ich bin mir auch nicht sicher, ob es wirklich hilft, die Frist bis zur öffentlichen Offenlegung zu verkürzen. Organisationen, die innerhalb weniger Stunden patchen können, sind ohnehin schon in guter Form, und der Rest braucht weiterhin Tage oder Wochen.
  Im Gegenteil: Je geringer die Kosten für die Erzeugung von Exploits werden, desto wahrscheinlicher wird koordinierte Offenlegung nicht weniger, sondern mehr Bedeutung bekommen.

  • „Menschen haben bereits Kernel-Commit-Diffs verglichen, um herauszufinden, welche davon Security-Fixes sind“, aber das erforderte Können und geschah meist nicht konsistent oder systematisch. Mit AI kann das jeder bei jeder Software tun.
    Zu „Ich bin mir nicht sicher, ob es hilft, die Frist bis zur öffentlichen Offenlegung zu verkürzen“: Die Frage ist, warum 90 Tage und nicht 2 Jahre? Der Punkt des Artikels ist, dass sich die Faktoren verändert haben, die dieses Gleichgewicht bestimmt haben, weil gleichzeitige Entdeckungen häufiger werden. Wenn ohnehin viele Menschen außerhalb der Frist Exploits finden werden, dann ist die Schonfrist kein echtes Zeitfenster, sondern nur eine Illusion.
    Dass „billige Exploit-Erzeugung koordinierte Offenlegung wichtiger macht“, sehe ich auch so. Aber zugleich macht sie sie weniger praktikabel. Wenn selbst Script Kiddies Zero-Days finden und ausnutzen können, bricht die Fähigkeit zur Koordination zusammen.
    In der Whitehat-Kultur gab es schon immer eine Art handwerkliche Gildenethik. Wenn diese Gilde zerbricht, verliert auch diese Ethik ihren Platz.
  • Ich habe nicht die gesamte Linux-Entwicklung ständig verfolgt, aber ich weiß nicht, ob es früher schon vorkam, dass funktionsfähige Exploits auf Mailinglisten veröffentlicht wurden, noch bevor ein Patch überhaupt in den Kernel kam.
    Ich habe so etwas nie gesehen, und selbst wenn man die leicht überhitzte Stimmungslage berücksichtigt, entsteht jetzt doch der Eindruck, dass so etwas dank LLMs häufiger passieren wird.
  • Torvalds sagte, dass man bei der Entdeckung größerer Probleme das anschließende Spektakel nicht noch zusätzlich braucht und dass es ausreicht, einfach den Bug selbst offenzulegen [1].
    Deshalb ist es nicht überraschend, dass Dirtyfrag über einen Linux-Kernel-Fix offengelegt wurde [2].
    [1] https://www.zdnet.com/article/torvalds-criticises-the-securi...
    [2] https://afflicted.sh/blog/posts/copy-fail-2.html
  • Es trifft wohl zu, dass ein altes Problem durch AI noch verschärft wird.
  • Ich habe das Gefühl, jede Woche eine neue Variante desselben Themas zu schreiben, daher würde ich mir, wenn etwas Bequemlichkeit erlaubt ist, einfach eine frühere Version von mir selbst teilen.
    https://news.ycombinator.com/item?id=47921829

• Wir haben ein großes Problem.
  Die USA befinden sich im Krieg, und ein großer Teil der Welt ebenfalls in einer Form von kriegsähnlichen Cyberangriffen. Das gilt für die USA, die EU, große Teile des Nahen Ostens, Israel und Russland.
  Wichtige Dienste wie Ubuntu, GitHub, Let’s Encrypt und Stryker wurden angegriffen und fielen tagelang aus, und ganze Krankenhaus-Systeme wurden teilweise lahmgelegt.
  Inmitten all dessen hat AI die Geschwindigkeit der Angriffserzeugung massiv erhöht. Schneller, als die Verteidiger reagieren können. Früher waren Zero-Day-Angriffe selten, jetzt sind sie normal geworden.
  Es wird schlimmer, bevor es besser wird, und vielleicht sogar viel schlimmer.

  • Ich sehe nicht, wie es besser werden soll.

• Bei der Stelle „Jetzt kommen so viele Security-Fixes herein, dass das Durchsehen von Commits attraktiver geworden ist. Das Signal-Rausch-Verhältnis ist höher“ frage ich mich, warum das so sein soll.
  Entscheidend ist der Teil „Die Kosten dafür, dass AI jeden Commit im Vorbeigehen bewertet, werden immer geringer und effektiver“. Mit AI fällt die Annahme weg: „Es gibt zu viele Änderungen, da wird es niemand bemerken.“

• Dieser schnelle Test zeigt nicht besonders viel. Wenn man AI direkt fragt: „Ist das ein Security-Patch?“, dann legt man ihr diese Annahme bereits nahe und steuert die Ausgabe in diese Richtung.
  Eine Konfusionsmatrix wäre nützlicher. Ich verstehe natürlich, dass dieser Text kein detaillierter Beitrag zum Testen von AI-Fähigkeiten ist.

  • Ich stimme zu, dass das als zusätzlicher Beleg nicht besonders stark ist. Wenn jemand denselben Test inklusive dieses Commits für N Commits aus dieser Liste durchlaufen lassen würde, fände ich die Ergebnisse sehr interessant.
  • Im Idealfall bräuchte man für alle Kernel-Diffs einen Phi-Koeffizienten, also MCC, der sich aus der Konfusionsmatrix der Ja/Nein-Klassifikation durch das LLM berechnen lässt.
    Man kann ihn aus der Anzahl wahrer Positiver, wahrer Negativer, falscher Positiver und falscher Negativer berechnen.

• Wir brauchen automatisierte Patch- und Release-Zyklen.
  Bisher haben wir uns auf unglaublich langsame manuelle Verfahren verlassen: Meldung entgegennehmen, untersuchen, validieren, patchen und ein Release vorbereiten. Dass ein Fix Monate braucht, ist ganz normal. In einer Zeit, in der Angreifer innerhalb weniger Stunden neue Exploits am Fließband erzeugen können, ist das viel zu langsam.
  Um die durchschnittliche Zeit bis zum Patch zu verkürzen, muss man die Engpässe entlang der gesamten Wertschöpfungskette iterativ verbessern.
  Nach Eingang einer Bug-Meldung sollte man innerhalb einer Stunde bei einem gepatchten Produkt sein, das QA-testbar ist. Das muss standardisiert oder Open Source werden, und die gesamte Software-Lieferkette sollte es nutzen: Linux-Kernel → Distribution → Produkt, das die Distribution nutzt → Benutzer. Mit AI gibt es keinen Grund, warum das nicht möglich sein sollte; wir sind einfach nur zu langsam.

• AI wird das Update-Fenster dramatisch verkleinern. 2026 noch über Dependency-Cooldown nachzudenken, ist das Schlechteste überhaupt, jetzt muss man über Dependency-Warm-up nachdenken.
  Bald wird so etwas wie eine sichere Offenlegung von Schwachstellen in Open-Source-Projekten verschwinden. Zentralisierte SaaS-Dienste werden hier einen großen Sicherheitsvorteil haben.

  • Closed-Source-zentralisierte SaaS wird einen großen Sicherheitsvorteil haben.
    Eine Remote-Code-Execution-Schwachstelle in einer Open-Source-Abhängigkeit bedeutet, dass man in dem Moment, in dem der Security-Patch öffentlich wird, genauso verwundbar ist, daher verstehe ich nicht, warum das überhaupt umstritten ist.
  • Organisationen, die Linux nutzen, könnten jeweils mit einem gewissen Aufwand AI einsetzen, um ihre Abhängigkeiten kontinuierlich zu scannen und zu patchen, und ein Vertrauensnetz schaffen, in dem sie Patches und Scan-Ergebnisse untereinander austauschen.

• Tony Hoares alter Ausspruch über „das Fehlen offensichtlicher Bugs“ und „offensichtlich frei von Bugs“ passt im Zeitalter der LLMs mehr denn je.

• Mir persönlich erscheint die Erklärung, Bugs einfach als Bugs zu behandeln, ziemlich unsinnig, aber ich weiß, dass es in der Linux-Welt viele Menschen gibt, die Prinzipien höher gewichten als praktische Probleme.
  Trotzdem wirken 90 Tage lang.
  Letztlich werden die großen AI-Unternehmen wohl den Menschen helfen müssen, die sich um die Kerninfrastruktur des Internets kümmern. Die modernste und beste AI auf Dinge wie nginx anzusetzen, wäre aus meiner Sicht ein kollektiver Vorteil für uns alle.

• Die Passage „Zum Glück kann AI hier Verteidiger genauso beschleunigen wie Angreifer und damit sogar Offenlegungsfristen praktikabel machen, die früher so kurz gewesen wären, dass sie nutzlos gewesen wären“ ist ein wichtiger Aspekt dieses Problemraums.
  Das Sicherheitsrisiko könnte letztlich zu einem Wettrüsten darum werden, wer mehr Token-Kosten ausgeben kann.

  • Interessant ist dabei, dass Closed-Source-Code dadurch für Verteidiger zu einem noch wertvolleren Gut wird.
    Angreifer können dafür keine Token ausgeben, Verteidiger aber schon, um auf Basis des Source Codes Härtungsmaßnahmen durchzuführen. Angreifer bleiben auf Black-Box-Tests beschränkt.