Informe de seguridad de curl generado por IA

• El proyecto curl opera un programa de recompensas por errores y está viendo un aumento de reportes de seguridad que parecen hechos con LLM, lo que hace que el tiempo de los desarrolladores se gaste verificando reportes falsos en lugar de atender vulnerabilidades reales
• Hasta ahora, curl ha pagado más de 70 mil dólares y ha recibido 415 reportes, pero solo 64 correspondieron a problemas de seguridad reales y 77 fueron clasificados como informativos
• El problema central es que los reportes, al venir con inglés convincente, explicaciones detalladas e incluso propuestas de corrección, elevan mucho el costo de revisión
• En 2023 se recibieron un reporte que afirmaba la divulgación de cambios de código de CVE-2023-38545 y otro sobre un desbordamiento de búfer en WebSocket, pero en realidad no había ni divulgación ni desbordamiento de búfer
• La IA puede ser útil como apoyo para traducción, redacción o herramientas de detección de vulnerabilidades, pero enviar salidas de LLM sin validación humana traslada al proyecto el costo de responder a la seguridad en código abierto

---

Reportes de baja calidad que enfrenta el bug bounty de curl

• El proyecto curl opera un programa de recompensas por errores que paga recompensas reales a hackers que reportan problemas de seguridad
• La posibilidad de obtener una recompensa atrae a “luck seekers” que hacen grep de patrones en el código fuente o solo ejecutan escáneres de seguridad básicos y luego envían resultados sin análisis suficiente
• En el pasado, los reportes de baja calidad solían identificarse y descartarse rápidamente, por lo que la pérdida de tiempo no se había convertido en un gran problema para el proyecto
• Resultados acumulados del bug bounty de curl hasta ahora:
  • Más de 70 mil dólares pagados en recompensas
  • 415 reportes de vulnerabilidades recibidos
  • 64 confirmados como problemas de seguridad reales
  • 77 clasificados como informativos, como bugs comunes u otros casos similares
  • 66% del total de los reportes no eran ni problemas de seguridad ni bugs generales

Por qué los reportes falsos pero verosímiles son más peligrosos

• Cuanto más sofisticado es un reporte falso, más tiempo de investigación y energía se requieren para descartarlo
• Todos los reportes de seguridad deben ser leídos por una persona para evaluar su significado real
• El trabajo de seguridad suele recibir alta prioridad, así que incluso los reportes falsos pueden desplazar otras tareas de desarrollo
• Los reportes que no mejoran la seguridad real quitan tiempo que podría dedicarse a corregir bugs molestos o desarrollar nuevas funciones
• Responder repetidamente a reportes de baja calidad también aumenta el desgaste de los desarrolladores

Reportes de seguridad que parecen hechos por IA

• La IA es una herramienta de uso general que puede servir para cosas buenas, pero también puede usarse de forma equivocada
• Puede haber potencial para usar IA de manera productiva en la detección y reporte de problemas de seguridad, pero el proyecto curl aún no ha encontrado buenos ejemplos
• Por ahora, parece que algunos usuarios introducen el código de curl en un LLM y luego envían esa salida como reporte de vulnerabilidad
• Como los usuarios no solo copian y pegan la salida de la IA, sino que también mezclan texto propio, detectarlo se vuelve más difícil
• Aunque todo el reporte no coincida exactamente con frases generadas por IA, el resultado puede seguir siendo un reporte inválido

Por qué no es fácil descartarlos solo por indicios de IA

• Entre los reportantes hay personas que no dominan el inglés y, para entender su intención, a veces hacen falta varias rondas de preguntas y respuestas
• Las barreras de idioma y cultura existen de verdad, y ese proceso de comunicación puede aceptarse como algo natural
• Algunos reportantes usan IA u otras herramientas como apoyo de traducción y redacción para comunicarse mejor en un idioma extranjero
• Incluso quienes no hablan bien inglés pueden encontrar y reportar problemas de seguridad reales
• Por eso, no es fácil descartar un reporte de inmediato solo porque parte del texto muestre rastros de haber sido generado por IA, y los reportes falsos bien escritos toman más tiempo de evaluar

Caso A: afirmación de divulgación de cambios de código de CVE-2023-38545

• En otoño de 2023, la comunidad de curl fue informada de la próxima divulgación de CVE-2023-38545, evaluada con severidad alta
• Un día antes de que ese problema se hiciera público, llegó a HackerOne el reporte “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet”
• Solo por el título, si hubiera sido cierto, habría sido un asunto serio
• Sin embargo, el reporte parecía una típica alucinación de IA: mezclaba hechos y detalles de problemas de seguridad anteriores para fabricar contenido nuevo que no estaba conectado con la realidad
• Los cambios de CVE-2023-38545 no se habían divulgado en internet, y los cambios que sí estaban públicos correspondían, como era esperado, a un problema antiguo distinto
• El reportante dijo que había encontrado el problema usando Bard, lo que facilitó detectar el error y cerrar el reporte

Caso B: acusación de desbordamiento de búfer en WebSocket

• En la mañana del 28 de diciembre de 2023, llegó a HackerOne el reporte “Buffer Overflow Vulnerability in WebSocket Handling”
• Por el título parecía grave, pero el código de WebSocket en curl todavía era una función experimental, así que no estaba cubierto por el bug bounty
• El reportante era un usuario nuevo para el proyecto, pero tenía una reputación aceptable en HackerOne y no era su primer reporte de seguridad
• El reporte estaba bien organizado e incluía detalles, buen inglés e incluso una corrección propuesta
• Al principio parecía mejor que un reporte inicial promedio y daba la impresión de que el reportante entendía el problema y también proponía una solución
• Tras revisar el código varias veces durante 19 minutos, no se pudo encontrar el desbordamiento de búfer que se afirmaba
• Después de preguntas repetidas y varias respuestas con rasgos de alucinación, se concluyó que no era un problema real, y ese mismo día por la tarde el caso se cerró como not applicable
• No se puede asegurar que esas respuestas hubieran sido generadas por un LLM, pero sí quedaron varias señales

Función de bloqueo y sanciones de reputación en HackerOne

• Al principio se pensó que HackerOne no tenía una función para bloquear explícitamente a un reportante de futuras comunicaciones con el proyecto
• Se señaló que, de existir esa función, se habría usado
• Cerrar un caso como not applicable reduce la reputación del investigador en HackerOne, pero si eso ocurre solo una vez en un solo proyecto, el efecto sancionador es muy pequeño
• En una actualización posterior se añadió que la función sí existía, pero que simplemente no se había visto en el lugar correcto

Más reportes generados por LLM en el futuro

• Se espera que este tipo de reportes se vuelva más común con el tiempo
• Los proyectos pueden aprender a detectar mejor las señales de contenido generated-by-AI y a descartar reportes con base en ello
• Sin embargo, eso también podría perjudicar casos en los que la IA se usó de forma adecuada, como apoyo para traducción o redacción
• En el futuro podrían aparecer algunas herramientas que realmente funcionen mejor para encontrar problemas de seguridad usando IA
• Se considera que incluso un nivel muy pequeño de validación humana mejoraría mucho la utilidad y los resultados de este tipo de herramientas
• Es probable que siga habiendo gente buscando atajos para obtener recompensas rápidas y, dado lo fácil que es acceder a LLM potentes, se espera que la bandeja de entrada de HackerOne reciba más reportes de baja calidad

[GN⁺]

Comentarios de Hacker News

• Frases como “¡Por supuesto! Permítame explicar con más detalle las preocupaciones planteadas por el clasificador” son un tono típico de LLM y suenan como un mayordomo robot
  Casi nunca he visto a una persona escribir así, y también es raro referirse al “clasificador” en tercera persona, como si hubiera otra entidad guiando la respuesta
  Está bien que los LLM tengan una forma identificable de hablar, pero lo preocupante es que los LLM no hablen como personas, sino que las personas empiecen a hablar como LLM

  • Daniel Stenberg[1] señaló un buen punto: curl se usa en todo el mundo, así que no tiene nada de raro que alguien cuya lengua materna no sea el inglés use ayuda de un LLM para redactar un bug report
    Por eso, no se puede asumir que el contenido del reporte también fue generado por un LLM solo por indicios superficiales de que el inglés parece escrito por uno

    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • Ojalá alguien esté escribiendo en algún lado una ciencia ficción distópica donde los amos robot siguen disculpándose mientras dicen cosas como “En última instancia, si se rendirá o no dependerá de sus necesidades y preferencias específicas”

  • Ver lo de “suena como un mayordomo robot” de repente me hizo entender la expresión Butlerian Jihad

  • En India, a veces el inglés se enseña en un estilo británico colonial para la clase servicial, una especie de “habla de mayordomo”
    Si nunca habías visto ese tono hasta ahora, probablemente nunca trataste con soporte técnico corporativo de Microsoft

  • Sin duda es una gran señal de alerta, pero si una persona real fue quien entregó ese contenido basura, habría bastado con borrar esa línea
    El contenido seguiría siendo sospechoso, pero habría muchas menos pistas para notarlo

• La gente que busca una “recompensa mendigada” ya había hecho que operar programas de bug bounty fuera bastante molesto
  En ese entonces, al menos hacía falta que una persona real dedicara tiempo a armar “bug reports” que en esencia no eran nada, pero con los LLM se pueden crear reportes falsos casi sin costo, así que esto realmente podría volverse incontrolable
  Personalmente, creo que podría ser el fin de los programas de bug bounty
  O quizá haya que cerrarlos más: recibir solicitudes para participar en el programa, verificar de forma barata que se trata de una persona real, un investigador de seguridad legítimo y alguien que realmente busca fallas de seguridad con impacto, y luego permitir que solo las personas aprobadas puedan enviar bugs y recibir recompensas monetarias

  • Ya existen plataformas que ofrecen esa clase de función
    Mantienen un pool de investigadores conocidos, hacen seguimiento de su estado y permiten ajustar qué tan público quieres operar el programa
    Algunas también ponen clasificadores, pero el éxito o fracaso depende bastante de qué tan típico sea el proyecto
  • Otra opción podría ser cobrar una tarifa de envío
    No sé si ayudaría, pero al menos podría servir como freno contra envíos basura generados en masa por máquinas
    El peor escenario es una avalancha de basura de IA y luego intentar “resolverla” metiendo filtros de IA igual de malos, degradando la calidad general para todos los que quieren participar de buena fe

• Al principio pensé que esta publicación era un duplicado de https://news.ycombinator.com/item?id=37904047, pero resultó ser otro reporte falso de vulnerabilidad generado por LLM subido a curl en HackerOne

  • Menos mal, no estaba loco
    Mientras leía, estaba seguro de que ya lo había visto antes, pero es tan parecido al incidente anterior que resulta extraño
    ¿Será que en proyectos populares como curl la gente sigue abriendo reportes de incidentes escritos por LLM solo para meter una línea en el currículum?
  • Los clientes de HackerOne son las empresas que operan programas de bug bounty
    Parece que deberían gestionar con más cuidado a la gente que puede enviar a sus clientes spam basura de LLM solo para ganar visibilidad
  • No tenía ni idea de que esto ya había pasado antes
    Entonces lo de ahora se vuelve un precedente todavía más claro

• Lo que más me preocupa es que unos cuantos centavos de costo de LLM hayan desperdiciado mucho tiempo de ingeniería caro e importante
  Si uno imagina cuánto esfuerzo hará falta para desarmar toda la información falsa que se está generando, se parece a la ley de Brandolini

  • Sí, los LLM tienen el potencial de arruinar una parte enorme de internet, y no sé bien si esto es un problema solucionable
    Los modelos actuales dejan pistas evidentes, pero los futuros serán distintos y mejores
    La detección y el bloqueo pueden convertirse en una carrera armamentista, y mucha gente productiva y muchas plataformas podrían no lograr seguirles el ritmo

• Es interesante que hayamos convertido la escritura, el medio de menor ancho de banda para demostrar acción y esfuerzo, en algo mucho más intensivo en trabajo para determinar si realmente hubo acción o esfuerzo
  Las consecuencias probablemente serán muy grandes
  Aquí tanto quien reporta como quien administra desperdiciaron tiempo que podrían haber usado en algo más útil, y todo el proceso de bug bounty y de CVE basado en crowdsourcing se deteriora por la menor relación señal/ruido
  Como resultado, es más probable que suban las barreras de envío para combatir el spam, y eso puede llevar a que se descubran y corrijan menos bugs, aumenten las vulnerabilidades de seguridad y aparezcan todos los problemas derivados
  La misma dinámica también opera en otras áreas, haciendo cada vez más difícil confiar en reseñas de productos, documentos presentados ante tribunales, recetas, guías de uso, consejos médicos y más
  Una de las promesas de internet era la rápida expansión del contenido mediante la democratización de la publicación, pero da la impresión de que estamos viendo incluso el vaciamiento de las ventajas que todavía quedaban

• Aquí es especialmente raro cuestionar la comprobación de límites de longitud
  No se usa en absoluto ningún dato proporcionado por el usuario, y todos los tamaños son estáticos en tiempo de compilación
  curl está metiendo en un búfer estático de 40 bytes una cadena aleatoria de 16 bytes codificada en base64, es decir, 25 bytes ASCII más el terminador nulo \0

  https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

Y ya por simple curiosidad, ¿alguien que sepa más de C que yo puede explicar por qué aquí usan la variable local keyval?
¿Por qué no simplemente asignar heads[3].val = randstr y luego hacer free() cuando termine el procesamiento de los datos del header?
Y además, ¿por qué keyval tiene 40 bytes en vez de 26 o 32?

• Probablemente la idea sea reducir la cantidad de lugares donde hay que llamar a free y disminuir la posibilidad de olvidarlo.
  Aunque uno podría pensar que eso ya podría pasar en la línea 580, en la práctica quizá ese caso nunca ocurra.

• Si ese era el objetivo, entonces podrían eliminar tanto randstr como keyval y, ya que de todos modos se asigna memoria, codificar directamente en &heads[3].val.
  Aun así habría que seguir pasando el inútil randlen, porque si no, falla.
  La belleza propia de un parámetro de salida en C.
  Este baile de “copiar del heap a una variable en el stack” tampoco reduce el trabajo de limpieza.
  Después de codificar, de todos modos solo hay un punto de retorno.
  Eso sí, si primero “dejaron preparadas” las variables arriba y luego se dieron cuenta de que Curl_base64_encode siempre asigna memoria, sí se entiende cómo terminó quedando el código actual.

• Usar el stack es casi gratis, porque el espacio ya queda reservado durante la configuración de la función y se limpia automáticamente cuando la función retorna.
  Usar el heap requiere más trabajo, puede fallar y necesita limpieza manual.

• Una de las lecciones importantes que aprendí en la preparatoria fue cómo distinguir entre una mentira expresada con elegancia y una verdad expresada de forma tosca.
  Pero puede ser difícil.
  La gente tiende a usar la gramática y el estilo correctos como filtro primario del discurso intelectual, y los LLM son extremadamente buenos para hacer que la forma del lenguaje suene convincente.

  • Me pregunto hasta qué punto esa lección realmente nos llegó a mí y a mis compañeros en ese momento.
    Es un problema muy complicado, y creo que la mayoría de los adultos tampoco está preparada para manejarlo.
    La persona promedio sí tiene suficiente capacidad para distinguir entre ambas cosas, pero el problema es que hace falta acostumbrarse a leer de forma sistemática y poner esfuerzo.
    Cuando estás scrolleando en el celular a altas horas de la noche, eso se vuelve muy difícil.

• Si no hubiera sido tan irritante y una pérdida de tiempo, habría sido gracioso ver a dineshsec / dinesh_b intentando enseñarle a Daniel cómo usar strncpy.
  Primero etiquetó a Daniel con un handle cualquiera, y luego inventó código inexistente diciendo “el código en cuestión es el siguiente:”.

  • Este es un problema típico del mal uso de los LLM.
    El usuario quiere analizar algo, pero como es demasiado largo lo va pegando en varias solicitudes.
    Entonces, para cuando llega al punto clave, el fragmento de código original ya se perdió fuera del contexto, y el modelo empieza a soltar con total seguridad cosas plausibles pero que en realidad no existen.

• No debería usarse strcpy ni strncpy, sino simplemente memcpy.
  En particular, strncpy es claramente la peor opción de las tres.
  El código ya conoce el tamaño del búfer de origen y además ya verificó si cabe en el búfer de destino, así que no hay razón para llamar a strcpy y hacer que vuelva a medir innecesariamente la longitud de la cadena.
  Sinceramente, la recomendación del LLM es algo que desaconsejaría activamente.
  Si no sabes el tamaño, no te preocupa el truncamiento silencioso y tampoco te importa el rendimiento, entonces usa snprintf.
  strncpy rellena innecesariamente con ceros el resto del búfer.
  Salvo que estés trabajando con algo como UI, por lo general sí debería importarte el truncamiento, y en ese caso strncpy no te va a salvar.

• Esto parece relacionado: https://news.ycombinator.com/item?id=38840907