Daniel Stenberg, autor dunha utilidade para recibir e enviar datos a través do curl da rede, criticou o uso de ferramentas de IA á hora de crear informes de vulnerabilidade. Estes informes inclúen información detallada, están escritos en linguaxe normal e teñen un aspecto de alta calidade, pero sen unha análise reflexiva en realidade só poden ser enganosos, substituíndo os problemas reais por contido de lixo de calidade.
O proxecto Curl paga recompensas por identificar novas vulnerabilidades e xa recibiu 415 informes de posibles problemas, dos cales só 64 foron confirmados como vulnerabilidades e 77 como erros non relacionados coa seguridade. Así, o 66% de todos os informes non contiñan información útil e só lles quitou tempo aos desenvolvedores que se puidese dedicar a algo útil.
Os desenvolvedores vense obrigados a perder moito tempo analizando informes inútiles e revisando varias veces a información alí contida, xa que a calidade externa do deseño crea unha confianza adicional na información e hai a sensación de que o desenvolvedor entendeu algo mal. Por outra banda, xerar un informe deste tipo require un esforzo mínimo por parte do solicitante, que non se molesta en comprobar un problema real, senón que simplemente copia cegamente os datos recibidos dos asistentes de IA, esperando que teña sorte na loita para recibir unha recompensa.
Déronse dous exemplos deste tipo de informes de lixo. O día antes da divulgación prevista de información sobre a perigosa vulnerabilidade de outubro (CVE-2023-38545), a través de Hackerone enviouse un informe de que o parche coa corrección estaba a disposición do público. De feito, o informe contiña unha mestura de feitos sobre problemas similares e fragmentos de información detallada sobre vulnerabilidades pasadas compilados polo asistente de intelixencia artificial de Google, Bard. Como resultado, a información parecía nova e relevante, e non tiña conexión coa realidade.
O segundo exemplo refírese a unha mensaxe recibida o 28 de decembro sobre un desbordamento do búfer no manejador de WebSocket, enviada por un usuario que xa informara a varios proxectos sobre vulnerabilidades a través de Hackerone. Como método para reproducir o problema, o informe incluía palabras xerais sobre pasar unha solicitude modificada cun valor maior que o tamaño do búfer utilizado ao copiar con strcpy. O informe tamén ofrecía un exemplo de corrección (un exemplo de substitución de strcpy por strncpy) e indicaba unha ligazón á liña de código "strcpy(keyval, randstr)", que, segundo o solicitante, contiña un erro.
O programador comprobou todo tres veces e non atopou ningún problema, pero dado que o informe foi escrito con confianza e incluso contiña unha corrección, había a sensación de que faltaba algo nalgún lugar. Un intento de aclarar como o investigador conseguiu evitar a comprobación explícita de tamaño presente antes da chamada strcpy e como o tamaño do búfer de keyval resultou ser menor que o tamaño dos datos lidos levou a explicacións detalladas, pero sen levar información adicional. que só mastigou as causas comúns obvias do desbordamento do buffer non relacionadas co código Curl específico. As respostas lembraban a comunicación cun asistente de intelixencia artificial e, despois de pasar medio día en intentos inútiles para descubrir exactamente como se manifesta o problema, o desenvolvedor finalmente convenceu de que en realidade non había ningunha vulnerabilidade.
Fonte: opennet.ru