Virksomheden Anthropic har annonceret, at AI-modellen Claude Opus 4.6 har fået udvidede funktioner til at finde sårbarheder i kode, og de har delt resultaterne af et eksperiment, hvor mere end 500 tidligere ukendte (0-dages) sårbarheder blev identificeret i de nyeste versioner af forskellige open source-projekter. Arbejdet har været fokuseret på at finde sårbarheder forårsaget af problemer med hukommelsen, da disse er lettere at verificere. Alle identificerede sårbarheder er blevet tildelt en høj fareklasse. Hver sårbarhed blev manuelt undersøgt og bekræftet af medarbejdere fra Anthropic eller eksterne sikkerhedsforskere.
Til analysen af sårbarhederne blev kildekoderne fra populære open source-projekter, der i længere tid har været under kontinuerlig fuzzing-testning i tjenesten OSS-Fuzz, inddraget. I modsætning til fuzzing-testning, hvor der genereres en strøm af forskellige tilfældige kombinationer af inputdata, forsøgte AI-modellen at analysere koden under hensyntagen til tidligere rettelser for at identificere lignende uoprettede fejl, fremhæve problematiske mønstre og logisk udlede, hvilke inputdata der kan forstyrre udførelsen.
Informationen om de sårbarheder, der blev identificeret under eksperimentet, er allerede begyndt at blive videregivet til de vedligeholdere, som der arbejdes sammen med for at implementere rettelser. For at hjælpe de vedligeholdere, under den gennemførte kontrol, er der manuelt blevet udviklet patches til at rette de identificerede problemer. Som eksempel er tre sårbarheder i GhostScript, OpenSC og CGIF nævnt, som på tidspunktet for publiceringen er blevet løst af vedligeholderne.
Den konfiguration, der blev brugt til at identificere problemer, adskilte sig fra traditionelle automatiske sårbarhedssøgningssystemer — modellen Claude Opus 4.6 fik adgang til virtuelle maskiner, hvor der udover den undersøgte kode var installeret standard udviklingsværktøjer (coreutils, Python osv.) og værktøjer til fejlfinding og sårbarhedsanalyse (herunder værktøjer til fuzzing-testning). Modellen fik ikke klare instruktioner til brug af disse værktøjer og fik ikke specifik information om metoder til at finde sårbarheder. Modellen fik kun en opgave og mulighed for selv at ræsonnere om den optimale anvendelse af de tilgængelige værktøjer.
I søgen efter sårbarheder i GhostScript forsøgte AI-modellen først at udføre fuzzing-test, men da dette ikke gav resultater, skiftede den til kodeanalyse. Kodeanalysen gav heller ikke resultater, og modellen begyndte at studere ændringshistorikken i git og opdagede i et af committene en omtale af grænsekontrol. Ved at analysere committen fastslog modellen, at rettelsen tilføjede en manglende grænsekontrol ved behandling af skrifttyper.
Derefter identificerede modellen koden, der var før rettelsen, og forsøgte at finde lignende brugsmønstre af den problematiske funktion i den resterende kode, der forblev uopdagede. Som følge heraf blev der i filen gdevpsfx.c identificeret et kald til funktionen gs_type1_blend uden validering af parametrenes korrekthed. Til sidst udvalgte modellen indholdet af en fil, hvis behandling førte til en nedbrud på grund af skrivning af data uden for den tildelte buffer.
I CGIF tog AI-modellen udgangspunkt i, at når GIF-filer udpakkes, anses størrelsen af de komprimerede data altid for at være mindre end de udpakkede. Søgningen efter sårbarheden var centreret om at bestemme de betingelser, under hvilke de komprimerede data fra LZW-algoritmen ville blive større end de udpakkede. Sådanne betingelser blev fundet, og AI-modellen var i stand til at skabe en GIT-fil, hvis behandling førte til buffer-overløb. I OpenSC blev problemet afsløret efter analyse af brugen af potentielt farlige funktioner som strrchr og strcat.
Det bemærkes, at sprogmodeller har nået et niveau, hvor de kan identificere tidligere ukendte sårbarheder, og inden længe vil de overgå sikkerhedseksperter i hastighed og omfang af sårbarhedssøgning. Det antages, at stigningen i antallet af identificerede sårbarheder vil kræve reformer af de eksisterende processer for offentliggørelse af oplysninger, da de nuværende 90 dage til reparation ikke vil være tilstrækkelige.
Kilde: opennet.ru
