Anthropic findet 38.000 Schwachstellen – aber nur 217 sind behoben

Als jemand, der bei einem großen Tech-Unternehmen seit dem Start von Mythos jeden einzelnen Arbeitstag (und viele Wochenenden) damit verbracht hat, ernsthafte, unternehmensbeendende Sicherheitsprobleme zu patchen, regen mich solche Beiträge wirklich auf.

Öffentliche Datensätze von CVEs, die enttäuschend sind, bedeuten nicht viel, wenn all die Probleme in privaten Unternehmenscodebasen liegen, denen nie eine CVE-Nummer zugewiesen wird und die nie einen schicken Blogbeitrag bekommen. Du wirst nie von ihnen hören, und die Leute, die daran arbeiten, können dir wahrscheinlich nicht davon erzählen, aber das heißt nicht, dass es sie nicht gibt.

Wir alle machen uns Sorgen über Sicherheitsprobleme in OSS, weil Dinge wie PHP oder curl so weit verbreitet sind ... aber dasselbe gilt für E-Mail-Anbieter, SaaS für Dokumentenzusammenarbeit, Zahlungsabwickler usw., von denen Millionen von Unternehmen abhängen. Diese Unternehmen werden nie in solchen Datensätzen auftauchen, und sie werden nie öffentlich bekannt geben, wie viele Probleme sie gefunden haben.

Die PHP2Shell-Schwachstelle war für mich paradoxerweise beruhigend.

Sie haben Frontier-Modelle auf PHP losgelassen, und das große Problem, das sie fanden, basierte auf einem bereits bekannten Logikfehler, der extrem schwer auszunutzen war. Was Sinn ergibt: daher die Notwendigkeit von Frontier-Modellen.

Und in freier Wildbahn gab es zwar viele Versuche und ein paar einfache Demo-Erfolge, aber die praktischen Auswirkungen scheinen gering gewesen zu sein, offenbar begrenzt durch die Länge der Kette und die Vielfalt der PHP-Konfigurationen.

Kurz gesagt, es war tatsächlich eine schwerwiegende Schwachstelle, aber keine Magie (im Sinne von Arthur C. Clarke).

Ich denke, letztlich läuft die Angst darauf hinaus: Glaubst du, dass Code abgesichert werden kann? Ich erkenne an, dass es wegen des Halteproblems usw. wahrscheinlich keine objektive Möglichkeit gibt, das deduktiv zu beweisen. Aber wenn man glaubt, dass Code so konstruiert werden kann, dass er spezifikationsgemäß funktioniert, dann muss es eine Grenze für den Schaden geben, den ein LLM anrichten kann, selbst ein sehr kluges.

Ich denke, wir durchlaufen eine Phase, in der viele bekannte, triagierte Codeschwächen aufgedeckt und hoffentlich behoben werden. Das ist währenddessen scheiße. Aber nicht wirklich die erste Runde dieser Art von Evolution. Und letztlich denke ich, dass wir wie zuvor mit sichererer und dauerhafterer Technologie aus der Sache hervorgehen werden.

Der Blog ist irreführend, weil er versucht, die Wirksamkeit von Project Glasswing anhand einer tangential verwandten Datenquelle zu charakterisieren. Eine Schwachstellenentdeckung von Project Glasswing erfolgt meistens, wenn ein Glasswing-Partner ein Modell der Mythos-Klasse auf seine eigene, oft proprietäre Software ansetzt. Die Datenquelle (auch „Ledger“ genannt) gilt nur für das koordinierte Schwachstellenoffenlegungsprogramm von Anthropic für Open-Source-Software: mit anderen Worten, Anthropic selbst setzt ein Modell der Mythos-Klasse auf ein OSS-Paket an und benachrichtigt den Maintainer danach, dass es dies getan hat und Ergebnisse mitzuteilen hat. Diese OSS-Arbeit ist sicherlich nützlich, aber die Anzahl der Fixes spiegelt – teilweise – die begrenzte Zeitverfügbarkeit ehrenamtlicher OSS-Maintainer wider und dass Anthropic manchmal ohne Kenntnis des Bedrohungsmodells des OSS-Projekts arbeitet (das Bedrohungsmodell wird in der neueren oss-scanner-Initiative ausdrücklich angefordert). Der Prozentsatz der behobenen Probleme ist oft viel höher, wenn Glasswing mit proprietärer Software verwendet wird, z. B. https://blog.cloudflare.com/cyber-frontier-models/ „Unsere Forschung mit Mythos Preview wurde in einer kontrollierten Umgebung gegen unseren eigenen Code durchgeführt; jede durch diese Arbeit aufgedeckte Schwachstelle wurde triagiert, validiert und, wo Maßnahmen erforderlich waren, im Rahmen von Cloudflares formalem Schwachstellenmanagementprozess behoben.“

Es gibt eine Anekdote über curl, aber ich bin mir nicht sicher, ob hier genug drin ist, um Schlussfolgerungen zu ziehen. 20 % der Schwachstellen wurden öffentlich gemacht, und viele davon sind als „zurückgezogen“ oder „Duplikate“ markiert. Es ist jedoch unklar, ob die restlichen 80 % nicht öffentlich gemacht wurden, weil sie nicht behoben oder nicht echt sind. Mit anderen Worten, dies ist eine Analyse der Überlebenden (öffentlich); über diejenigen, die noch unter Embargo stehen, lässt sich nicht viel sagen.

> Bisher wurden nur 2 der 442 in freier Wildbahn ausgenutzt, also nur 0,45 %.

> fast keine werden ausgenutzt

Ist es nicht der ganze Sinn von Glasswing, Dinge zu patchen, lange bevor sie ausgenutzt werden können? Wenn der gepatchte Code schnell verteilt wird, gibt es keine Gelegenheit (oder keinen Anreiz) für böswillige Akteure, einen Exploit zu erstellen und zu verbreiten. Das liest sich wie ein Versuch, sie als keine „echten“ Schwachstellen darzustellen.

Es ist schlecht, wenn dies auf ein allgemeines Muster hindeutet, dass KI besser darin ist, Schwachstellen zu finden, als sie zu beheben. Je größer dieses Verhältnis, desto schwieriger ist es, alle Dinge abzusichern. Die aktuelle Statistik aus diesem Experiment ist 37.966 zu 217. Viele Fehlalarme, aber nicht genug, um das Gesamtbild zu ändern. Ich hoffe, sie haben nicht auf beiden Seiten gleich viele Token aufgewendet, sonst ist KI vielleicht besser im Abreißen als im Aufbauen.

Als jemand, der in der Wertschöpfungskette unterhalb des im Beitrag genannten Unternehmens steht, kann ich die Tsunami von KI-generierten Schwachstellenmeldungen bestätigen. Und so sind die menschlichen Maintainer noch dünner besetzt, und die meisten Bugs sind egal.

Das Gute ist der Trend zur Einstufung der Ausnutzbarkeit: Wenn du ein verwundbares Stück Software auf deinem System hast, das aber nicht läuft, ist es nicht kritisch.