Daniel Stenberg, autore dell'utilità per l'invio e la ricezione di dati in rete curl, ha criticato l'uso di strumenti AI nella creazione di rapporti sulle vulnerabilità. Tali rapporti, sebbene contengano dettagli ben scritti e sembrino di alta qualità, possono fuorviare senza un'analisi approfondita, sostituendo problemi reali con contenuti apparentemente validi ma in realtà privi di valore.
Il progetto Curl offre ricompense per la segnalazione di nuove vulnerabilità e ha già ricevuto 415 rapporti su potenziali problemi, di cui solo 64 sono stati confermati come vulnerabilità e 77 come errori non legati alla sicurezza. Pertanto, il 66% di tutti i rapporti non conteneva informazioni utili, sottraendo tempo agli sviluppatori che avrebbe potuto essere impiegato in attività produttive.
Gli sviluppatori sono costretti a perdere molto tempo a esaminare rapporti inutili e a verificare le informazioni indicate più volte, poiché la qualità esterna della presentazione crea una fiducia aggiuntiva verso le informazioni, dando l'impressione che lo sviluppatore non abbia compreso appieno la situazione. D'altra parte, la creazione di un tale rapporto richiede il minimo sforzo da parte del richiedente, che non si preoccupa di verificare l'esistenza di un reale problema, ma copia semplicemente dati ottenuti dagli assistenti AI, sperando di avere fortuna nella lotta per ottenere una ricompensa.
Vengono forniti due esempi di questi rapporti spazzatura. Un giorno prima della divulgazione programmata delle informazioni sulla pericolosa vulnerabilità di ottobre (CVE-2023-38545), è stato inviato tramite Hackerone un rapporto secondo cui la patch correttiva era stata resa pubblica. In realtà, il rapporto conteneva una miscela di fatti su problemi simili e estratti dettagliati di vulnerabilità passate, assemblata dall'assistente AI Google Bard. Di conseguenza, le informazioni apparivano nuove e attuali, senza alcun legame con la realtà.
Il secondo esempio riguarda un messaggio ricevuto il 28 dicembre relativo a un overflow del buffer nel gestore WebSocket, inviato da un utente che aveva già segnalato vulnerabilità a vari progetti tramite Hackerone. Come metodo per riprodurre il problema, il rapporto menzionava parole generali sulla trasmissione di una richiesta modificata con un valore superiore alla dimensione del buffer utilizzato durante la copia con strcpy. Il rapporto includeva anche un esempio di correzione (sostituzione di strcpy con strncpy) e indicava il riferimento alla riga di codice «strcpy(keyval, randstr)», in cui, secondo l’autore della segnalazione, si trovava un errore.
Lo sviluppatore ha controllato tutto tre volte senza trovare problemi, ma poiché il rapporto era redatto con convinzione e includeva anche una correzione, è sorto il sospetto che qualcosa potesse essere trascurato. L'interrogativo su come il ricercatore fosse riuscito a eludere 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 ha portato a ricevere spiegazioni dettagliate, ma prive di informazioni aggiuntive, che si limitavano a ripetere ovvie cause generali di overflow del buffer non direttamente collegate al codice di Curl. Le risposte ricordavano un'interazione con un assistente AI e, dopo aver speso mezza giornata in tentativi infruttuosi di scoprire come si manifestasse il problema, lo sviluppatore si è convinto definitivamente che non ci fosse alcuna vulnerabilità reale.
Fonte: opennet.ru
