Daniel Stenberg, forfatter av et verktøy for mottak og sending av data over nettverkscurl, kritiserte bruken av AI-verktøy når man oppretter sårbarhetsrapporter. Slike rapporter inkluderer detaljert informasjon, er skrevet på normalt språk og ser av høy kvalitet, men uten gjennomtenkt analyse i virkeligheten kan de bare være villedende, og erstatte reelle problemer med søppelinnhold av høy kvalitet.
Curl-prosjektet betaler belønninger for å identifisere nye sårbarheter og har allerede mottatt 415 rapporter om potensielle problemer, hvorav bare 64 ble bekreftet som sårbarheter og 77 som ikke-sikkerhetsfeil. Dermed inneholdt ikke 66 % av alle rapporter noen nyttig informasjon og tok bare tid fra utviklere som kunne vært brukt på noe nyttig.
Utviklere er tvunget til å kaste bort mye tid på å analysere ubrukelige rapporter og dobbeltsjekke informasjonen der flere ganger, siden den eksterne kvaliteten på designet skaper ekstra tillit til informasjonen og det er en følelse av at utvikleren har misforstått noe. På den annen side krever å generere en slik rapport minimal innsats fra søkeren, som ikke gidder å se etter et reelt problem, men ganske enkelt blindt kopierer dataene mottatt fra AI-assistenter, i håp om flaks i kampen for å motta en belønning.
Det er gitt to eksempler på slike søppelmeldinger. Dagen før den planlagte avsløringen av informasjon om den farlige oktobersårbarheten (CVE-2023-38545), ble det sendt en rapport via Hackerone om at oppdateringen med rettelsen var blitt offentlig tilgjengelig. Faktisk inneholdt rapporten en blanding av fakta om lignende problemer og utdrag av detaljert informasjon om tidligere sårbarheter samlet av Googles AI-assistent Bard. Som et resultat så informasjonen ny og relevant ut, og hadde ingen sammenheng med virkeligheten.
Det andre eksemplet gjelder en melding mottatt 28. desember om et bufferoverløp i WebSocket-behandleren, sendt av en bruker som allerede hadde informert ulike prosjekter om sårbarheter gjennom Hackerone. Som en metode for å reprodusere problemet inneholdt rapporten generelle ord om å sende en modifisert forespørsel med en verdi større enn størrelsen på bufferen som ble brukt ved kopiering med strcpy. Rapporten ga også et eksempel på en rettelse (et eksempel på å erstatte strcpy med strncpy) og indikerte en lenke til kodelinjen «strcpy(keyval, randstr)», som ifølge søkeren inneholdt en feil.
Utvikleren dobbeltsjekket alt tre ganger og fant ingen problemer, men siden rapporten ble skrevet trygt og til og med inneholdt en rettelse, var det en følelse av at noe manglet et sted. Et forsøk på å klargjøre hvordan forskeren klarte å omgå den eksplisitte størrelseskontrollen som var tilstede før strcpy-anropet og hvordan størrelsen på nøkkelvalbufferen viste seg å være mindre enn størrelsen på de leste dataene, førte til detaljerte, men uten tilleggsinformasjon, forklaringer som bare tygget på de åpenbare vanlige årsakene til bufferoverløp som ikke er relatert til spesifikk Curl-kode. Svarene minnet om å kommunisere med en AI-assistent, og etter å ha brukt en halv dag på meningsløse forsøk på å finne ut nøyaktig hvordan problemet manifesterer seg, ble utvikleren til slutt overbevist om at det faktisk ikke var noen sårbarhet.
Kilde: opennet.ru