Glasswing de Anthropic: 442 CVEs, solo 2 explotados y una avalancha de trabajo para los mantenedores

Como alguien que trabaja en una gran tecnológica y que ha pasado cada día laborable (y muchos fines de semana) desde el lanzamiento de Mythos parcheando problemas de seguridad graves, del tipo que puede acabar con la empresa, este tipo de publicaciones realmente me irritan.

Que los conjuntos de datos públicos de CVEs sean decepcionantes no significa mucho si todos los problemas están en bases de código privadas de empresas a las que nunca se les asignará un número CVE y que nunca tendrán una entrada de blog llamativa. Nunca vas a oír hablar de ellos, y la gente que trabaja en ellos probablemente no pueda contártelos, pero eso no significa que no existan.

Todos estamos preocupados por que el OSS tenga problemas de seguridad debido a lo ampliamente usadas que son cosas como PHP o curl... pero lo mismo puede decirse de los proveedores de correo electrónico, los SaaS de colaboración de documentos, los procesadores de pagos, etc., de los que dependen millones de empresas. Esas empresas nunca estarán en conjuntos de datos como este, y nunca revelarán públicamente cuántos problemas encontraron.

La vulnerabilidad PHP2Shell terminó siendo paradójicamente reconfortante para mí.

Soltaron modelos de frontera contra PHP, y la grande que encontraron se basaba en un fallo lógico ya conocido que era extremadamente difícil de explotar. Lo cual tiene sentido: de ahí la necesidad de modelos de frontera.

Y en la práctica, aunque ha habido muchos intentos y algunos éxitos simples de demostración, el impacto práctico parece haber sido pequeño, aparentemente limitado por la longitud de la cadena y la diversidad de configuraciones de PHP.

En resumen, efectivamente era una vulnerabilidad importante, pero no magia (en el sentido de Arthur C. Clarke).

Creo que en última instancia el miedo se reduce a: ¿crees que el código puede asegurarse? Reconozco que probablemente no haya una forma objetiva de demostrarlo deductivamente debido al problema de la parada, etc. Pero si uno cree que se puede construir código que opere según especificación, entonces debe haber un límite al daño que un LLM puede hacer, incluso uno muy inteligente.

Creo que estamos atravesando una fase en la que muchas deficiencias conocidas y clasificadas del código quedarán expuestas y, con suerte, corregidas. Apesta mientras está pasando. Pero en realidad no es la primera ronda de este tipo de evolución. Y en última instancia creo que, como antes, saldremos al otro lado con una tecnología más segura y duradera.

El blog es engañoso porque intenta caracterizar la eficacia de Project Glasswing mediante el uso de una fuente de datos tangencialmente relacionada. Un descubrimiento de vulnerabilidad de Project Glasswing ocurre la mayoría de las veces cuando un socio de Glasswing apunta un modelo de clase Mythos a su propio software, a menudo propietario. La fuente de datos (también conocida como "ledger") es solo para el programa de divulgación coordinada de vulnerabilidades de Anthropic para software de código abierto: en otras palabras, Anthropic mismo apuntando un modelo de clase Mythos a un paquete de OSS, y luego notificando al mantenedor después que había hecho esto, y que tenía hallazgos que compartir. Este trabajo de OSS es ciertamente útil, pero el número de correcciones refleja —en parte— la disponibilidad limitada de tiempo de los mantenedores voluntarios de OSS, y que Anthropic a veces trabaja sin conocer el modelo de amenazas del proyecto de OSS (el modelo de amenazas se solicita explícitamente en el esfuerzo más reciente oss-scanner). El porcentaje corregido suele ser mucho mayor cuando se usa Glasswing con software propietario, p. ej., https://blog.cloudflare.com/cyber-frontier-models/ "Nuestra investigación con Mythos Preview se realizó en un entorno controlado contra nuestro propio código; cada vulnerabilidad que surgió de este trabajo fue triada, validada y remediada donde se necesitaba actuar bajo el proceso formal de gestión de vulnerabilidades de Cloudflare."

Hay una anécdota sobre curl, pero no estoy seguro de que haya suficiente aquí para sacar conclusiones. El 20% de las vulnerabilidades se han hecho públicas, y muchas de ellas están marcadas como "retiradas" o "duplicadas". Sin embargo, no está claro si el 80% restante no se ha hecho público porque no están corregidas o no son reales. En otras palabras, este es un análisis de los supervivientes (públicos); no se puede decir mucho sobre los que siguen bajo embargo.

> Hasta ahora, solo 2 de las 442 se han explotado en la práctica, apenas el 0,45%.

> casi ninguna está siendo explotada

¿No es acaso todo el objetivo de glasswing parchear las cosas mucho antes de que puedan ser explotadas? Si el código parcheado se distribuye rápidamente, no hay oportunidad (ni incentivo) para que los actores maliciosos elaboren y distribuyan un exploit. Esto se lee como un intento de presentarlas como si no fueran vulnerabilidades "reales".

Es malo si esto apunta a un patrón general de que la IA es mejor encontrando vulnerabilidades que corrigiéndolas. Cuanto mayor sea esa proporción, más difícil será asegurar todas las cosas. La estadística actual de este experimento es de 37.966 a 217. Muchos falsos positivos, pero no suficientes para cambiar el panorama general. Espero que no hayan aplicado tokens equivalentes a ambos lados, o puede que la IA sea mejor demoliendo que construyendo.

Como alguien que está aguas abajo de la empresa en la publicación, puedo confirmar el tsunami de informes de vulnerabilidades generados por IA. Y así los mantenedores humanos quedan aún más estirados, y la mayoría de los bugs no importan.

Lo bueno es el impulso hacia una calificación de explotabilidad: si tienes una pieza de software vulnerable en tu sistema, pero no se está ejecutando, no es crítico.