Chris Rohlf vom Frontier Red Team hat am 20. Oktober Zahlen aus einem Versuch veröffentlicht, der eine andere Frage stellt als die üblichen Sicherheitsarbeiten. Nicht: Welche Lücke steckt im Code? Sondern: Welcher Code ist überhaupt erreichbar, und muss er das sein?
Angriffsfläche verkleinern statt Lücken zählen
Die Begründung ist unbequem und richtig. Eine einzelne Lücke zu schließen sagt nichts über die restlichen aus. Wenn du dagegen die Erreichbarkeit von Code senkst, sinkt der Schweregrad auch der Lücken, die du noch nicht kennst – einschließlich derer, die gerade ausgenutzt werden. Die Fehler sind weiter drin, aber schwerer zu erreichen.
Drei Methoden hat das Team an Claude gegeben: Code, der in der Standardkonfiguration erreichbar ist, ohne von einer Standardfunktion gebraucht zu werden. Paare von Optionen, die einzeln vernünftig aussehen und zusammen etwas kaputt machen. Und sicherheitsrelevanter Code, der vor der Authentifizierung oder vor einem Protokollübergang läuft.
Was dabei herauskam
25 Projekte, über fünf Millionen Zeilen, C, C++, Java, PHP und Python. Claude hat einen Bestand von über 17.000 Konfigurationsoptionen aufgenommen, davon 3.842 sicherheitsrelevant, und 493 Probleme gemeldet.
Die Projekte sind in drei Gruppen eingeteilt: öffentlich, gated (erst nach Authentifizierung nutzbar) und privat. Bei allen elf Gated-Projekten fand Claude unbeabsichtigt erreichbaren Code: 93 unnötige Pre-Auth-Flächen in der Standardkonfiguration, 37 Stellen, an denen vor der Authentifizierung Code lief oder Zustand geschrieben wurde, und 61 Konfigurationskombinationen, die eine vom Administrator gesetzte Pre-Auth-Kontrolle still schwächen.
Die interessanteste Kategorie sind die Wechselwirkungen: 162 sicherheitsrelevante Kombinationen, die ohne Fehler, ohne Warnung und ohne Dokumentation akzeptiert werden. In 94 Fällen schaltet die Kombination eine Sicherheitskontrolle still ab.
Das Muster, das viermal unabhängig auftrat
Ein Administrator schreibt eine Zugriffsregel für entfernte Clients mit Hostnamen oder Wildcard statt mit IP-Adresse. Verbindet sich ein Client, vergleicht der Server die Regel mit dessen Hostnamen – sofern er ihn kennt, was von einer separaten Option für Reverse-DNS abhängt. Die stand in den meisten Projekten auf aus.
Dann hat der Server nur die IP und vergleicht die Regel als Text dagegen. Ein Hostname-Muster passt niemals auf eine IP. Die Deny-Regel feuert nie, die Liste fällt offen. Manche Projekte erwähnen in ihrer Doku, dass Hostname-Regeln DNS-Lookups brauchen. Keines schreibt, dass eine so geschriebene Deny-Liste dann durchlässig ist.
Dieser Befund ist langweiliger als ein Exploit, und deshalb mehr wert
In derselben Woche findet KI eine RCE-Lücke in PHP, die 70 Prozent aller Websites betrifft. Das ist die Geschichte, die alle lesen. Diese hier ist die, die mehr Server rettet.
Denn das Problem der Verteidigung ist nicht, dass ihr Lücken fehlen, die sie schließen könnte. Es ist, dass sie nach jeder geschlossenen Lücke genauso wenig weiß wie vorher. Eine Konfiguration, die eine Kontrolle still abschaltet, steht in keiner CVE-Datenbank, kostet aber genau dann, wenn die nächste CVE kommt. 94 solcher Fälle in 25 Projekten ist keine Forschungsnotiz, das ist eine Hausaufgabenliste.