- Comparte la experiencia de usar el modelo o3 de OpenAI para descubrir una vulnerabilidad remota 0-day (CVE-2025-37899) en la implementación SMB del kernel de Linux
- Mientras se evaluaba la capacidad de análisis de LLM sobre el código de ksmbd, se comparó el desempeño del LLM tomando como referencia una vulnerabilidad previamente hallada de forma manual
- Durante el proceso de detección de vulnerabilidades, se diseñó el contexto por función y con prompts adecuados para que o3 pudiera reconocer la vulnerabilidad
- Como resultado del experimento, o3 encontró vulnerabilidades con una precisión 2 a 3 veces mayor que los LLM anteriores, y además descubrió automáticamente un nuevo tipo de bug use-after-free
- Los LLM, en especial modelos recientes como o3, muestran flexibilidad y creatividad similares al enfoque humano en auditoría de código e investigación de vulnerabilidades, por lo que su valor práctico va en aumento
Introducción
Este texto presenta cómo se descubrió una vulnerabilidad remota 0-day en la implementación SMB del kernel de Linux (ksmbd) usando el modelo o3 de OpenAI. El experimento se realizó usando únicamente la API de o3, sin frameworks ni herramientas adicionales. ksmbd es el servidor que implementa el protocolo SMB3 dentro del kernel de Linux para ofrecer compartición de archivos por red. A partir de una auditoría de vulnerabilidades iniciada como una pausa del trabajo relacionado con LLM, se hizo un benchmark para medir qué tan bien o3 podía encontrar bugs reales. Aquí el foco está especialmente en la vulnerabilidad zero-day CVE-2025-37899 encontrada por o3.
Esta vulnerabilidad es un problema de use-after-free que ocurre durante el procesamiento del comando SMB logoff. Requiere comprender tanto la situación de conexiones concurrentes al servidor como la forma en que múltiples hilos comparten ciertos objetos. o3 detectó la vulnerabilidad al entender dentro del contexto estos problemas de concurrencia y errores de gestión de objetos. Este es el primer caso público conocido en el que un LLM descubre este tipo de vulnerabilidad.
El mensaje principal es que o3 demuestra que la capacidad de análisis de código y razonamiento lógico de los LLM dio un salto importante, y que cualquier investigador de vulnerabilidades debería prestar atención a esta tendencia. Los LLM no reemplazan a los expertos, pero ya apuntan a convertirse en una herramienta que aumenta de forma drástica la productividad y eficiencia de los especialistas. Para bases de código de menos de 10 mil líneas, o3 puede brindar ayuda práctica para detectar y resolver la mayoría de los problemas.
Benchmark de o3 usando CVE-2025-37778
Contexto y objetivo del benchmark
Primero, se evaluó la capacidad de o3 para detectar vulnerabilidades usando como punto de referencia CVE-2025-37778 (en adelante, la vulnerabilidad de autenticación Kerberos), una falla previamente descubierta de forma manual. Se trata de un problema donde ocurre un use-after-free durante el proceso de autenticación del cliente cuando el estado de la sesión cumple ciertas condiciones.
- Cuando el estado de la sesión es
SMB2_SESSION_VALID, el objeto de usuario se libera de memoria - Si luego falla la autenticación, el objeto de usuario no se reinicializa y puede seguir siendo accedido en ese estado, provocando el use-after-free
- Para entender toda la ruta relacionada, es necesario seguir cerca de 3,300 líneas de código, por lo que resulta una tarea de benchmark de dificultad adecuada
Construcción del contexto de análisis
En el experimento, desde la perspectiva de un sistema automatizado real de detección de vulnerabilidades, se construyó cuidadosamente el contexto (las regiones de código) que recibiría el LLM. Se incluyeron las funciones principales y subfunciones por unidad de handler de comandos SMB hasta una profundidad de llamada de 3 niveles, de modo que entrara todo el código con relación lógica (3.3k LoC en total, alrededor de 27k tokens). También fue necesario incluir funciones relacionadas con parsing de datos, bifurcación de requests y desconexión para obtener resultados confiables.
Los prompts concretos y el material de entrada usados pueden revisarse en el repositorio relacionado de GitHub. Al LLM se le dieron condiciones como las siguientes:
- Indicar de forma explícita que debía detectar vulnerabilidades de tipo use-after-free
- Explicar brevemente la estructura básica de ksmbd y su modelo de amenazas
- Usar prompts orientados a evitar falsos positivos
Las consultas reales se ejecutaron repetidamente con la herramienta de línea de comandos llm para recopilar resultados experimentales (N=100).
Resultados del benchmark
- o3: detectó la vulnerabilidad de autenticación Kerberos 8 veces de 100, no la detectó 66 veces, y reportó 28 falsos positivos
- Claude Sonnet 3.7: la detectó solo 3 veces
- Claude Sonnet 3.5: falló en detectarla en las 100 ejecuciones
Al final, o3 registró una precisión entre 2 y 3 veces superior a la de los LLM previos. Además, la salida real de o3 fue concisa, similar al reporte resumido que escribiría un investigador de seguridad humano. En cambio, los resultados de Sonnet 3.7 daban más la impresión de un registro de trabajo centrado en el proceso, con ventajas y desventajas al mismo tiempo.
Descubrimiento de un 0-day real (CVE-2025-37899) con o3
Experimento con entrada de código a gran escala
Además de la vulnerabilidad de Kerberos, se intentó una detección de vulnerabilidades más amplia con o3 incluyendo todos los handlers de comandos SMB (alrededor de 9,000 líneas). Sumando handlers de todo tipo y código de conexión/desconexión, se ingresaron en total unas 12k LoC (aproximadamente 100 mil tokens) de una sola vez. Al repetir la ejecución 100 veces, la vulnerabilidad de autenticación Kerberos se detectó solo 1 vez, lo que mostró con claridad una caída de rendimiento, aunque el objetivo principal era probar la utilidad del LLM sobre un rango de código más amplio.
La nueva vulnerabilidad descubierta en este experimento
En medio de eso, o3 descubrió un nuevo bug use-after-free distinto al de autenticación Kerberos. Se trataba de un problema de concurrencia en el handler de logoff de la sesión, donde dos hilos, en una situación de conexiones concurrentes, comparten y acceden al objeto user de la sesión, y un hilo libera el objeto mientras el otro puede seguir refiriéndose a él.
Resumen del reporte automático de vulnerabilidad generado por o3
- Dos hilos worker cooperan: uno libera de memoria el objeto
usermientras ejecuta la terminación de sesión (logoff), y el otro sigue usando ese objetouserdesde la sesión existente - Si justo después de liberarlo (antes de inicializarlo a
NULL) ocurre una dereferencia por otra ruta, se produce un use-after-free clásico - Dependiendo del timing, también puede ocurrir un DoS por
NULLdereference - Puede derivar en corrupción de memoria del kernel y ejecución arbitraria de código
Insights obtenidos del reporte automático
A partir de este reporte automático, se entendió que la forma en que se había corregido la vulnerabilidad previa de autenticación Kerberos (asignar NULL justo después de liberar) no era una solución fundamental para el procesamiento de logoff. Es decir, para garantizar la seguridad también hay que considerar el binding de sesión y el vector de ataque entre hilos. o3 incluso logró identificar ese punto en algunos reportes y demostrar que podía proponer una corrección “más sólida”.
Conclusión
Los LLM, y en particular modelos recientes como o3, muestran un desempeño mucho más cercano al de un investigador humano de seguridad que las técnicas anteriores en lo que respecta al análisis creativo y flexible de código. Hasta hace poco esto se discutía como una posibilidad teórica, pero o3 es el primero en llegar, en un caso real, a un nivel que resulta verdaderamente útil en la práctica. Por supuesto, o3 todavía puede producir falsos positivos y omisiones, pero la probabilidad de que entregue resultados realmente útiles ya es lo bastante alta como para que tenga sentido incorporarlo al trabajo real. Ahora es el momento en que investigadores de vulnerabilidades y desarrolladores deben buscar cómo integrar los LLM de manera eficiente en su flujo de trabajo.
1 comentarios
Comentarios en Hacker News
El autor explicó que gestiona el proyecto creando por separado archivos
.promptpara el system prompt, el contexto y los comandos auxiliares, y ejecutándolos mediantellmMe da la impresión de que esta forma tan estructurada de usar LLM muestra que, igual que con otras herramientas de ingeniería, se necesita un pensamiento de diseño meticuloso y un ajuste fino muy cuidadoso de las especificaciones
El proyecto relacionado puede verse aquí
Curiosamente, me dio risa que el autor admitiera con honestidad sobre esa parte que "en realidad todo mi system prompt está basado en conjeturas y está lejos de ser ciencia o ingeniería"
Hay distintas formas de escribir prompts, pero no existe un criterio claro para evaluarlas o compararlas, así que se siente casi como recitar conjuros improvisados
Por ejemplo, instrucciones como "eres un experto en encontrar vulnerabilidades", "dime solo vulnerabilidades reales, no falsas", o separar cosas con etiquetas HTML arbitrarias que uno supone que el modelo procesa bien
Me pregunto dónde entra realmente el componente de ingeniería
Me parece curioso recurrir a principios de ingeniería para intentar controlar un sistema que es esencialmente inestable e impredecible
A estos prompts les quedaría mejor llamarse "pistas"
Hoy en día, casi todos los LLM suelen ignorar el prompt si hace falta, porque su objetivo intrínseco es dar una respuesta sí o sí (sin importar si es verdadera o no), incluso cuando el prompt es contradictorio
En la publicación se menciona que la relación señal-ruido era de alrededor de 1:50, pero creo que el autor pudo identificar bien las señales significativas porque conoce muy bien el codebase
Justo esa parte, la automatización de la identificación de señales útiles, me parece el verdadero gran premio que podría lograrse con LLM, así que pienso seguir muy de cerca cómo evoluciona esto
Estamos desarrollando un sistema para mejorar este problema de relación señal-ruido, y también estamos haciendo benchmarking directo de agentes de software populares recientemente
La variación en los resultados es enorme, y planeamos publicar todos los resultados experimentales en una conferencia próxima
Debería dar una buena vista general del estado actual de la industria
Algo que se me ocurrió hace unos días: ¿no sería posible usar todo el historial del kernel de Linux, como todos los cambios en git, listas de correo, etc., para desarrollar un modelo fine-tuned?
Un LLM así podría convertirse en una versión sintética más cercana al criterio de desarrolladores que realmente han trabajado con ese código durante mucho tiempo
Con contexto largo ya se puede cubrir mucho, y algunos codebases superan los 200 mil tokens solo en código, así que creo que hay potencial
Una proporción de 1:50 es una tasa de detección muy buena en una situación tipo "buscar una aguja en un pajar"
Si el LLM pudiera escribir por sí mismo el harness y las pruebas de concepto que demuestren cada vulnerabilidad estimada, la relación señal-ruido mejoraría muchísimo
Pero por ahora ese tipo de automatización sigue siendo bastante costosa, lo cual es una lástima
Lo que más me impresionó fue que el propio autor repitió la búsqueda de vulnerabilidades 100 veces para distintos modelos de LLM
Ese nivel de recursos invertidos es muchísimo mayor que en la mayoría de problemas que yo había tratado con LLM, así que ahora estoy pensando si yo también debería dejarle una ronda de "repetición sin pensar" al modelo
Al final, la conclusión es que hace falta mucho dinero
Los zero-days se venden por cantidades importantes, y también se puede ganar dinero con bug bounties
Comparado con esas recompensas, el costo de usar LLM es mínimo
Un entorno de seguridad futuro en el que el costo de inferencia sea casi cero probablemente se verá completamente distinto
Ejecutarlo 100 veces por modelo también implica un consumo energético considerable
Cuando encontrar una vulnerabilidad típica en código C requiere gastar tantos recursos, siento que eso le quita mérito y más bien resalta el desperdicio y el lujo
Tomando en cuenta que estamos en una crisis climática global, me preocupa ver que se sigan quemando recursos en cosas de valor dudoso, como en los años 50
Como Claude no tenía un scratchpad separado, creo que el flujo de pensamiento y el reporte terminaron mezclados en el resultado
Me gustaría experimentar para ver cuánto cambia Claude cuando se le permite oficialmente un espacio para ordenar sus ideas
Mientras que o3 entrega el contenido esencial refinado con la sensación de un bug report escrito por un humano, el resultado de Sonnet 3.7 deja más rastros del flujo mental o del log de trabajo, en ese mismo sentido
Yo mismo he usado o3, 3.7 y Gemini 2.5 pro, y mi impresión es que o3 está en otro nivel, sin comparación
Puede que las puntuaciones de benchmark no se vean tan grandes, pero mientras más compleja es la tarea, más importa esa diferencia
Me intriga por qué lo anunciaron en noviembre del año pasado pero lo lanzaron recién hace como un mes (supongo que por temas de seguridad), y también espero con ganas o4
Me gustaría saber si alguien puede recomendar casos de uso, papers o enlaces relacionados con el uso de "scratchpad" en investigación
Me gustó porque resume muy bien la esencia del proceso de prompt engineering
En especial la parte de "hice todo lo posible por guiarlo para que no marcara vulnerabilidades incorrectas como falsos positivos, pero no tengo forma de saber si eso realmente ayuda y solo espero que haya servido; todavía no he evaluado lo suficiente si esto funciona, así que no es ni ciencia ni ingeniería, compartiré la evaluación después" se parece muchísimo a cómo desarrollo mis prompts
Creo que este tipo de uso, la detección automática de vulnerabilidades, podría ser el caso de uso más adecuado para los LLM
En teoría se puede automatizar todo el proceso y tratar al LLM como un fuzzer muy avanzado, ejecutando continuamente el objetivo en una VM y detectando posibles vulnerabilidades reales cuando aparezcan comportamientos anómalos
(recordando que muchos exploits iniciales empiezan tirando abajo la máquina o provocando un crash antes de refinarse)
Por un lado, este uso de LLM parece bastante efectivo; por otro, también deja la idea de que "el hecho de que podamos hacer este tipo de pruebas no significa que se haya revelado algo tremendamente nuevo o decisivo"
Dejo una charla en YouTube que di sobre el tema del targeting automatizado de bugs de zk
Esos parámetros extra son básicamente para seguimiento del enlace
De verdad espero que esto no termine como los problemas recurrentes de curl
Para el contexto relacionado, ver la publicación de Daniel Stenberg
Hasta donde sé, ksmbd es conocido como un servidor SMB en espacio de kernel, más ligero y orientado a alto rendimiento que el servidor Samba tradicional
P1: me da curiosidad saber quién usa realmente ksmbd en producción
P2: me da curiosidad saber por qué lo usan
¿Alguien sabe si esto soporta ACL de forma nativa como en Windows?
(Esa era la última razón para seguir usando Solaris, por lo que entiendo con soporte a través de ZFS)
Samba sigue atado a una estructura anticuada basada en sincronizar UID/GID y el modelo de seguridad de Unix
También hay que tener claro el trade-off: en Windows ya han ocurrido vulnerabilidades remotas de root bastante graves en servidores SMB dentro del kernel
La causa es un tema de licencias
Samba es GPLv3, mientras que Linux solo puede usar GPLv2
Supongo que simplemente lo usan por ser más ligero y de mayor rendimiento
Creo que es por una razón parecida a usar kmod-trelay en vez de relayd
Creo que el mayor desafío de corto plazo de los LLM, el Alignment Problem, se hace visible precisamente en este tipo de automatización de vulnerabilidades
Últimamente descubrí con un LLM, casi sin esfuerzo, una vulnerabilidad de seguridad realmente seria en un servidor de nicho que a veces uso
Si este mercado se automatiza, me preocupa que empiecen a estallar en masa problemas graves en todo tipo de software de cola larga que antes no valía la pena atacar manualmente
Por otro lado, gracias a este avance tecnológico, nosotros también podemos analizar nuestros propios codebases de forma automatizada desde una "perspectiva adversaria"
Eso nos da la oportunidad de parchear de forma preventiva vulnerabilidades que de otro modo un investigador podría encontrar y explotar
Por eso no me parece adecuado llamarlo un problema de alignment
Los atacantes pueden automatizar la detección de vulnerabilidades, pero los defensores también pueden tener esa capacidad
Incluso se puede incorporar automatización defensiva en el proceso de aprobación de commits o en cada build