El laboratorio FORGE de Microsoft identificó casos donde código safe Rust puede desencadenar comportamiento indefinido, exponiendo tres patrones recurrentes de confianza mal colocada en las bibliotecas estándar del lenguaje.
El laboratorio FORGE de Microsoft identificó múltiples problemas de seguridad de memoria en las bibliotecas estándar de Rust (std y core), incluyendo casos donde código escrito enteramente en safe Rust puede desencadenar undefined behavior — precisamente el tipo de falla que el lenguaje fue diseñado para prevenir. La investigación utilizó Hyenas, versión de investigación de MDASH, un sistema de escaneo de vulnerabilidades impulsado por IA. Los hallazgos revelan tres patrones recurrentes de confianza mal colocada en código unsafe: confiar en que el código no entre en pánico, confiar en implementaciones proporcionadas por el usuario, y confiar en el sistema subyacente. Al momento de la publicación, dos de los problemas reportados permanecen abiertos, aunque los mantenedores de Rust triaron y respondieron rápidamente.
Por qué importa ahora: Rust ya no es un experimento de nicho
Microsoft designó a Rust como lenguaje Tier-1 interno junto a C++, C# y TypeScript. GitHub reescribió el runtime del agente Copilot en Rust. Bun, Android, el kernel de Linux y Cloudflare están migrando código a Rust. Miles de millones de personas interactúan diariamente con software basado en Rust, a menudo sin saberlo. Mucho de ese software depende de las bibliotecas fundamentales core y std, y de las garantías de seguridad de las API que proveen. Bugs en esas bibliotecas pueden tener consecuencias que van mucho más allá del código donde se originan.
Las garantías de seguridad de memoria de Rust son precisamente lo que hace interesantes estos hallazgos. Su sistema de tipos y modelo de ownership descartan clases enteras de problemas de seguridad de memoria, pero gran parte de la biblioteca estándar depende de código unsafe debajo de sus API seguras. Cuando ese código rompe su contrato de seguridad, incluso el safe Rust puede encontrar comportamiento que el lenguaje fue diseñado para prevenir.
El problema estructural: unsafe Rust es más difícil de lo que parece
En el nivel más bajo, Rust usa bloques unsafe para trabajar con punteros raw e interactuar directamente con el sistema operativo. Gran parte de la biblioteca estándar, incluyendo Vec y String, está construida a partir de pequeñas piezas unsafe envueltas en API seguras. Dentro de un bloque unsafe, el programador asume responsabilidad por las garantías que el compilador no puede verificar, y esa responsabilidad se extiende a la API segura construida alrededor.
Esa API debe ser sound: sin importar cómo el código safe la use, debe ser imposible desencadenar undefined behavior. Mantener esa promesa es más difícil de lo que parece. El código unsafe debe ser cuidadoso con cada llamada que hace. Los bugs encontrados caen en tres patrones: confiar en que el código no entre en pánico (panic safety bugs), confiar en que implementaciones proporcionadas por el usuario sean correctas, y confiar en el sistema subyacente.
El primer patrón ocurre cuando código unsafe rompe un invariante por un momento y lo restaura después — por ejemplo, puede asignar un buffer no inicializado y llenarlo directamente, evitando escrituras redundantes para poner la memoria en cero primero. Eso funciona mientras la función corra hasta el final. Pero muchas operaciones en Rust pueden entrar en pánico, desde indexación fuera de límites hasta llamadas a código proporcionado por el usuario, y por defecto un panic unwinds: deja la función temprano mientras sigue ejecutando destructores. Unwinding dentro de esa ventana se convierte en una salida invisible que expone el invariante roto a código que confía en él.
Cómo la IA ayudó a encontrar lo que el análisis tradicional no vio
El equipo de Microsoft incluye a los creadores de Rudra, un analizador estático que buscó bugs de seguridad de memoria en el ecosistema Rust en 2021. Algunos de los bugs reportados fueron encontrados con ayuda de Hyenas. Los investigadores investigaron el código subyacente, reprodujeron los bugs, evaluaron su potencial impacto de seguridad, y trabajaron con los mantenedores de Rust para reportarlos y corregirlos.
La investigación se enfocó en bugs de soundness en el código unsafe de la biblioteca estándar. Bugs en el compilador mismo, como miscompilations y agujeros en el sistema de tipos, son un tema diferente que no se cubrió. El uso de herramientas asistidas por IA permitió investigar código y encontrar bugs difíciles de descubrir mediante análisis tradicional solo.
Qué significa para América Latina: dependencia sin visibilidad del riesgo
La adopción de Rust en infraestructura crítica de la región sigue el mismo patrón global: migración acelerada sin auditoría profunda de las bibliotecas base. Empresas de tecnología en Brasil, Argentina y México que adoptaron Rust para servicios de backend — especialmente en fintech y plataformas de pagos — dependen de las mismas bibliotecas std y core donde Microsoft encontró las fallas. La diferencia es que esas empresas rara vez tienen equipos con capacidad de auditar código unsafe a ese nivel, y mucho menos de contribuir fixes upstream.
El riesgo no es teórico: si una falla de panic safety o de confianza en implementaciones de usuario se activa en producción, el comportamiento indefinido resultante puede derivar en corrupción de memoria, bypass de validaciones de seguridad, o exposición de datos sensibles. En contextos donde Rust se eligió precisamente por sus garantías de seguridad — reemplazando C++ en componentes críticos — la falsa sensación de inmunidad puede retrasar la detección de problemas hasta que ya estén en producción.
Nuestro análisis
Este caso revela una tensión estructural en el modelo de seguridad de Rust: las garantías del lenguaje son reales, pero dependen de que el código unsafe en las bibliotecas base mantenga sus contratos de seguridad sin fallas. Esos contratos son difíciles de verificar formalmente y fáciles de romper con suposiciones incorrectas sobre panic, sobre implementaciones de traits proporcionadas por el usuario, o sobre el comportamiento del sistema operativo subyacente. Microsoft encontró estos bugs usando herramientas de IA porque el análisis estático tradicional no alcanza a cubrir todas las combinaciones de estados posibles en código unsafe complejo.
Lo que todavía no se sabe es cuántos bugs de este tipo permanecen sin descubrir en bibliotecas de terceros del ecosistema Rust — crates ampliamente usados que también contienen código unsafe y que no reciben el mismo nivel de escrutinio que std y core. La comunidad Rust tiene un historial sólido de respuesta rápida a reportes de seguridad, pero la superficie de ataque crece con cada migración de código crítico al lenguaje. Si las herramientas de análisis asistido por IA se vuelven necesarias para encontrar bugs que el análisis humano y las herramientas tradicionales no detectan, ¿cuántas organizaciones en la región tienen acceso a esas capacidades antes de que un bug se active en producción?