Daniel Stenberg, autor da ferramenta para enviar e receber dados pela rede curl, criticou o uso de ferramentas de IA na criação de relatórios sobre vulnerabilidades. Esses relatórios incluem detalhes escritos de forma clara e são visualmente atraentes, mas sem uma análise cuidadosa podem enganar, substituindo problemas reais por conteúdo com aparência qualitativa que não oferece valor.
O projeto Curl recompensa a identificação de novas vulnerabilidades e já recebeu 415 relatórios sobre problemas potenciais, dos quais apenas 64 foram confirmados como vulnerabilidades, e 77 como erros não relacionados à segurança. Assim, 66% de todos os relatórios não continham informações úteis e apenas desperdiçaram o tempo dos desenvolvedores, que poderia ser utilizado em algo mais produtivo.
Os desenvolvedores são forçados a gastar muito tempo analisando relatórios inúteis e revisando as informações várias vezes, pois a qualidade externa da formatação confere uma confiança adicional à informação, criando a impressão de que o desenvolvedor não entendeu algo. Por outro lado, a elaboração desse tipo de relatório exige esforços mínimos do solicitante, que não se preocupa em verificar a existência de um problema real e simplesmente copia dados gerados por assistentes de IA, esperando ter sorte na busca por recompensas.
São apresentados dois exemplos desses relatórios inúteis. Um dia antes do anúncio planejado sobre uma vulnerabilidade crítica de outubro (CVE-2023-38545), um relatório foi enviado pelo Hackerone afirmando que o patch de correção havia sido tornado público. De fato, o relatório continha uma mistura, criada pelo assistente de IA Google Bard, de fatos sobre problemas semelhantes e trechos de detalhes sobre vulnerabilidades passadas. Como resultado, a informação parecia nova e relevante, mas não tinha ligação com a realidade.
O segundo exemplo aborda a mensagem sobre o estouro de buffer recebida em 28 de dezembro no manipulador WebSocket, enviada por um usuário que já havia informado sobre vulnerabilidades em diversos projetos através do Hackerone. Como método de reprodução do problema, o relatório mencionava palavras gerais sobre o envio de uma solicitação modificada com um valor que excedia o tamanho do buffer utilizado ao copiar com a função strcpy. O relatório também apresentava um exemplo de correção (substituindo strcpy por strncpy) e fornecia um link para a linha de código "strcpy(keyval, randstr)", na qual, segundo o reclamante, havia um erro.
O desenvolvedor conferiu tudo três vezes e não encontrou nenhum problema, mas como o relatório foi escrito de forma convincente e até continha uma correção, havia a impressão de que algo estava sendo ignorado. A tentativa de esclarecer como o pesquisador conseguiu contornar a verificação explícita de tamanho antes da chamada da função strcpy e como o tamanho do buffer keyval era menor que o tamanho dos dados lidos, levou a explicações detalhadas, mas sem informações adicionais, que apenas discutiam as causas gerais do estouro de buffer, não relacionadas ao código específico do Curl. As respostas lembravam uma interação com um assistente de IA e, após passar meio dia em tentativas inúteis de descobrir como exatamente o problema se manifestava, o desenvolvedor ficou convencido de que não havia de fato nenhuma vulnerabilidade.
Fonte: opennet.ru
