Una explotación por corrupción de memoria no siempre necesita sustituir el flujo de control de un programa por instrucciones escritas por un atacante. En un ataque basado solo en datos, el atacante cambia un valor que el programa tratará más tarde como legítimo —como una ruta, un indicador de permisos, un nombre de archivo o un argumento de comando—, mientras el programa continúa ejecutando su código normal. Un artículo de USENIX del 1 de julio de 2024 presenta Einstein, una herramienta de investigación destinada a encontrar y validar automáticamente estas rutas, y cuestiona el supuesto de que este tipo de ataques son demasiado especializados o requieren demasiado trabajo para ser prácticos.
El gráfico oficial del artículo de USENIX identifica la fuente de investigación discutida a lo largo del texto.
La distinción es importante porque las defensas habituales se concentran en gran medida en impedir el secuestro del flujo de control. Defensas como DEP y la integridad del flujo de control buscan evitar que un atacante redirija la ejecución o ejecute código inyectado. Un ataque basado solo en datos puede preservar el flujo de control previsto por el programa y aun así provocar un comportamiento perjudicial al cambiar los datos que consume una operación ya aprobada. El resultado no es una evasión de la seguridad de memoria; es una consecuencia distinta de un fallo de escritura en memoria.
El artículo ilustra esto con un ejemplo simplificado de un servidor web. El servidor normalmente combina un directorio CGI configurado con el nombre de un script solicitado e invoca el sistema operativo mediante `execve`. Si un fallo de seguridad de memoria permite que un cliente sobrescriba la variable del directorio con `/bin`, una solicitud posterior de `/sh` puede hacer que el servidor ejecute el intérprete de comandos del sistema. El servidor sigue realizando la misma secuencia de operaciones, pero sus datos de confianza convierten ahora una operación ordinaria en una acción peligrosa.
El enfoque propuesto por Einstein es deliberadamente independiente de la aplicación. En lugar de modelar todos los protocolos o reglas de negocio, instrumenta un programa a nivel binario, marca los datos que un atacante podría corromper y observa si esos datos llegan a los argumentos de llamadas al sistema sensibles desde el punto de vista de la seguridad. Los autores denominan “flujo de datos de identidad” a una relación particularmente sencilla en la que los datos controlados por el atacante se copian literalmente en un argumento sensible. Einstein genera después una sobrescritura de memoria candidata y reinicia el programa para confirmar que el candidato funciona realmente.
Esa fase de confirmación es importante. Que un valor marcado como no fiable llegue a una llamada al sistema no demuestra automáticamente que sea explotable: una validación posterior, el aislamiento o la lógica de la aplicación pueden bloquear el efecto previsto. Por ello, los autores de la herramienta distinguen entre la generación de candidatos y la confirmación de una explotación funcional. Esto hace que el resultado sea más sólido que una advertencia estática, pero también significa que la evidencia se refiere a rutas y cargas de trabajo probadas, no a todas las rutas de ataque posibles.
El artículo de USENIX afirma que la evaluación se dirigió a `httpd`, `lighttpd`, `nginx`, `postgres` y `redis`, y que utilizó sus suites de pruebas para generar cargas de trabajo. También dice que se confirmaron exploits candidatos para nginx. Esos detalles muestran que los investigadores estaban mirando más allá de un ejemplo de juguete y hacia software de servidor ampliamente desplegado. Sin embargo, el texto suministrado no establece que todos los productos enumerados sean actualmente vulnerables, que una versión desplegada específica sea explotable o que las rutas de las suites de pruebas representen las rutas más importantes en las configuraciones de producción.
La pregunta operativa más útil no es simplemente si un ataque evita el código malicioso. Es qué valores de confianza son críticos para la seguridad después de una escritura en memoria. Una ruta utilizada por `execve`, un nombre de archivo pasado a `write` o un valor relacionado con privilegios que se consuma más tarde pueden convertir una ruta de código por lo demás ordinaria en una acción de alto impacto. Por eso el análisis de flujo de datos es relevante: ayuda a rastrear cómo se mueven los bytes corruptibles a través de un programa y dónde adquieren significado operativo.
La evidencia también tiene límites. El artículo está escrito por los investigadores que desarrollaron Einstein, por lo que respalda directamente su descripción del método y la evaluación, pero no constituye una auditoría de seguridad independiente de todos los objetivos. El material suministrado no proporciona código de explotación, listas de versiones afectadas, avisos de proveedores ni una comparación reproducible con otras herramientas de análisis. Por tanto, respalda una conclusión centrada: la explotación basada solo en datos merece atención como una clase distinta de consecuencia de la falta de seguridad de memoria, especialmente cuando los argumentos sensibles de las llamadas al sistema son accesibles desde estado que un atacante puede corromper.
Para los defensores, la implicación práctica es combinar las protecciones del flujo de control con comprobaciones de los datos sensibles y de los límites de las llamadas al sistema. La seguridad de memoria sigue siendo el problema de raíz, pero evitar la ejecución de código no es lo mismo que evitar el uso perjudicial de código legítimo. El valor de Einstein consiste en hacer visible y comprobable una clase de flujos de datos peligrosos; no demuestra que todos los ataques basados solo en datos sean fáciles ni que cualquier fallo de seguridad de memoria pueda weaponizarse.