La historia detrás de reforzar Firefox con Claude Mythos Preview
(hacks.mozilla.org)- Mozilla construyó un pipeline para encontrar bugs de seguridad reales a gran escala en Firefox, aumentando la señal y reduciendo el ruido de los reportes de seguridad generados por IA mediante mejoras en el rendimiento del modelo y en el harness
- En Firefox 150 release se corrigieron 271 bugs identificados por Claude Mythos Preview, y 149.0.2, 150.0.1, 150.0.2 también incluyeron correcciones relacionadas
- Entre los bugs representativos publicados se incluyen una primitive de objeto falso causada por la eliminación de inicialización de structs de WebAssembly GC en el JIT, un UAF en el proceso padre mediante una condición de carrera de IPC, un problema de deserialización de NaN, un bug de rehash de XSLT con 20 años de antigüedad y un overflow de bitfield de layout de 16 bits usando
rowspan=0 - Una parte importante de los bugs publicados corresponde a escapes de sandbox, y la IA pudo cubrir con más amplitud una superficie de ataque difícil de encontrar solo con fuzzing, ya que asume un proceso de contenido comprometido que eleva privilegios hacia el proceso padre con privilegios
- Mozilla montó un harness agéntico sobre su infraestructura de fuzzing existente para descartar conjeturas no reproducibles y validar hipótesis con casos de prueba, y planea integrarlo en integración continua para escanear los parches cuando entren al tree
El cambio en los bugs de seguridad de Firefox revelado por modelos de IA
- Hasta hace unos meses, los reportes de bugs de seguridad generados por IA que llegaban a proyectos open source solían parecer plausibles pero ser incorrectos, creando un costo asimétrico para quienes mantienen el proyecto
- En Firefox la situación cambió mucho en poco tiempo, y la razón principal fue la mejora en el rendimiento de los modelos y en las técnicas para dirigir, extender y combinar modelos con un harness para aumentar la señal y filtrar el ruido
- Mozilla normalmente mantiene en privado los reportes detallados de bugs durante varios meses incluso después de publicar avisos de seguridad y distribuir correcciones, pero esta vez decidió divulgar algunos reportes considerando la urgencia y el interés en todo el ecosistema
- Los reportes publicados fueron elegidos entre varios subsistemas del navegador; la selección es algo arbitraria, pero la profundidad y diversidad de los reportes muestran por qué los defensores necesitan aplicar esta técnica
Bugs representativos publicados
- 2024918
- Debido a una verificación de equivalencia incorrecta, el JIT eliminó por optimización la inicialización de un struct vivo de WebAssembly GC, lo que permitió crear una primitive de objeto falso conectable con lecturas y escrituras arbitrarias potenciales en código que ya había pasado por amplio fuzzing interno y externo
- 2024437
- Un bug de 15 años en el elemento
<legend>, activado mediante una combinación refinada de casos límite en áreas alejadas entre sí del navegador, como el límite de profundidad de pila recursiva, propiedades expando y cycle collection
- Un bug de 15 años en el elemento
- 2021894
- Al explotar de forma confiable una condición de carrera de IPC, un proceso de contenido comprometido podía manipular el conteo de referencias de IndexedDB en el proceso padre, provocando UAF y un posible escape de sandbox
- 2022034
- Un NaN sin procesar podía cruzar el límite de IPC y parecer un puntero etiquetado a objeto JS, por lo que la deserialización de un double podía llevar a una primitive de objeto falso en el proceso padre y a un escape de sandbox
- 2024653
- Un caso de prueba complejo que combinó loops de eventos anidados, un listener
pagehidey recolección de basura provocó un UAF en el setter de un atributo del elemento<object>
- Un caso de prueba complejo que combinó loops de eventos anidados, un listener
- 2022733
- Al inyectar miles de hashes de certificados en WebTransport, se amplió una condición de carrera en un loop de copia con mucho conteo de referencias, provocando un UAF en el padre mediante IPC desde un proceso de contenido comprometido
- 2023958
- Al interceptar llamadas a funciones DNS de glibc para simular un servidor DNS malicioso y reproducir un caso límite de fallback de UDP a TCP, se provocó una lectura fuera de límites del búfer y una filtración de memoria de stack del proceso padre durante el parsing de HTTPS RR y ECH
- 2025977
- Era un bug de XSLT con 20 años de antigüedad en el que una llamada reentrante a
key()provocaba un rehash de la tabla hash que liberaba el backing store, pero el puntero crudo a la entrada seguía usándose; fue uno de varios problemas sec-high de XSLT corregidos
- Era un bug de XSLT con 20 años de antigüedad en el que una llamada reentrante a
- 2027298
- Tras parchear el selector de color para simular una selección de usuario difícil de automatizar, se ejecutó un loop de eventos anidado con eventos de entrada síncronos para reentrar en el teardown del actor y hacer que un callback fuera liberado mientras se estaba liberando, provocando un UAF en el proceso de contenido
- 2023817
- Un proceso de contenido comprometido podía enviar al proceso padre una imagen de fondo de pantalla arbitraria para que la decodificara, y en combinación con una vulnerabilidad hipotética en el decodificador de imágenes podía llevar a un escape de sandbox
- Requería razonar en el proceso padre sobre el nivel de confianza de la entrada, algo difícil de automatizar
- 2029813
- En RLBox, la tecnología de sandboxing granular de Firefox 95, se evadió el sandbox aprovechando una brecha en la lógica de validación al copiar valores del lado no confiable al lado confiable
- 2026305
- Con un caso de prueba muy pequeño que aprovechaba la semántica especial de
rowspan=0en tablas HTML, se agregaron más de65535filas para eludir el clamping y desbordar un bitfield de layout de 16 bits, algo que los fuzzers no detectaron durante años
- Con un caso de prueba muy pequeño que aprovechaba la semántica especial de
Escapes de sandbox y capas de defensa
- Una parte importante de los bugs publicados son escapes de sandbox, y para terminar en una cadena de compromiso completa de Firefox tendrían que combinarse con otros exploits
- Estos reportes parten de que el proceso sandbox que renderiza el contenido de sitios ya fue comprometido por otro bug y que código máquina controlado por el atacante intenta escalar privilegios al proceso padre con privilegios
- Al crear escapes de sandbox, el modelo puede parchear el código fuente de Firefox siempre que el código modificado se ejecute solo dentro del proceso sandbox
- Este tipo de bug es difícil de encontrar con fuzzing, y Mozilla ha desarrollado técnicas como el fuzzing de IPC con snapshots, pero el análisis con IA pudo cubrir esta superficie crítica de manera mucho más amplia
- Lo que el modelo no encontró también fue importante
- En los últimos años, investigadores de seguridad enviaron varios reportes que causaban prototype pollution en el proceso padre con privilegios para escapar del sandbox del proceso
- En lugar de corregir cada problema uno por uno, Mozilla aplicó un cambio arquitectónico para congelar los prototypes por defecto
- En los logs del harness hubo muchas señales de intentos de usar esa ruta de escape que quedaron bloqueados por el diseño, confirmando el efecto directo del trabajo previo de hardening
Construcción de un pipeline de endurecimiento de seguridad con harnesses
- Mozilla llevó a cabo internamente durante los últimos años experimentos de auditoría de código con LLM para análisis estático de código de alto riesgo, usando modelos como GPT 4 o Sonnet 3.5
- Los experimentos iniciales mostraban potencial, pero la tasa de falsos positivos era demasiado alta para escalar
- La situación cambió con la llegada de harnesses agénticos capaces de detectar problemas de seguridad de forma más confiable
- Pueden encontrar bugs reales
- Pueden descartar conjeturas no reproducibles
- Con interfaces e instrucciones adecuadas, pueden crear y ejecutar casos de prueba reproducibles para validar dinámicamente hipótesis sobre bugs en el código
- Después de corregir los issues iniciales enviados por Anthropic en febrero, Mozilla construyó su propio harness sobre su infraestructura de fuzzing existente
- Al principio comenzaron con un experimento pequeño usando Claude Opus 4.6 para buscar escapes de sandbox
- Incluso solo con este modelo identificaron una cantidad considerable de vulnerabilidades antes desconocidas que requerían razonamiento complejo sobre código de un motor de navegador multiproceso
- Al principio observaban directamente el proceso en la terminal, ajustando en tiempo real los prompts y la lógica
- Cuando el funcionamiento se estabilizó, paralelizaron el trabajo con varias VM efímeras, donde cada VM buscaba bugs en archivos objetivo específicos y luego registraba los resultados en un bucket
- El subsistema de descubrimiento por sí solo no era suficiente
- Había que integrarlo con todo el ciclo de vida del bug de seguridad, incluyendo qué buscar, dónde mirar y cómo procesar los resultados
- Eso incluye eliminar duplicados con issues existentes, seguimiento de bugs, triage y distribución de correcciones
- El modelo es el bloque primitivo central que mueve el harness, pero para que sea útil a escala se necesita todo el pipeline
- El harness puede reutilizarse entre proyectos, pero el pipeline cambia según el significado del codebase, las herramientas y los procesos de cada proyecto
- Hizo falta bastante trabajo iterativo y un loop de retroalimentación muy cercano con la manera en que los ingenieros de Firefox procesan los bugs entrantes
Claude Mythos Preview y el efecto de cambiar de modelo
- Una vez que el pipeline end-to-end está listo, cambiar a otro modelo cuando sale uno nuevo se vuelve sencillo
- Mozilla encontró varios bugs graves incluso con modelos públicos, y gracias a este pipeline pudo aprovechar de inmediato la oportunidad de evaluar Claude Mythos Preview
- La mejora de modelo elevó la eficacia de todo el pipeline
- Encuentra mejor los bugs potenciales
- Construye mejor los casos de prueba de prueba de concepto que demuestran el bug
- Resume mejor las patologías y el impacto
- Además de corregir 271 bugs identificados por Claude Mythos Preview en Firefox 150 release, también se incluyeron correcciones relacionadas en 149.0.2, 150.0.1 y 150.0.2
- Internamente siguen encontrando bugs por otras vías, y al igual que otros proyectos también aumentaron mucho los reportes externos en los últimos meses
- Todos los bugs requirieron atención cuidadosa para corregirse bien, y durante los últimos meses hubo mucho trabajo y jornadas largas para ponerse al día con una escala sin precedentes
- Más de 100 personas participaron aportando código para lanzar la versión más segura posible de Firefox; además de escribir y revisar parches, también trabajaron en construir y expandir el pipeline, hacer triage, probar correcciones y gestionar el proceso de release de cada bug
Lecciones clave
- Cualquiera que haga software hoy puede usar modelos modernos y harnesses para encontrar bugs y endurecer su código
- Se puede empezar con prompts simples, observar y repetir
- El prompt inicial no era muy distinto del enfoque mostrado en este video
- Con la iteración se añadieron muchas herramientas y orquestación para optimizar y escalar el pipeline, pero el núcleo del loop interno seguía siendo: “hay un bug en esta parte del código, encuéntralo y crea un caso de prueba”
- Firefox no está en un estado donde ya se hayan agotado todos los bugs potenciales, pero están satisfechos con la trayectoria actual
- En este momento el escaneo se enfoca principalmente en áreas específicas de código, es decir, archivos y funciones seleccionados mediante una mezcla de juicio humano y señales automáticas
- En el futuro cercano planean integrar este análisis en el sistema de integración continua para escanear los parches cuando entren al tree
- Los modelos se adaptan con flexibilidad al formato de contexto que se les da, y esperan que el escaneo basado en parches funcione igual de bien o mejor que el escaneo basado en archivos
- El momento actual es riesgoso, pero también ofrece una gran oportunidad, y hay que actuar juntos para hacer internet más seguro
Preguntas frecuentes
-
Por qué “271 bugs” y el número de avisos de seguridad no coinciden
- La página web de avisos de seguridad agrupa varios bugs reportados internamente en CVE de tipo “rollup”, donde múltiples bugs quedan reunidos bajo uno solo
- La página se genera a partir del yaml del repositorio foundation-security-advisories, que es la ubicación formal para la asignación de CVE
- Algunos navegadores no crean identificadores CVE para issues encontrados internamente, pero Mozilla los divulga para ofrecer la mayor transparencia posible
- Firefox 150 tuvo 3 rollups internos
- CVE-2026-6784: 154 bugs
- CVE-2026-6785: 55 bugs
- CVE-2026-6786: 107 bugs
- La suma de los tres rollups internos es 316, más que los 271 bugs que se anunció haber encontrado con Claude Mythos Preview
- La razón es que el equipo de seguridad de Mozilla ataca Firefox todos los días para encontrar nuevos bugs, usando una combinación de sistemas de fuzzing, revisión manual y el nuevo pipeline agéntico con varios modelos
- En la release de abril se corrigieron 423 bugs de seguridad en total
- Los 271 bugs anunciados hace dos semanas
- 41 bugs reportados externamente
- Los 111 restantes fueron hallazgos internos y se dividen aproximadamente en tres grupos
- Bugs encontrados con este pipeline usando Claude Mythos Preview, pero corregidos en una release distinta de Firefox 150
- Bugs encontrados con este pipeline usando otros modelos
- Bugs encontrados con otras técnicas, como fuzzing
- Anthropic recibió crédito directo por 3 CVE aparte de este trabajo más reciente
- CVE-2026-6746
- CVE-2026-6757
- CVE-2026-6758
- Se trata de correcciones de bugs enviados hace meses a Mozilla por el Anthropic Frontier Red Team, y a cada uno se le asignó un CVE único según el procedimiento habitual
-
Qué significan las calificaciones de severidad de seguridad
- Mozilla aplica security severity ratings desde critical hasta low para indicar la urgencia de un bug
- sec-critical y sec-high se asignan a vulnerabilidades que pueden activarse con acciones normales de un usuario, como visitar una página web
- No hay una diferencia técnica entre sec-critical y sec-high, pero sec-critical se usa solo para issues que ya fueron divulgados públicamente o se sabe que fueron explotados en ataques reales
- sec-moderate se asigna a vulnerabilidades que de otro modo serían sec-high, pero que requieren pasos anómalos y complejos por parte de la víctima
- sec-low se asigna a bugs molestos pero lejanos de causar daño al usuario, como un crash seguro
- Las calificaciones de los 271 bugs anunciados en Firefox 150 fueron las siguientes
- 180 sec-high
- 80 sec-moderate
- 11 sec-low
- Mozilla considera critical/high como lo más importante, pero también suele priorizar bugs de seguridad moderate y low para corregir problemas de exactitud y reforzar la defensa en profundidad
-
La diferencia entre sec-high o sec-critical y un exploit real
- Que un bug sea sec-high o sec-critical no significa automáticamente que exista un exploit práctico
- En la mayoría de los casos, un solo bug critical/high no basta por sí mismo para comprometer Firefox
- Firefox tiene una arquitectura de defensa en profundidad, así que por ejemplo explotar un bug del JIT solo da ejecución remota de código dentro de un proceso sandboxeado y aislado por sitio
- En un ataque real, normalmente el atacante debe encadenar varios exploits para elevar privilegios a través de una o más capas de sandboxing y mitigaciones a nivel del sistema operativo como ASLR
- Mozilla por lo general no desarrolla exploits para confirmar si un bug sería utilizable por atacantes reales
- La clasificación sec-high se basa en síntomas de crash predecibles, como use-after-free o problemas de memoria out-of-bounds reportados por AddressSanitizer
- El modelo de amenazas asume que con suficiente esfuerzo este tipo de bugs podría llegar a ser explotable
- Este enfoque reduce el riesgo de falsos negativos en el análisis de explotabilidad y permite concentrar recursos en encontrar y corregir más vulnerabilidades
2 comentarios
Opiniones de Hacker News
Insisto de nuevo: un bug es un bug. Una “vulnerabilidad potencial” también es un bug, y para que una vulnerabilidad tenga impacto de seguridad verificado debe validarse con una prueba de concepto o evidencia equivalente
Las palabras importan, y los bugs también. Corregir muchos bugs siempre ha sido importante y es algo que se ha hecho desde hace mucho; eso por sí solo ya es bastante impresionante
Mythos no escribió pruebas de concepto para 271 vulnerabilidades ni demostró alcanzabilidad de rutas de código con impacto de seguridad. Mythos encontró 271 bugs válidos, y me parece que eso basta
Como contexto adicional, Mozilla aplica niveles de severidad de seguridad desde critical hasta low para indicar la urgencia de un bug. sec-critical y sec-high se asignan a vulnerabilidades que pueden activarse con acciones normales del usuario, como visitar una página web; técnicamente no distingue entre ambas, pero sec-critical se reserva para problemas divulgados públicamente o con explotación real conocida
sec-moderate se usa para vulnerabilidades que de otro modo serían sec-high pero que requieren pasos inusuales y complejos por parte de la víctima, y sec-low se aplica a bugs molestos alejados del daño al usuario, por ejemplo un crash seguro
De los 271 bugs anunciados en Firefox 150, 180 eran sec-high, 80 sec-moderate y 11 sec-low
Mozilla incluso usa la palabra “vulnerability” para sec-high, aunque justo debajo dice que no significa lo mismo que un exploit práctico. En su página de definiciones, incluso sec-low se clasifica como “vulnerabilities” [2]
Las palabras son herramientas, y su utilidad viene del significado compartido. Me da curiosidad de dónde se adoptó ese sistema de significados y si coincide con el de Mozilla o no
[1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
[2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
Bajo nuestros criterios, eso ya es evidencia práctica suficiente para considerarlos vulnerabilidades de seguridad salvo que haya evidencia en contra, y así es como siempre se han tratado los bugs encontrados por fuzzing
Mi única fuente es experiencia personal, y no puedo compartir pruebas
El blog no técnico anterior lo descarté como propaganda descarada de producto para Anthropic. El post enlazado en Mozilla Hacks es una fuente mejor que este artículo y una publicación agradecida
Ahora ya parece difícil negar que hubo resultados reales. La definición interna de “vulnerabilidad” en Mozilla parece usarse de forma más amplia de lo que mucha gente imaginaría intuitivamente, pero igual está bien que estos problemas se tomen en serio y se corrijan
Mythos sí es real, pero parece que Deepseek pro o GPT 5.5 también podrían hacer lo mismo
Fuente original: https://news.ycombinator.com/item?id=48051079
Es mejor porque enumera algunos reportes de Bugzilla realmente públicos. Este tema ya se había discutido antes, pero la parte de que los reportes de bugs ya fueran públicos sí es completamente nueva
La discusión anterior fue hace dos semanas y tuvo 36 comentarios: https://news.ycombinator.com/item?id=47885042
Ojalá llegue el día en que los LLM sean tan buenos encontrando y corrigiendo bugs que los ingenieros de Firefox puedan concentrarse solo en agregar funciones nuevas
No lo digo con sarcasmo. Firefox merece usarse más. La mayoría a mi alrededor no usa Firefox porque “Chrome hace casi todo mejor”, y a Firefox le cuesta competir con la hoja de ruta de los demás navegadores
A veces también escribo al soporte para decir que Firefox no está soportado o que una función no funciona bien. Casi nunca pasa nada, pero siento que es algo que puedo hacer para mantener al navegador dentro del campo de visión
Si la IA arregla todos los bugs, ¿qué trabajo quedará aparte de mantener la compatibilidad sintáctica con varios lenguajes de build? Al final parece que volverán a arruinar el navegador otra vez
Sería otra historia si Mozilla construyera un LLM o un harness propietario de uso interno y con eso se pusiera por delante de Chrome, pero tampoco suena muy realista
Mi esposa también usa Firefox como navegador principal desde que se lo expliqué y entendió cuánto puede cambiar la experiencia de internet
Así que preferiría que no se planteara esto como “los monopolios son malos y Google es medio malvado, así que usa al desvalido inferior”. En todo lo que le he aventado, Firefox me ha dado una experiencia de primera, y en móvil diría que tres veces más. De lejos, la mejor experiencia útil de navegador móvil
Solo hay unos cuantos tickets enlazados, así que quizá al ver los 271 elementos individuales reales cambie la cosa, pero los que revisé eran todos bugs graves en código C++
Firefox está escrito en varios lenguajes y C++ es solo alrededor del 25%, pero todos estos problemas parecen tocar C++
Habrá que ver si para problemas más sutiles se necesitan verificadores más específicos, o si el LLM irá mejorando por sí solo para imaginar otras condiciones de riesgo que se puedan verificar
A mi parecer, muchos de estos bugs no son tanto problemas exclusivos de C++, sino problemas que casualmente ocurrieron en código C++. Ni siquiera Rust, por muy seguro que sea, puede detectar mágicamente cosas como TOCTOU
Leer esto junto con la actitud de la gente de Zig, que ni siquiera quiere revisar bugs generados por LLM, me está cambiando la forma de pensar sobre qué tecnologías meter en mi toolchain en el futuro
Algunos proyectos están tan inundados de lo primero que necesitan salvaguardas para que no se vuelva un ataque de denegación de servicio de facto contra los mantenedores
Cuando estaba en PalmSource traté de conseguir presupuesto para herramientas de análisis estático de código como CoVerity o Fortify, pero la línea gerencial decía que “eran demasiado caras”
Me tardé otro año bajando el costo y limitando la propuesta al escaneo del stack de red, y entonces dijeron que “está basado en BSD y BSD es inherentemente seguro”. Ninguna de las dos cosas era cierta
Al final dejé la empresa y me fui a Mozilla, y había comentarios
/* flawfinder ignore */regados por todo el códigoMi sospecha es que Mythos simplemente ignoró las directivas
flawfinder ignorey reportó vulnerabilidades ya conocidas en el códigoMe pregunto qué impacto tendrá esto sobre las herramientas de análisis estático. El estilo es bastante distinto, pero a veces logran el mismo objetivo
Las herramientas de análisis estático pueden ser lentas y dar muchos falsos positivos. Si estos modelos se vuelven lo bastante buenos y baratos, me pregunto si la gente casi dejará de recurrir al análisis estático
Usar herramientas de codificación con LLM para ir limpiando la salida de herramientas de análisis estático funciona muy bien, y también es buena idea añadir guardrails que obliguen a no dejar problemas pendientes. Algo como una verificación de CI para confirmar que todo quedó limpio
Los falsos positivos dependen de la herramienta. Yo suelo evitar las que solo generan ruido, y normalmente esas mismas herramientas permiten desactivar las reglas más ruidosas. O también puedes pedirle al LLM que corrija todo. Si arreglarlo sale más barato que discutir con la regla, simplemente arréglalo. Antes era carísimo porque lo tenía que hacer una persona; ahora ya no tanto
Usé este enfoque hace poco al actualizar un codebase de Ansible que no tocaba desde hace años. Había cientos de problemas de ansible-lint, la mayoría advertencias de deprecación y advertencias no fatales; 10 minutos después eran 0. No eran problemas gravísimos, pero sí una especie de deuda técnica. Si tuviera que corregir manualmente cientos de advertencias, probablemente no lo haría; pero si con agitar una varita mágica desaparecen todas, no hay razón para no hacerlo. Ahora ajusté los guardrails para que siempre corran ansible-lint y corrijan los problemas, y solo toma unos segundos más
No hay duda de que las herramientas de análisis estático son más rápidas y baratas, así que escalan mejor a codebases enormes y quizá puedan generalizar el método del LLM
[0] https://lwn.net/Articles/1068968/
Yo mantengo una herramienta de análisis estático que se usa en el CI de Firefox. Para meter un parche en nuestro árbol, hay que corregir todo, ya sea falso positivo o positivo real, o marcarlo como algo que no es un problema. Es decir, exigimos tolerancia de 0 positivos, lo cual es un estándar bastante estricto
Es una concesión consciente. Para mantener una relación señal-ruido lo bastante alta como para que la gente no lo ignore, no lo llene de comentarios para silenciarlo o directamente deje de ejecutarlo, hay que debilitar el análisis y aceptar algunos falsos negativos. Casi todas las herramientas de análisis estático tienen que equilibrar eso
En cambio, a la IA de uso común se le da mucho más margen. Parece casi fundamental permitirle alucinar falsos positivos, y esa es parte importante de su poder. Por eso hacen falta varias capas de validación y verificación encima. Puede ser lento y no puedes decir “atrapa el 100% de esta forma específica de error”, pero aun así encuentra una cantidad enorme de cosas
Tengo un dato concreto. Mi análisis asumió erróneamente que había poca probabilidad de que apareciera un bug real y además parecía engorroso de implementar, así que no cubrí un caso. No sé si fue Opus o Mythos, pero empezó a reportar vulnerabilidades derivadas de ese caso, y yo corrí a ampliar el análisis para tapar ese hueco. Tomó bastante tiempo implementarlo y, para cuando escaneé todo el árbol de código, Claude ya había encontrado todos los problemas importantes que había reportado. El análisis estático encontró algunos más, pero todavía no sé honestamente si alguno de esos realmente puede activarse
Aun así, sigo creyendo que el análisis estático tiene valor. Algunas instancias del patrón problemático podrían ser alcanzables hoy por rutas demasiado complicadas para que la IA las construya. O podrían volverse problemas reales si cambia otro código. Por ambas posibilidades, parece valioso corregirlas todas desde ahora, y también por la razón menos importante de evitar que la IA desperdicie tiempo tratando de explotarlas. Al mismo tiempo, está claro que la relación costo-beneficio ya cambió
También podrían colaborar. Podría relajar mis criterios para que la herramienta de análisis produzca un reporte adicional de advertencias sobre problemas sospechosos, dejando explícito que se espera que puedan ser falsos positivos, y luego darle esa lista a la IA para que la valide. Básicamente sería alimentar slop a una máquina de slop para que filtre de forma no determinista las gemas en bruto
Da para pensarlo
En la película más reciente de Mission Impossible, para salvar al mundo hay que recuperar el software original de una AGI sobrehumana fugitiva desde un submarino ruso hundido
Luther escribe al instante una “poison pill” que acaba de un solo golpe con la IA en cuanto tiene el código fuente original. Me preguntaba cómo había escrito ese código mágico, y ahora ya lo sé. Luthor simplemente le pasó el código fuente a un prompt de Mythos y pidió un exploit fatal e inmutable
Me da curiosidad cómo ve la gente si en 5 años los LLM harán el software más seguro o menos seguro
Ya había una tendencia de migración manual a Rust antes de que aparecieran los LLM. Ahora, gracias a ellos, ese trabajo será más fácil y más rápido. El valor de largo plazo vendrá de limpiar la montaña de deuda técnica que representan los codebases heredados en C/C++. Ese código es responsable de la inmensa mayoría de los exploits de memoria, buffer overflows y otros problemas, y aun después de décadas de atención siguen apareciendo en codebases importantes
Que Mozilla encontrara estos problemas se apoya en el trabajo de ingenieros muy capaces que durante 25 años han intentado hacer lo correcto y han usado todas las herramientas disponibles para evitar que aparezcan. Tengo muchísimo respeto por ese equipo y por lo que han aportado durante años al mejorar herramientas, pruebas y prácticas de validación. El problema no es su esfuerzo ni su capacidad
Tomar un sistema heredado bien probado, bien documentado y con especificaciones claras para hacer una implementación de reemplazo drop-in ya empieza a ser algo revisable. Hace unos años eso habría implicado un costo y un riesgo de proyecto enormes; ahora es algo que puedes intentar empezar un viernes por la tarde. En el peor caso falla, y en el mejor consigues una implementación mucho mejor
Todavía estamos en una etapa temprana y el código generado por LLM tiene muchos problemas de calidad. Pero las tasas de éxito y de fracaso probablemente mejorarán con el tiempo
Cuando más gente tiene más herramientas, se terminan haciendo más cosas y de una variedad más amplia
Pero también significa que, para los proyectos que no apliquen estas herramientas, los black hats tendrán más facilidades para explotarlos
Opiniones en Lobste.rs
Ojalá también publicaran los prompts y otras funciones que usaron en este trabajo
Estaría bien incluir los prompts en los reportes de bugs o en el historial de soluciones para que se pueda reproducir
Como también mencionaron modelos que no son Mythos, parece que parte de este trabajo podría ser útil de inmediato para otras personas
Básicamente, basta con decir “revisa este proyecto desde la perspectiva de problemas de seguridad, empezando por (archivo), y enumera todas las rutas posibles”, y luego continuar con cada punto: “verifica este reporte y crea una prueba de concepto”
En este momento, usando Opus, es más difícil no encontrar algo con este método
Digan lo que digan, esto es realmente impresionante
Encontraron 271 problemas de seguridad con Mythos y 423 en total
De esos, 180 eran de alta severidad, y algunos problemas de seguridad tenían 20 años de antigüedad
Se sugiere algo como que Mythos encontró “271 bugs” en código que ya había sido escaneado antes de la misma manera con 4.6, pero el texto no dice exactamente eso
Me pregunto si el harness de investigación también cambió al mismo tiempo
La parte de “uno de los varios problemas sec-high que corregimos estaba relacionado con XSLT” parece estar ahí por la controversia sobre eliminar XSLT
Lo que más curiosidad me da aquí es cuántos falsos positivos también se reportaron
Me pregunto si el modelo reportó aproximadamente el doble de vulnerabilidades potenciales y si las que aparecen aquí son las confirmadas
Tampoco sé si el modelo llega a reproducirlas antes de reportarlas
En los issues públicos se ven comentarios que parecen intentar reproducirlas, aunque también podría ser un bot que ya existía
No sé bien cómo Firefox manejaba este tipo de cosas originalmente ni cómo lo hace ahora con IA, así que una explicación más detallada sería muy interesante