Daniel Stenberg, auteur van een hulpprogramma voor het ontvangen en verzenden van gegevens via de netwerkkrul, bekritiseerde het gebruik van AI-tools bij het maken van kwetsbaarheidsrapporten. Dergelijke rapporten bevatten gedetailleerde informatie, zijn geschreven in normale taal en zien er kwalitatief hoogstaand uit, maar zonder doordachte analyse kunnen ze in werkelijkheid alleen maar misleidend zijn en echte problemen vervangen door kwalitatief hoogwaardige inhoud.
Het Curl-project betaalt beloningen voor het identificeren van nieuwe kwetsbaarheden en heeft al 415 meldingen van potentiële problemen ontvangen, waarvan er slechts 64 werden bevestigd als kwetsbaarheden en 77 als niet-beveiligingsbugs. Zo bevatte 66% van alle rapporten geen enkele nuttige informatie en kostte het de ontwikkelaars alleen maar tijd die aan iets nuttigs had kunnen worden besteed.
Ontwikkelaars worden gedwongen veel tijd te verspillen aan het ontleden van nutteloze rapporten en het meerdere keren dubbel controleren van de informatie die daarin staat, omdat de externe kwaliteit van het ontwerp extra vertrouwen in de informatie schept en het gevoel bestaat dat de ontwikkelaar iets verkeerd heeft begrepen. Aan de andere kant vereist het genereren van een dergelijk rapport minimale inspanning van de aanvrager, die niet de moeite neemt om te controleren op een echt probleem, maar eenvoudigweg blindelings de gegevens kopieert die zijn ontvangen van AI-assistenten, in de hoop op geluk in de strijd om een beloning te ontvangen.
Er worden twee voorbeelden gegeven van dergelijke afvalrapporten. De dag vóór de geplande openbaarmaking van informatie over de gevaarlijke October-kwetsbaarheid (CVE-2023-38545) werd via Hackerone een melding verzonden dat de patch met de fix publiekelijk beschikbaar was gekomen. In feite bevatte het rapport een mengeling van feiten over soortgelijke problemen en fragmenten van gedetailleerde informatie over kwetsbaarheden uit het verleden, samengesteld door Google's AI-assistent Bard. Hierdoor zag de informatie er nieuw en relevant uit en had geen enkele relatie met de werkelijkheid.
Het tweede voorbeeld betreft een op 28 december ontvangen bericht over een bufferoverflow in de WebSocket-handler, verzonden door een gebruiker die via Hackerone al diverse projecten op de hoogte had gesteld van kwetsbaarheden. Als methode om het probleem te reproduceren, bevatte het rapport algemene woorden over het doorgeven van een aangepast verzoek met een waarde groter dan de grootte van de buffer die werd gebruikt bij het kopiëren met strcpy. Het rapport gaf ook een voorbeeld van een correctie (een voorbeeld van het vervangen van strcpy door strncpy) en vermeldde een link naar de coderegel “strcpy(keyval, randstr)”, die volgens verzoekster een fout bevatte.
De ontwikkelaar controleerde alles drie keer en vond geen problemen, maar omdat het rapport zelfverzekerd was geschreven en zelfs een correctie bevatte, had je het gevoel dat er ergens iets ontbrak. Een poging om te verduidelijken hoe de onderzoeker erin slaagde de expliciete groottecontrole te omzeilen die aanwezig was vóór de strcpy-aanroep en hoe de grootte van de keyval-buffer kleiner bleek te zijn dan de grootte van de gelezen gegevens, leidde tot gedetailleerde, maar geen aanvullende informatie, verklaringen dat alleen kauwde op de voor de hand liggende veelvoorkomende oorzaken van bufferoverflow die geen verband hielden met specifieke Curl-code. De antwoorden deden denken aan communicatie met een AI-assistent, en na een halve dag zinloze pogingen te hebben gedaan om erachter te komen hoe het probleem zich precies manifesteert, was de ontwikkelaar er uiteindelijk van overtuigd dat er feitelijk geen sprake was van een kwetsbaarheid.
Bron: opennet.ru