Firma Anthropic ogłosiła rozszerzenie możliwości w modelach AI Claude Opus 4.6 dotyczących wykrywania podatności w kodzie i podzieliła się wynikami eksperymentu, w którym zidentyfikowano ponad 500 wcześniej nieznanych (0-day) podatności w najnowszych wersjach różnych otwartych projektów. Prace skoncentrowano na wyszukiwaniu podatności spowodowanych problemami z pamięcią, ponieważ łatwiej je zweryfikować. Wszystkim wykrytym podatnościom przypisano wysoki poziom zagrożenia. Każda podatność została ręcznie zweryfikowana i potwierdzona przez pracowników Anthropic lub współpracujących zewnętrznych badaczy bezpieczeństwa.
Do analizy podatności wykorzystano bazy kodu popularnych otwartych projektów, które od dłuższego czasu są poddawane ciągłemu testowaniu fuzzingowemu w serwisie OSS-Fuzz. W przeciwieństwie do testowania fuzzingowego, podczas którego generowany jest strumień wszelkich możliwych losowych kombinacji danych wejściowych, model AI próbował analizować kod, uwzględniając wcześniejsze poprawki w celu identyfikacji podobnych nieusuniętych błędów, wyodrębniając problematyczne wzorce i logicznie wnioskować, jakie dane wejściowe mogą zakłócić przebieg wykonania.
Informacje o wykrytych podczas eksperymentu podatnościach zostały już przekazane zespołom wsparcia, z którymi prowadzona jest wspólna praca nad wprowadzeniem poprawek. Aby pomóc zespołom wsparcia podczas przeprowadzonej weryfikacji, ręcznie opracowano łatki do naprawy wykrytych problemów. Jako przykład podano trzy podatności w GhostScript, OpenSC i CGIF, które na moment publikacji zostały usunięte przez zespoły wsparcia.
Używana do wykrywania problemów konfiguracja różniła się od tradycyjnych systemów automatycznego wyszukiwania podatności — modelowi Claude Opus 4.6 zapewniono dostęp do maszynie wirtualnej, w którym oprócz badane kodu zainstalowano standardowe narzędzia programistyczne (coreutils, Python itp.) oraz narzędzia do debugowania i analizy podatności (w tym narzędzia do testowania fuzzingowego). Modelowi nie przekazano jasnych instrukcji dotyczących korzystania z tych narzędzi ani nie dostarczono specjalnych informacji na temat metod wykrywania podatności. Modelowi postawiono jedynie zadanie i udzielono możliwości samodzielnego rozważania optymalnego wykorzystania dostępnych narzędzi.
W poszukiwaniu luk w GhostScript model AI na początku spróbował przeprowadzić testy fuzzingowe, ale gdy to nie przyniosło rezultatu, przeszedł do analizy kodu. Analiza kodu również nie przyniosła efektu, więc model zaczął badać historię zmian w git i w jednym z commitów zauważył wzmiankę o sprawdzaniu granic bufora. Zrozumiawszy commit, model stwierdził, że poprawka dodawała brakujące sprawdzenie granic bufora przy obsłudze czcionek.
Następnie model zidentyfikował kod sprzed poprawki i spróbował znaleźć w pozostałym kodzie podobne wzorce użycia problematycznej funkcji, które pozostały nieskorygowane. Ostatecznie w pliku gdevpsfx.c zidentyfikowano wywołanie funkcji gs_type1_blend bez sprawdzenia poprawności wartości. W końcowym etapie model dobrał zawartość pliku, której przetwarzanie prowadziło do awaryjnego zakończenia z powodu zapisu danych w obszarze pamięci poza przydzielonym buforem.
W CGIF model AI opierał się na tym, że podczas dekompresji plików GIF biblioteka zakładała, że rozmiar skompresowanych danych jest zawsze mniejszy od dekompresowanych. Poszukiwanie luk koncentrowało się na określeniu warunków, w których dane skompresowane algorytmem LZW mogłyby być większe od dekompresowanych. Takie warunki zostały znalezione, a model AI był w stanie utworzyć plik GIT, którego przetwarzanie prowadziło do przekroczenia bufora. W OpenSC problem został zidentyfikowany po analizie użycia w kodzie potencjalnie niebezpiecznych funkcji strrchr i strcat.
Zauważono, że modele językowe osiągnęły poziom, który pozwala na wykrywanie wcześniej nieznanych luk, i w najbliższym czasie przewyższą ekspertów ds. bezpieczeństwa pod względem szybkości i skali wyszukiwania luk. Zakłada się, że wzrost liczby ujawnianych luk wymusi reformę istniejących procesów ujawniania informacji, ponieważ obecnie przeznaczane 90 dni na poprawki będzie niewystarczające.
Źródło: opennet.ru
