Daniel Stenberg, autor de una utilidad para recibir y enviar datos a través de la red curl, criticó el uso de herramientas de inteligencia artificial al crear informes de vulnerabilidad. Estos informes incluyen información detallada, están escritos en un lenguaje normal y parecen de alta calidad, pero sin un análisis cuidadoso, en realidad sólo pueden ser engañosos, reemplazando los problemas reales con contenido basura que parece de calidad.
El proyecto Curl paga recompensas por identificar nuevas vulnerabilidades y ya ha recibido 415 informes de problemas potenciales, de los cuales sólo 64 fueron confirmados como vulnerabilidades y 77 como errores no relacionados con la seguridad. Por lo tanto, el 66% de todos los informes no contenían ninguna información útil y solo les quitaban a los desarrolladores tiempo que podrían haberlo invertido en algo útil.
Los desarrolladores se ven obligados a perder mucho tiempo analizando informes inútiles y verificando varias veces la información contenida allí, ya que la calidad externa del diseño crea confianza adicional en la información y existe la sensación de que el desarrollador entendió mal algo. Por otro lado, generar un informe de este tipo requiere un esfuerzo mínimo por parte del solicitante, que no se molesta en comprobar si hay un problema real, sino que simplemente copia a ciegas los datos recibidos de los asistentes de IA, esperando tener suerte en la lucha por recibir una recompensa.
Se dan dos ejemplos de este tipo de informes basura. El día antes de la divulgación prevista de información sobre la peligrosa vulnerabilidad de octubre (CVE-2023-38545), se envió un informe a través de Hackerone de que el parche con la solución estaba disponible públicamente. De hecho, el informe contenía una mezcla de datos sobre problemas similares y fragmentos de información detallada sobre vulnerabilidades pasadas compiladas por el asistente de inteligencia artificial de Google, Bard. Como resultado, la información parecía nueva y relevante y no tenía conexión con la realidad.
El segundo ejemplo se refiere a un mensaje recibido el 28 de diciembre sobre un desbordamiento del buffer en el manejador WebSocket, enviado por un usuario que ya había informado a varios proyectos sobre vulnerabilidades a través de Hackerone. Como método para reproducir el problema, el informe incluía palabras generales sobre cómo pasar una solicitud modificada con un valor mayor que el tamaño del búfer utilizado al copiar con strcpy. El informe también proporcionó un ejemplo de corrección (un ejemplo de sustitución de strcpy por strncpy) e indicó un enlace a la línea de código "strcpy(keyval, randstr)", que, según el solicitante, contenía un error.
El desarrollador verificó todo tres veces y no encontró ningún problema, pero como el informe fue escrito con confianza e incluso contenía una corrección, existía la sensación de que faltaba algo en alguna parte. Un intento de aclarar cómo el investigador logró eludir la verificación de tamaño explícita presente antes de la llamada strcpy y cómo el tamaño del buffer keyval resultó ser menor que el tamaño de los datos leídos condujo a explicaciones detalladas, pero que no contienen información adicional. que solo analiza las causas comunes obvias de desbordamiento del búfer no relacionadas con el código Curl específico. Las respuestas recordaban a la comunicación con un asistente de IA, y después de pasar medio día intentando inútilmente descubrir exactamente cómo se manifiesta el problema, el desarrollador finalmente se convenció de que en realidad no había ninguna vulnerabilidad.
Fuente: opennet.ru