Powierzchnia ataku to części programu, do których można dotrzeć przed sprawdzeniem uprawnień lub uwierzytelnieniem. Anthropic podało, że Claude wskazał 493 problemy z niepotrzebną ekspozycją kodu w 25 projektach open source. Ograniczanie takiej ekspozycji może zmniejszyć ryzyko związane z nieznanymi błędami, jak argumentuje Anthropic. Liczba 493 opisuje wyniki analizy powierzchni ataku, a nie 493 potwierdzone, natychmiast wykorzystywalne podatności. Anthropic zaznaczyło, że wyniki w 11 projektach z grupy Gated nie były same w sobie natychmiast wykorzystywalne.

Co obejmowała analiza Claude’a

Projekty objęte analizą zawierały łącznie ponad 5 mln linii kodu napisanego w C, C++, Javie, PHP i Pythonie. Claude zinwentaryzował ponad 17 tys. opcji konfiguracji, w tym 3842 dotyczące zabezpieczeń. Anthropic podzieliło projekty na 10 publicznych, 11 z ograniczonym dostępem (Gated) i 4 prywatne.

Analiza dotyczyła między innymi tego, jaki kod można osiągnąć przy ustawieniach domyślnych, jak opcje konfiguracji wpływają na siebie oraz czy wrażliwy kod wykonuje się przed kontrolą dostępu. „Osiągalny” oznacza tu, że program może dotrzeć do danego fragmentu kodu, nawet jeśli użytkownik nie przeszedł jeszcze uwierzytelnienia.

Trzy miary dla projektów z ograniczonym dostępem

W 11 projektach Gated Anthropic odnotowało 93 niepotrzebnie dostępne obszary przed uwierzytelnieniem przy domyślnej konfiguracji, 37 miejsc, w których przed uwierzytelnieniem wykonywał się kod lub zapisywał stan, oraz 61 kombinacji ustawień osłabiających zabezpieczenie działające przed uwierzytelnieniem. Są to odrębne kategorie wyników, a nie liczby potwierdzonych exploitów.

Osobno, w całej analizowanej grupie projektów, Anthropic wykryło 162 wrażliwe kombinacje konfiguracji akceptowane bez ostrzeżenia i bez dokumentacji oczekiwanego działania. W 94 przypadkach kombinacja po cichu wyłączała zabezpieczenie; pozostałe 68 wiązało się z innymi niespójnościami. To problemy z tym, jak ustawienia współdziałają, a nie miara liczby udanych ataków.

Co zmieniło się w OpenSSH od wersji 10.4 do 10.6

W analizowanym domyślnym demonie OpenSSH 10.4 nieuwierzytelniony klient mógł dotrzeć do około 4500 linii eksperymentalnego kodu podpisów ML-DSA-44, zanim program sprawdził, czy dany typ klucza jest dozwolony. Algorytm ML-DSA nie był domyślnie włączony. Anthropic oceniło, że te linie stanowiły około 16% kodu OpenSSH dostępnego przed uwierzytelnieniem.

W OpenSSH 10.5 wprowadzono wstępne sprawdzenie konfiguracji przed parsowaniem, czyli analizą struktury danych wejściowych. Późniejsza analiza wykazała jednak kolejne problemy: rozbieżność między reklamowanym algorytmem a typem klucza zapisanym w jego danych oraz sprawdzanie podpisu urzędu certyfikacji w certyfikacie.

Anthropic podało, że poprawki w OpenSSH 10.6 sprawdzają typ zakodowanego klucza i algorytm podpisu urzędu certyfikacji względem skonfigurowanych list dozwolonych, zanim program przejdzie do deserializacji lub weryfikacji podpisu. Deserializacja odtwarza obiekt z zakodowanych danych. Zgłoszona redukcja wynosząca około jednej piątej dotyczy kodu dostępnego wcześniej dla nieuwierzytelnionych klientów w domyślnej kompilacji, a nie całego kodu OpenSSH.

Jak Anthropic opisuje sprawdzanie poprawek i OSS-Scanner

Anthropic podało, że Claude potwierdza wyniki za pomocą śladów dynamicznych, które pokazują, jakie fragmenty programu wykonują się podczas działania. Przy zmianach dotyczących domyślnej konfiguracji zmodyfikowaną kompilację porównuje się z wersją bazową przy użyciu zestawu testów projektu i testów regresyjnych działających w trybie czarnej skrzynki. Zmiany wpływające na konfiguracje niedomyślne trafiają do oceny człowieka.

Anthropic poinformowało również, że pracuje nad integracją wielokrotnego użytku narzędzia analizy powierzchni ataku z OSS-Scanner.