Daniel Stenberg, autor d'una utilitat per rebre i enviar dades a través de la xarxa curl, va criticar l'ús d'eines d'IA a l'hora de crear informes de vulnerabilitat. Aquests informes inclouen informació detallada, estan escrits en llenguatge normal i semblen de gran qualitat, però sense una anàlisi reflexiva en realitat només poden induir a error, substituint els problemes reals per contingut d'escombraries de qualitat.
El projecte Curl paga recompenses per identificar noves vulnerabilitats i ja ha rebut 415 informes de problemes potencials, dels quals només 64 es van confirmar com a vulnerabilitats i 77 com a errors no de seguretat. Així, el 66% de tots els informes no contenien cap informació útil i només va treure temps als desenvolupadors que es podria haver gastat en alguna cosa útil.
Els desenvolupadors es veuen obligats a perdre molt de temps analitzant informes inútils i revisant la informació que hi conté diverses vegades, ja que la qualitat externa del disseny crea més confiança en la informació i hi ha la sensació que el desenvolupador ha entès malament alguna cosa. D'altra banda, generar un informe d'aquest tipus requereix un esforç mínim per part del sol·licitant, que no es molesta en comprovar si hi ha un problema real, sinó que simplement copia a cegues les dades rebudes dels assistents d'IA, amb l'esperança de tenir sort en la lluita per rebre una recompensa.
Es donen dos exemples d'aquests informes d'escombraries. El dia abans de la divulgació prevista d'informació sobre la perillosa vulnerabilitat d'octubre (CVE-2023-38545), es va enviar un informe a través de Hackerone que el pegat amb la correcció havia quedat disponible públicament. De fet, l'informe contenia una barreja de fets sobre problemes similars i fragments d'informació detallada sobre vulnerabilitats anteriors compilats per l'assistent d'IA de Google, Bard. Com a resultat, la informació semblava nova i rellevant, i no tenia cap connexió amb la realitat.
El segon exemple es refereix a un missatge rebut el 28 de desembre sobre un desbordament de memòria intermèdia al gestor de WebSocket, enviat per un usuari que ja havia informat diversos projectes sobre vulnerabilitats mitjançant Hackerone. Com a mètode per reproduir el problema, l'informe incloïa paraules generals sobre passar una sol·licitud modificada amb un valor més gran que la mida de la memòria intermèdia utilitzada quan es copiava amb strcpy. L'informe també proporcionava un exemple de correcció (un exemple de substitució de strcpy per strncpy) i indicava un enllaç a la línia de codi "strcpy(keyval, randstr)", que, segons el sol·licitant, contenia un error.
El desenvolupador ho va comprovar tot tres vegades i no va trobar cap problema, però com que l'informe es va escriure amb confiança i fins i tot contenia una correcció, hi havia la sensació que faltava alguna cosa en algun lloc. Un intent d'aclarir com l'investigador va aconseguir eludir la comprovació de mida explícita present abans de la trucada strcpy i com la mida de la memòria intermèdia de claus va resultar ser inferior a la mida de les dades llegides va portar a explicacions detallades, però sense portar informació addicional. que només va mastegar les causes comunes òbvies del desbordament del buffer no relacionades amb el codi Curl específic. Les respostes eren una reminiscència de comunicar-se amb un assistent d'IA i, després de passar mig dia en intents inútils per esbrinar exactament com es manifesta el problema, el desenvolupador finalment es va convèncer que en realitat no hi havia cap vulnerabilitat.
Font: opennet.ru