KI entdeckt 27 Jahre alten OpenBSD-TCP-SACK-Fehler

Ein KI-gesteuertes System zur Schwachstellenerkennung hat einen 27 Jahre alten Fehler im Netzwerkcode des Betriebssystems OpenBSD wieder aufgedeckt und unterstreicht damit die Grenzen der patchbasierten Verteidigung, da künstliche Intelligenz die Geschwindigkeit verändert, mit der Sicherheitslücken gefunden werden. Der Fehler war ein Fehler beim Vergleich von vorzeichenbehafteten Ganzzahlen in OpenBSDs TCP-SACK-Implementierung, die selektive Bestätigungen verarbeitet, einen Mechanismus, der es einem Empfänger ermöglicht, dem Sender mitzuteilen, welche Teile eines Datenstroms bereits angekommen sind, sodass nur fehlende Teile erneut gesendet werden. Niels Provos, ein Computersicherheitsexperte mit einem Doktortitel der University of Michigan und beruflichen Stationen bei Google, Stripe und Lacework, hat den Code ursprünglich im November 1998 beigesteuert. Der Fehler könnte eine NULL-Dereferenzierung auslösen und den Kernel zum Absturz bringen, den Kern eines Betriebssystems, der Hardware und Systemressourcen verwaltet. Am 7. April 2026 deckte der Mythos-KI-Agent von Anthropic den Fehler auf, genau zwölf Jahre nach der öffentlichen Offenlegung von OpenSSL Heartbleed. Provos, der als einer der Gründer von Activ8te schreibt, merkt an, dass die Gruppe denselben Jahrestag mit einem Dance-Pop-Song namens Heartbleed markierte.

Vor dreißig Jahren hing das Finden einer solchen Schwachstelle davon ab, dass eine Person den richtigen Code las. Provos erinnert sich, dass er 1996 den Quellcode von Wietse Venemas TCP Wrappers las, einen Fehler im Zusammenhang mit losen Source-Routing-Optionen bemerkte, einen Angriff baute und ihn später live auf der HIP'97 vorführte. Das Advisory von Secure Networks Inc. folgte im Februar 1997, das Provos über Oliver Friedrichs zugeschrieben wurde, was der erste harte Zeitstempel seiner Schwachstellenforschung war. Heute erledigt ein KI-System dieselbe Arbeit autonom. Mythos lief über den Kernel-Quellcode und deckte den Fehler auf. Provos sagt, er habe das Ergebnis unabhängig mit seinem Open-Source-Framework IronCurtain gegen Opus 4.7, Sonnet 4.6 und Z.AIs Open-Weight-Modell GLM 5.1 reproduziert. Sein vorheriger Beitrag beschreibt die Orchestrierungsmechanik im Detail, aber der Kernpunkt ist, dass Schwachstellenerkennung ein Orchestrierungsproblem ist, kein Problem des Spitzenmodells.

IronCurtain ist Open Source, daher ist die Fähigkeit weder ein Geheimnis des Verteidigers noch des Angreifers. Provos argumentiert, dass die richtige Grundannahme eine Parität der Fähigkeiten ist. Die Disziplin, die die Lücke zur Spitzenfähigkeit schließt, ist ein endlicher Automat, ein Workflow-Controller, der selbst kein großes Sprachmodell ist. Er leitet spezialisierte Agenten durch vorbestimmte Zustände: analysieren, Hypothesen aufstellen, Testumgebung bauen, validieren und priorisieren. Jeder Zustand beginnt mit einem frischen Kontextfenster, das aus einem append-only Journal auf der Festplatte neu aufgebaut wird. Zustände können nur Urteile aus einer festen Menge ausgeben, und begrenzte Schleifen haben Besuchslimits; wenn eine Untersuchung ins Stocken gerät, eskaliert sie an einen Menschen, anstatt einem Modell zu erlauben, die Sitzung mit einem falschen „sieht gut aus“ zu beenden. Der Workflow erfordert keine Spitzengewichte. Das Open-Weight-Modell GLM 5.1, das über Z.AI bereitgestellt wird, trieb die autonome Erkennung in einer grundlegenden Bibliothek ohne manuelle Steuerung voran. Das Modell ist groß und läuft nicht auf einem Laptop, aber jeder, der für einen API-Endpunkt bezahlen oder eine Multi-GPU-Instanz mieten kann, kann es betreiben. Die Kosten pro Audit liegen im Bereich von mehreren zehn bis niedrigen hundert Dollar, niedrig genug, dass jede Abhängigkeit in einem Produktionsstack für Routineprüfungen in Frage kommt.

In den letzten zehn Jahren war die Standardhaltung von Chief Information Security Officers ein Schwachstellenmanagement-Programm, SaaS von Drittanbietern für Posture-Management und Bedrohungserkennung sowie ein Triage-Zyklus, der nie leer wird. Dieses Modell hielt, solange die Rate, mit der Fehler auftauchten, durch die verfügbare menschliche Arbeit begrenzt war, die zum Finden benötigt wurde. KI hat diese Grenze entfernt. Die Erkennung skaliert nun mit API-Guthaben, aber der Patch-Verbrauch nicht. Das Fenster zwischen Offenlegung und Waffeneinsatz schrumpft weiter, während das Fenster zwischen Patch-Verfügbarkeit und Patch-Verbreitung durch nachgelagerte Verbraucher nicht schrumpft. Der zweite Fehlermodus ist strukturell: Schwachstellenmanagement ist von Natur aus reaktiv. Es jagt Fehler, die die Welt bereits entdeckt hat, ohne die Angriffsfläche zu beseitigen oder die Verteidigung in der Tiefe zu stapeln, die den nächsten weniger folgenreich machen würde. Provos sagt, die Einschränkung sei selten die Analyse; es seien Budget, Priorität der Geschäftsleitung und Zugang zu Ingenieuren, die proaktive Kontrollen bauen können. Diese Ingenieure waren knapp und wurden durch die wirtschaftliche Schwerkraft in eine Handvoll großer Technologieunternehmen gelenkt. Ein CISO ohne dieses Talent oder Budget kann einen Anbieter und eine Triage-Warteschlange finanzieren, aber proaktive Arbeit stockt, und wenn ein Vorfall eintritt, ist der CISO die namentlich genannte Person im Postmortem.

Die Antwort, argumentiert Provos, ist nicht, Fehler schneller zu finden, sondern Infrastruktur aufzubauen, die Angriffsklassen vom kritischen Pfad laufender menschlicher Sicherheitsentscheidungen nimmt. Er nennt diese Sicherheitsinvarianten: maschinell durchgesetzte Einschränkungen, die konsistent über eine Infrastruktur angewendet werden und einen oder mehrere Schritte einer Angriffskette behindern, ohne dass eine menschliche Entscheidung pro Vorfall erforderlich ist. Der Fehler kann weiterhin existieren; was sich ändert, ist, ob ein Angreifer die Kette abschließen kann. Fragen Sie nicht, welche Fehler ein Gegner finden wird, sondern was ein Gegner tun kann, nachdem er einen Fehler gefunden hat. In einer begleitenden Analyse öffentlicher Sicherheitsvorfall-Bekanntgaben auf securityblueprints.io fand Provos, dass drei konsistent angewendete maschinell durchgesetzte Invarianten eine Mehrheit der Vorfälle im Datensatz behindert hätten, in der Größenordnung von 65 %.

Hardware-Zwei-Faktor-Authentifizierung ersetzt die Authentifizierung mit gemeinsamem Geheimnis durch den kryptografischen Nachweis des Besitzes eines registrierten Geräts. Sie entfernt Phishing von Anmeldedaten als praktikablen Vektor für den Erstzugriff. Google hat dies intern ab etwa 2010 nach Operation Aurora eingeführt und berichtet von null erfolgreichen Kompromittierungen von Mitarbeiterkonten durch Phishing seitdem. Das Beispiel ist fünfzehn Jahre alt, doch die meisten Unternehmen arbeiten immer noch mit der Authentifizierung über gemeinsame Geheimnisse, weil die Einführung Legacy-Integrationen stört, die auf der Annahme basieren, dass Passwörter ausreichen. Egress-Kontrolle bedeutet, ausgehenden Netzwerkverkehr aus der Produktion standardmäßig zu blockieren. Ein Angreifer, der einen extern erreichbaren Dienst kompromittiert und Codeausführung erlangt, ist normalerweise noch nicht fertig; der bedeutende Schaden folgt der Ankunft einer Second-Stage-Payload und der Einrichtung von Command-and-Control. Egress-Kontrolle entfernt diesen Schritt. Die log4j-Kampagnen vom Dezember 2021 sind das kanonische Beispiel: Jede Erstzugriffs-Ausnutzung, die zählte, beruhte darauf, dass der kompromittierte Host ausgehend Kontakt aufnahm, um eine nächste Stufe zu holen. Eine Produktionsumgebung, die keine beliebigen ausgehenden Aufrufe tätigen kann, macht die gesamte Schwachstellenklasse weniger folgenreich, unabhängig davon, ob der zugrunde liegende log4j-Fehler auf diesem bestimmten Host jemals gepatcht wird. Positive Ausführungskontrolle bedeutet, dass nur auf die Whitelist gesetzte Binärdateien ausgeführt werden dürfen. Social-Engineering-Angriffe, bei denen ein Angreifer als IT-Support auftritt und ein Ziel auffordert, ein Diagnosetool herunterzuladen und auszuführen, werden strukturell unmöglich. Das Zielgerät verweigert die Binärdatei, egal wie überzeugend der Vorwand war. Microsoft hat dieselbe Beobachtung rund um Smart App Control gemacht, und mehrere große Unternehmen haben intern äquivalente Whitelists für Produktionsworkloads aufgebaut. Keine dieser Maßnahmen ist neu oder neuartig, aber sie funktionieren, funktionieren seit über einem Jahrzehnt an den Orten, die sie eingeführt haben, und beseitigen einen erheblichen Anteil der Sicherheitsvorfälle in den öffentlichen Aufzeichnungen.

Stärkere Invarianten existieren unterhalb und oberhalb dieser Ebene. Auf der Hardware-Ebene bietet Memory Tagging zum Zeitpunkt der Zuweisung dem Betriebssystem und der Laufzeitumgebung eine strukturelle Verteidigung gegen Heap-Speichersicherheitsfehler. ARMs Memory Tagging Extension (MTE) ist heute auf Pixel-Geräten verfügbar. Apple hat auf der WWDC Memory Integrity Enforcement für iOS angekündigt. Mit einer MTE-fähigen Plattform und einem tag-bewussten Allokator führen Heap-Overflows, die zuvor stille Korruption verursachten, nun im Moment des Missbrauchs zu einem Fehler. CHERI ist die forschungsreife Erweiterung derselben Idee auf Fähigkeitsebene. Provos schreibt Dino Dai Zovi die Rahmung von Memory Tagging als Invariante und die Beobachtung zu, dass der Hardware-Erneuerungszyklus schneller ablaufen könnte als der Software-Umschreibzyklus: Eine Geräteflotte kann MTE im Zeitrahmen von Telefon-Erneuerungszyklen aufnehmen, während das Umschreiben der weltweiten C- und C++-Codebasis in sicherere Sprachen erheblich länger dauern wird.

Auf der Anwendungs- und Datenebene ist Context-Aware Data Access (CADA) die stärkste Invariante, die gegen Insider-Risiken entwickelt wurde. Der Zugriff auf sensible Daten und Systeme wird entfernt. Jeder Lese- oder Operationsvorgang erfordert eine aktuelle, verifizierbare geschäftliche Rechtfertigung, z. B. ein zugewiesenes Support-Ticket, und ein separates System validiert, dass die Rechtfertigung existiert und aktuell ist. Ein kompromittiertes Operator-Konto oder ein böswilliger Operator kann keine Daten abrufen oder auf Systeme zugreifen, ohne einen realen Grund, den ein anderes System unabhängig prüfen kann. Die konkrete Form sind Support-Anbieter von Drittanbietern. Historisch erhielten diese Anbieter leistungsstarke Tools und breiten Lesezugriff auf eine Kundendatenbank, mit der Theorie, dass sie den Zugriff nur nutzen würden, wenn sie ihn benötigen. CADA beschränkt sie auf den Kundendatensatz, der dem Ticket zugeordnet ist, das ihnen zugewiesen wurde. Sie können nicht stöbern oder pivotieren. Der praktische Effekt ist, dass die Offenlegung durch einen einzelnen kompromittierten Anbieter-Account von der gesamten Kundendatenbank auf einen einzelnen Datensatz zusammenfällt. Die Kosten einer Kompromittierung skalieren nicht mehr mit der Größe des Unternehmens. Der Kompromittierungsfall der administrativen Tools von Twitter im Juli 2020 ist das kanonische Beispiel für den Fehlermodus, den diese Invariante verhindert. Angreifer erlangten durch Social Engineering Zugang zu internen administrativen Tools und nutzten sie, um über 130 prominente Konten für einen Bitcoin-Betrug zu kapern. Der Schadensradius wurde durch den Umfang des Tools selbst bestimmt, das jeden Benutzerdatensatz berühren konnte. Context-Aware Data Access bricht diese Kopplung: Ein Konto mit administrativen Rechten kann nur auf Datensätze zugreifen, die aktuell mit einem gültigen Ticket verknüpft sind, und die Menge solcher Datensätze ist zu jedem Zeitpunkt klein.

Ein großes Hindernis waren immer die Kosten. Das Entwerfen, Bereitstellen und Warten von Invarianten erforderte spezialisierte Ingenieure, die knapp waren und von denselben wenigen großen Unternehmen rekrutiert wurden, die die Kontrollen bereits hatten. Der Anbietermarkt hat die Lücke nicht gefüllt; er verkauft Erkennung, nicht Invarianten. KI verschiebt die Gleichung. Die Bereitstellung von Egress-Kontrolle erforderte früher ein paar leitende Plattform-Sicherheitsingenieure, um die Umgebung zu untersuchen, die Kontrolle zu entwerfen, sie schrittweise einzuführen und abzusichern. Mit der richtigen Spezifikation kann ein einzelner KI-gestützter Ingenieur den Großteil dieser Arbeit erledigen. Provos sagt, er könnte eine solche Spezifikation schreiben, die den Ingenieur von einer Produktionsverkehrsumfrage über die Auswahl des Durchsetzungssubstrats, die Bereitstellung im Überwachungsmodus, die Erstellung von Ausnahmelisten und die schrittweise Verweigerung führt, Phase für Phase. Die Wartung bleibt, aber die Budget- und Talentbarriere, die Invarianten aus den meisten Organisationen fernhielt, ist gefallen.

Am Tag nach dem nächsten Zero-Day, argumentiert Provos, wird nur zählen, ob die Invarianten rechtzeitig gebaut wurden. Die Erkennung ist nicht mehr so eingeschränkt wie vor dreißig Jahren. Derselbe Workflow, der seinen eigenen 27 Jahre alten SACK-Fehler wiederentdeckte, ist Open Source, läuft gegen beliebigen Code und funktioniert ohne Nutzungsbeschränkungen in den Händen eines Gegners. Es gibt kein Gewinnen dieses Rennens durch Patch-Kadenz. Der Weg nach vorne ist, die Fehlerklasse irrelevant zu machen. Schwachstellenmanagement wird fortgesetzt, mit einem Bruchteil des operativen Gewichts, das es heute trägt, während die Infrastruktur die Angriffskette unabhängig vom Patch-Zeitpunkt unterbricht. Provos präsentierte die Aufzeichnung und Folien auf dem Cloud Security Alliance AI Summit, und der Artikel wurde ursprünglich auf Niels' Blog veröffentlicht. Der Tag nach den Zero-Days ist ein Aufruf, Hardware-2FA, Default-Deny-Egress, Whitelist-Ausführung, Memory Tagging auf Hardware-Ebene und kontextbewussten Datenzugriff auf Datenebene aufzubauen. Nichts davon ist neu, aber alles ist für einen einzelnen Ingenieur mit KI im Loop erreichbar. Für Leser, die Websites oder Cloud-Infrastruktur betreiben, beginnt die Anwendung dieser Invarianten oft mit der Überprüfung, welcher ausgehende Verkehr erlaubt ist und welche Binärdateien ausgeführt werden dürfen; ein sicherheitsorientierter IT- und Infrastrukturanbieter wie AEU-I kann bei der Bewertung und Implementierung von Default-Deny-Egress und Whitelist-Ausführung helfen.