Daniel Stenberg, autore dello strumento curl per l'invio e la ricezione di dati in rete, ha criticato l'uso di strumenti AI nella creazione di report sulle vulnerabilità. Tali report includono dettagli, scritti in linguaggio chiaro, e sembrano di buona qualità, ma senza un'analisi approfondita possono semplicemente fuorviare, sostituendo problemi reali con contenuti spazzatura che sembrano di qualità.
Il progetto Curl offre ricompense per la scoperta di nuove vulnerabilità e ha già ricevuto 415 report su potenziali problemi, di cui solo 64 sono stati confermati come vulnerabilità, mentre 77 sono stati classificati come errori non relativi alla sicurezza. Così, il 66% di tutti i report non ha fornito informazioni utili e ha solo sottratto tempo agli sviluppatori, che avrebbero potuto impiegare in attività più produttive.
Gli sviluppatori sono costretti a perdere molto tempo nell'analizzare report inutili e a verificare le informazioni fornite più volte, poiché la qualità apparente dei report genera una fiducia aggiuntiva nelle informazioni e porta a pensare che lo sviluppatore non abbia capito qualcosa. D'altra parte, la creazione di un simile report richiede sforzi minimi da parte del richiedente, che non si preoccupa di verificare l'esistenza di un problema reale, ma copia ciecamente i dati ottenuti dai assistenti AI, sperando in un colpo di fortuna nella lotta per ottenere una ricompensa.
Vengono forniti due esempi di tali report spazzatura. Il giorno prima della divulgazione programmata dei dettagli su una pericolosa vulnerabilità di ottobre (CVE-2023-38545), tramite Hackerone è stato inviato un report riguardante un patch correttivo reso pubblico. In realtà, il report conteneva una miscela creata dall'assistente AI Google Bard di fatti su problemi simili e stralci di dettagli riguardanti vulnerabilità passate. Alla fine, le informazioni sembravano nuove e aggiornate, ma non avevano alcun legame con la realtà.
Il secondo esempio riguarda il messaggio ricevuto il 28 dicembre riguardante l'overflow del buffer nel gestore WebSocket, inviato da un utente che aveva già informato diversi progetti su Hackerone riguardo alle vulnerabilità. Come metodo per riprodurre il problema, il rapporto menzionava parole generali sulla trasmissione di una richiesta modificata con un valore di dimensione superiore a quella del buffer utilizzato durante la copia con strcpy. Il rapporto includeva anche un esempio di correzione (sostituire strcpy con strncpy) e forniva un riferimento alla riga di codice "strcpy(keyval, randstr)", in cui il richiedente sosteneva ci fosse un errore.
Lo sviluppatore ha controllato tutto tre volte e non ha trovato alcun problema, ma poiché il rapporto era scritto in modo convincente e conteneva persino una correzione, c'era la sensazione che qualcosa fosse trascurato. Cercare di chiarire come lricercatore fosse riuscito ad aggirare il controllo esplicito della dimensione prima della chiamata a strcpy e come la dimensione del buffer keyval fosse risultata inferiore alla dimensione dei dati letti portò a ricevere spiegazioni dettagliate ma senza informazioni aggiuntive, che ripetevano solo le ovvie cause generali dell'overflow del buffer, non correlate al codice specifico di Curl. Le risposte ricordavano una conversazione con un assistente AI e, dopo aver speso mezza giornata in tentativi inutili di scoprire come si manifestasse realmente il problema, lo sviluppatore si convinse definitivamente che non ci fosse alcuna vulnerabilità in realtà.
Fonte: opennet.ru
