Anthropic anunció capacidades ampliadas de detección de vulnerabilidades en su modelo de IA Claude Opus 4.6 y compartió los resultados de un experimento que identificó más de 500 vulnerabilidades previamente desconocidas (de día cero) en las últimas versiones de varios proyectos de código abierto. El estudio se centró en identificar vulnerabilidades causadas por problemas de memoria, ya que su presencia es más fácil de verificar. A todas las vulnerabilidades identificadas se les asignó un nivel de gravedad alto. Cada vulnerabilidad fue revisada y confirmada manualmente por empleados de Anthropic o investigadores de seguridad externos.
Para analizar las vulnerabilidades, se utilizaron bases de código de proyectos populares de código abierto que llevan mucho tiempo sometiéndose a pruebas de fuzzing continuas mediante el servicio OSS-Fuzz. A diferencia de las pruebas de fuzzing, que generan un flujo de todas las posibles combinaciones aleatorias de datos de entrada, el modelo de IA intentó analizar el código, considerando correcciones anteriores para identificar errores similares sin resolver, identificar patrones problemáticos y deducir lógicamente qué datos de entrada podrían interrumpir la ejecución.
La información sobre las vulnerabilidades identificadas durante el experimento ya se ha empezado a compartir con los mantenedores, con quienes colaboramos para aprobar los parches. Para ayudarles durante la revisión manual, se desarrollaron parches que abordan los problemas identificados. A modo de ejemplo, se listan tres vulnerabilidades en GhostScript, OpenSC y CGIF, corregidas por los mantenedores al momento de la publicación.
Используемая для выявления проблем конфигурация не была похожа на традиционные системы автоматического поиска уязвимостей — модели Claude Opus 4.6 был предоставлен доступ к máquina virtual, в которой помимо исследуемого кода были установлены типовые инструменты разработчиков (coreutils, Python и т.п.) и утилиты для отладки и анализа уязвимостей (в том числе утилиты для fuzzing-тестирования). Модели не давалась чёткая инструкция по использованию данных инструментов и не предоставлялись специальные сведения о методах поиска уязвимостей. Модели была лишь поставлена задача и предоставлена возможность самостоятельно рассуждать об оптимальном использовании доступных инструментов.
Al buscar vulnerabilidades en GhostScript, el modelo de IA intentó inicialmente realizar pruebas de fuzzing, pero al fallar, optó por el análisis de código. El análisis de código también falló, por lo que el modelo comenzó a examinar el historial de commits de Git y detectó una mención de una comprobación de límites de búfer en uno de ellos. Tras analizar el commit, el modelo determinó que la corrección añadía una comprobación de límites de búfer que faltaba al procesar fuentes.
El modelo identificó el código existente antes de la corrección e intentó encontrar patrones similares de uso de la función problemática en el código restante que no se había corregido. Finalmente, se detectó una llamada a la función gs_type1_blend sin una comprobación de validación de valores en el archivo gdevpsfx.c. Finalmente, el modelo identificó el contenido del archivo cuyo procesamiento provocó un fallo debido a la escritura de datos en un área de memoria fuera del búfer asignado.
En CGIF, el modelo de IA se basaba en que, al descomprimir archivos GIF, la biblioteca asumía que el tamaño de los datos comprimidos siempre era menor que el de los descomprimidos. La búsqueda de vulnerabilidades se centró en identificar las condiciones bajo las cuales los datos comprimidos con LZW serían mayores que los descomprimidos. Se encontraron dichas condiciones, y el modelo de IA logró generar un archivo GIT cuyo procesamiento provocó un desbordamiento de búfer. En OpenSC, el problema se identificó tras analizar el uso de las funciones potencialmente peligrosas strrchr y strcat en el código.
Se observa que los modelos de lenguaje han alcanzado un nivel capaz de identificar vulnerabilidades previamente desconocidas y pronto superarán a los expertos en seguridad en velocidad y escala de búsqueda de vulnerabilidades. Se prevé que el creciente número de vulnerabilidades identificadas requerirá reformar los procesos de divulgación existentes, ya que el plazo actual de 90 días para la aplicación de parches será insuficiente.
Fuente: opennet.ru
