La empresa Anthropic ha anunciado una ampliación en las capacidades del modelo de IA Claude Opus 4.6 para la búsqueda de vulnerabilidades en el código y ha compartido los resultados de un experimento, en el cual se descubrieron más de 500 vulnerabilidades desconocidas (0-day) en las últimas versiones de varios proyectos de código abierto. El trabajo se centró en la búsqueda de vulnerabilidades causadas por problemas de gestión de memoria, ya que son más fáciles de verificar. A todas las vulnerabilidades detectadas se les asignó un alto nivel de peligro. Cada vulnerabilidad fue verificada manualmente y confirmada por empleados de Anthropic o investigadores de seguridad externos involucrados.
Para el análisis de vulnerabilidades se utilizaron las bases de código de populares proyectos de código abierto, que han estado sometidos a pruebas de fuzzing continuas en el servicio OSS-Fuzz durante un largo tiempo. A diferencia de las pruebas de fuzzing, donde se genera un flujo de combinaciones aleatorias de datos de entrada, el modelo de IA intentó analizar el código considerando correcciones pasadas para identificar errores similares no resueltos, destacando patrones problemáticos y deduciendo lógicamente qué datos de entrada podrían interrumpir el flujo de ejecución.
La información sobre las vulnerabilidades identificadas durante el experimento ya ha comenzado a ser transmitida a los mantenedores, con los que se está trabajando en conjunto para implementar correcciones. Para ayudar a los mantenedores durante la revisión, se desarrollaron parches manualmente para corregir los problemas detectados. Como ejemplo, se mencionan tres vulnerabilidades en GhostScript, OpenSC y CGIF, que al momento de la publicación ya han sido corregidas por los mantenedores.
La configuración utilizada para identificar problemas no se parecía a los sistemas tradicionales de búsqueda automática de vulnerabilidades: al modelo Claude Opus 4.6 se le proporcionó acceso a una máquina virtual, en la que además del código investigado se instalaron herramientas de desarrolladores estándar (coreutils, Python, etc.) y utilidades para la depuración y análisis de vulnerabilidades (incluidas herramientas para pruebas de fuzzing). A la modelo no se le dio una instrucción clara sobre el uso de estas herramientas ni se proporcionó información específica sobre los métodos de búsqueda de vulnerabilidades. Solo se le planteó una tarea y se le dio la oportunidad de razonar sobre la mejor manera de utilizar las herramientas disponibles.
En la búsqueda de vulnerabilidades en GhostScript, el modelo AI inicialmente intentó realizar pruebas de fuzzing, pero cuando esto no dio resultados, cambió a análisis de código. El análisis de código tampoco fue fructífero y luego el modelo comenzó a estudiar el historial de cambios en git, donde en uno de los commits notó una mención sobre la verificación de límites de búfer. Al investigar el commit, el modelo determinó que la corrección añadía la verificación que faltaba para los límites de búfer al procesar fuentes.
A continuación, el modelo identificó el código que existía antes de la corrección e intentó encontrar en el resto del código patrones similares de uso de la función problemática que permanecieran sin corregir. Como resultado, en el archivo gdevpsfx.c se detectó una llamada a la función gs_type1_blend sin verificar la validez de los valores. Al final, el modelo recopiló el contenido de un archivo cuya manipulación llevó a un cierre inesperado debido a la escritura de datos en un área de memoria fuera del búfer asignado.
En CGIF, el modelo AI partió de la premisa de 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 definir las condiciones bajo las cuales los datos comprimidos mediante el algoritmo LZW superarían el tamaño de los descomprimidos. Se encontraron tales condiciones y el modelo AI pudo generar un archivo GIT, cuya manipulación causó un desbordamiento de búfer. En OpenSC, el problema fue identificado tras el análisis del uso en el código de funciones potencialmente peligrosas como strrchr y strcat.
Se observa que los modelos de lenguaje han alcanzado un nivel que les permite identificar vulnerabilidades previamente desconocidas y, en breve, superarán a los expertos en seguridad en velocidad y escala en la búsqueda de vulnerabilidades. Se supone que el aumento en el número de vulnerabilidades identificadas requerirá una reforma de los procesos actuales de divulgación, ya que los 90 días actualmente asignados para su corrección serán insuficientes.
Fuente: opennet.ru
