Anthropic berichtet, Claude habe bei der Analyse von 25 Open-Source-Projekten 493 Befunde zur Angriffsfläche gefunden. Die Zahl steht für unnötig erreichbaren Code und problematische Konfigurationen, nicht für 493 einzeln nachgewiesene, sofort ausnutzbare Sicherheitslücken.
Die Angriffsfläche umfasst Code, den ein nicht authentifizierter Nutzer oder ein nicht authentifizierter Client erreichen kann, bevor eine Prüfung wie die Anmeldung greift. Weniger unnötig erreichbarer Code kann Risiken begrenzen, auch wenn dadurch bestehende Fehler nicht automatisch verschwinden.
Was Claude in den Projekten untersuchte
Anthropic ließ Claude nach Code suchen, der unter Standardeinstellungen erreichbar war, nach widersprüchlichen Konfigurationskombinationen und nach sensiblen Funktionen, die vor einer Zugangsschranke ausgeführt wurden. Die 25 Projekte umfassten mehr als fünf Millionen Codezeilen in C, C++, Java, PHP und Python.
Claude erfasste laut Anthropic mehr als 17.000 Konfigurationsoptionen, darunter 3.842 sicherheitsrelevante Einstellungen. Anthropic ordnete die Projekte in drei Gruppen ein: 10 Public, 11 Gated und 4 Private.
Was die einzelnen Befundzahlen aussagen
In den 11 Gated-Projekten meldete Anthropic 93 unnötige Bereiche, die in der Standardkonfiguration vor der Authentifizierung erreichbar waren. Außerdem fand das Unternehmen 37 Stellen, an denen vor der Anmeldung Code ausgeführt oder ein Zustand gespeichert wurde, sowie 61 Konfigurationskombinationen, die eine Schutzmaßnahme vor der Authentifizierung abschwächten. Anthropic zufolge war keiner dieser Befunde für sich genommen sofort ausnutzbar.
Eine weitere Zahl beschreibt einen anderen Befundtyp: Über alle Projekte hinweg identifizierte Anthropic 162 sicherheitsrelevante Konfigurationskombinationen, die ohne Warnung akzeptiert wurden und deren erwartetes Verhalten nicht dokumentiert war. In 94 Fällen wurde dadurch eine Sicherheitskontrolle stillschweigend deaktiviert; 68 weitere Kombinationen führten zu anderen Inkonsistenzen.
Wie sich die OpenSSH-Änderungen entwickelten
Am Beispiel von OpenSSH beschreibt Anthropic, wie unnötige Erreichbarkeit vor der Authentifizierung reduziert wurde. In OpenSSH 10.4 konnte ein nicht authentifizierter Client im Standardaufbau rund 4.500 Zeilen experimentellen ML-DSA-44-Signaturcode erreichen, bevor die Konfiguration geprüft wurde. ML-DSA-44 war dabei standardmäßig nicht aktiviert. Die erreichbaren Zeilen machten laut Anthropic etwa 16 Prozent des OpenSSH-Codes aus, der vor der Authentifizierung ausgeführt werden konnte.
Mit OpenSSH 10.5 wurde zunächst eine Konfigurationsprüfung vor das Parsen verschoben. Bei der anschließenden Analyse fand Anthropic weitere Lücken: Unter anderem konnten sich der angekündigte Algorithmus und der im Schlüssel enthaltene Schlüsseltyp unterscheiden; außerdem blieb ein Pfad zur Prüfung der CA-Signatur von Zertifikaten relevant. Die Maintainer veröffentlichten die abschließenden Änderungen laut Anthropic mit OpenSSH 10.6. Dabei werden die erlaubten Schlüsseltypen und Zertifikats-Signaturalgorithmen geprüft, bevor Schlüssel deserialisiert oder Signaturen verifiziert werden.
Anthropic beziffert den Effekt auf rund ein Fünftel des Codes, den nicht authentifizierte Clients zuvor in einem Standardaufbau erreichen konnten. Gemeint ist dieser zuvor erreichbare Code, nicht ein Fünftel des gesamten OpenSSH-Codes.
Was Anthropic für OSS-Scanner plant
Anthropic arbeitet nach eigener Darstellung daran, die wiederverwendbare Claude-Fähigkeit zur Angriffsflächenanalyse in OSS-Scanner zu integrieren. Für die Analyse nutzt das Verfahren dynamische Programmabläufe. Bei Änderungen an Standardkonfigurationen werden der angepasste Build mit der Ausgangsversion, der Testsuite des jeweiligen Projekts und einer Blackbox-Regressionstestsuite verglichen. Änderungen, die Nicht-Standardkonfigurationen betreffen, bleiben laut Anthropic einer menschlichen Prüfung vorbehalten.