Epsilon es un runtime de WebAssembly escrito en Go por Andrea Pivetta, diseñado para ejecutar código no confiable de forma aislada dentro de otras aplicaciones. Aunque es un intérprete relativamente pequeño de 11.000 líneas sin JIT, fue sometido a pruebas extensivas contra el testsuite oficial de WASM. Sorprendentemente, agentes de IA encontraron más de 20 vulnerabilidades de seguridad, incluyendo varias que permitían escapar del sandbox y acceder a estados privados de otros módulos.
El problema central radica en las suposiciones de diseño de Epsilon respecto al modelo de seguridad de WASM. En WebAssembly, los módulos deben estar completamente aislados: funciones, memorias y otros recursos privados no son accesibles desde fuera, salvo que se exporten explícitamente. El runtime confiaba en el validador de tipos para garantizar esta seguridad, representando internamente las referencias a funciones ('funcrefs') como enteros simples: -1 representa nulo y cualquier valor no negativo es un índice a la tabla global de funciones. Esta simplificación mejoraba el rendimiento, pero delegaba toda la seguridad al validador.
Los tres exploits documentados muestran cómo romper este aislamiento. El primero, 'Zero Is Not Null', aprovecha un error en la inicialización de variables locales: Go clear() establecía locales a 0 en lugar de -1 (el valor nulo real), permitiendo que una variable no inicializada apuntara a la primera función del store (índice 0) en vez de ser nula. El segundo combina dos bugs relacionados con la altura de la pila en bloques de control: el runtime grababa la altura después de consumir parámetros, mientras el validador lo hacía antes, causando una 'resurrección' de valores descartados que podían confundirse con referencias válidas. El tercer exploit, aunque no detallado completamente en el excerpt, sigue este mismo patrón.
Estos hallazgos son relevantes para cualquier desarrollador que implemente runtimes de lenguajes o trabaje con WebAssembly. Demuestran que incluso con especificaciones bien definidas y pruebas automatizadas, las suposiciones de implementación pueden introducir vulnerabilidades críticas. La lección principal: desconfiar de suposiciones implícitas sobre representación interna, validar en múltiples capas y considerar ataques que manipulen esquinas del sistema de maneras imprevistas.