Daniel Stenberg, autor de la herramienta para enviar y recibir datos a través de la red, curl, criticó el uso de herramientas de IA para crear informes sobre vulnerabilidades. Estos informes incluyen detalles elaborados, están escritos en un lenguaje normal y parecen de calidad, pero sin un análisis reflexivo, en realidad pueden ser engañosos, reemplazando problemas reales con contenido basura que parece de calidad.
El proyecto Curl otorga recompensas por la identificación de nuevas vulnerabilidades y ya ha recibido 415 informes sobre problemas potenciales, de los cuales solo 64 han sido confirmados como vulnerabilidades y 77 como errores no relacionados con la seguridad. Así, el 66% de todos los informes no contenían información útil y solo robaron tiempo a los desarrolladores que podría haberse utilizado en algo productivo.
Los desarrolladores se ven obligados a perder mucho tiempo revisando informes inútiles y verificando la información presentada varias veces, ya que la calidad externa de la presentación genera una confianza adicional en la información y la sensación de que el desarrollador no comprende algo. Por otro lado, la elaboración de tales informes requiere un mínimo de esfuerzo por parte del solicitante, quien no se toma la molestia de verificar la existencia de un problema real y simplemente copia ciegamente datos obtenidos de asistentes de IA, con la esperanza de tener suerte en la obtención de una recompensa.
Se presentan dos ejemplos de tales informes basura. Un día antes de la divulgación programada de la peligrosa vulnerabilidad de octubre (CVE-2023-38545), se envió a través de Hackerone un informe que indicaba que el parche de corrección había sido hecho público. En realidad, el informe contenía una mezcla compuesta por el asistente de IA Google Bard, que abarcaba hechos sobre problemas similares y extractos de información detallada sobre vulnerabilidades pasadas. Como resultado, la información parecía nueva y pertinente, aunque no tenía relación con la realidad.
El segundo ejemplo aborda un mensaje de desbordamiento de búfer recibido el 28 de diciembre en el manejador de WebSocket, enviado por un usuario que ya había informado sobre vulnerabilidades a diversos proyectos a través de Hackerone. Como método para reproducir el problema, el informe mencionaba palabras generales sobre el envío de una solicitud modificada con un tamaño de valor que superaba el tamaño del búfer utilizado durante la copia con strcpy. El informe también incluía un ejemplo de corrección (sustitución de strcpy por strncpy) y proporcionaba un enlace a la línea de código «strcpy(keyval, randstr)», en la que, según el denunciante, había un error.
El desarrollador verificó todo tres veces y no encontró ningún problema, pero dado que el informe estaba escrito con confianza e incluso contenía una corrección, surgía la sensación de que algo se estaba pasando por alto. Intentar aclarar cómo el investigador logró eludir la verificación de tamaño existente antes de la llamada a strcpy y cómo el tamaño del búfer keyval resultó ser menor que el tamaño de los datos leídos, llevó a obtener explicaciones detalladas pero que no aportaban información adicional, que solo aclaraban causas generales evidentes del desbordamiento de búfer, no relacionadas con el código específico de Curl. Las respuestas recordaban a una conversación con un asistente AI, y tras gastar medio día en intentos inútiles de saber cómo exactamente se manifestaba el problema, el desarrollador se convenció de que realmente no había vulnerabilidad alguna.
Fuente: opennet.ru
