FROST: el ataque que transforma el navegador en espía midiendo la latencia del SSD para revelar tus sitios y tus apps

Un nuevo ataque bautizado como FROST, descrito por investigadores de la Universidad Tecnológica de Graz y presentado en DIMVA 2026, demuestra que una página web maliciosa puede saber qué sitios visitas y qué aplicaciones abres simplemente midiendo la latencia de un SSD desde JavaScript. La novedad no es que los discos SSD filtren información —esa familia de errores ya incluía investigaciones como Secret Spilling Drive— sino que FROST elimina la necesidad de código nativo o permisos explícitos: todo corre en el sandbox del navegador y se aprovecha de una API estandarizada llamada Origin Private File System (OPFS), diseñada para que aplicaciones web gestionen archivos locales sin pedir permisos al usuario.

El vector técnico es sencillo y preocupante en su eficacia. OPFS permite a cada origen web reservar y escribir ficheros en una porción del disco sin interacción del usuario. Un atacante crea un archivo mayor que la RAM del equipo para forzar lecturas directas al SSD en lugar de hits en la caché de página, y luego ejecuta lecturas aleatorias de bloques de 4 KB midiendo el tiempo con los relojes de alto resolución. Cuando otro sitio se carga o una app arranca, la contención del disco altera esos tiempos y un clasificador entrenado puede identificar con alta precisión qué software o página generó la perturbación. En los experimentos reportados, la inferencia contra las 50 webs más populares alcanzó puntuaciones F1 cercanas al 89% en macOS y fue aún más efectiva al identificar aplicaciones nativas; además, los investigadores montaron un canal encubierto capaz de transferir cientos de bits por segundo entre una app nativa cooperante y la página maliciosa.

Si bien la técnica se basa en un canal de tiempo físico —algo que la comunidad de seguridad conoce desde hace años—, la transformación de un ataque local a uno remoto es lo que altera el panorama: basta con que un usuario visite o deje abierta una pestaña para que el sitio observe la actividad en su equipo. Esto cambia el riesgo, especialmente en equipos de un solo disco, donde todo reside en la misma unidad; las máquinas con múltiples discos o configuraciones que mantienen el perfil del navegador en RAM (por ejemplo, ciertos despliegues con profile-sync-daemon en Linux) limitan la superficie, pero esas no son soluciones universales.

Las opciones de mitigación prácticas hoy para un usuario son limitadas pero útiles. Cerrar pestañas sospechosas detiene inmediatamente la medición, y vigilar el almacenamiento del navegador para detectar archivos extraordinariamente grandes vinculados a orígenes desconocidos es una indicación de compromiso. Desactivar JavaScript para sitios no confiables o usar extensiones de bloqueo de scripts reducirá la exposición, así como usar navegadores configurados con perfiles separados o ejecutar actividad sensible en máquinas virtuales o en un navegador dedicado solo para tareas críticas. Para administradores, aislar procesos en discos distintos o usar políticas que eviten que el perfil se escriba en disco puede ser una defensa eficaz mientras llegan parches.

Las correcciones definitivas, sin embargo, dependen de los fabricantes de navegadores. Entre las soluciones técnicas posibles están limitar el tamaño máximo que OPFS puede reservar por origen para que quepa en la caché, añadir un cuadro de permiso para el uso intensivo del almacenamiento local, o degradar la resolución temporal cuando OPFS esté en uso. Cada alternativa tiene un coste en usabilidad o rendimiento, por eso los proveedores han de ponderar el impacto: Google, Apple y Mozilla fueron avisados antes de la publicación y hasta ahora no ha habido una acción uniforme ni un CVE público que aglutine la cuestión.

Desde una perspectiva más amplia, FROST subraya una tendencia: el navegador sigue ampliando las capacidades nativas que ofrece a las aplicaciones web, y con ellas crecen las vías de fuga de información de bajo nivel. Esta no es solo una vulnerabilidad aislada sino una lección de diseño: las API que otorgan acceso cercano al hardware requieren evaluaciones de privacidad y riesgos de canal lateral tan rigurosas como las que se aplican a interfaces de seguridad tradicionales. Mientras tanto, los usuarios y organizaciones deben asumir que dejar pestañas abiertas con confianza implícita implica un riesgo y adoptar defensas que reduzcan la exposición hasta que los navegadores implementen mitigaciones.

Para quienes quieran profundizar en la tecnología afectada, la especificación de OPFS del WICG describe por qué la API se diseñó sin diálogos de permisos: Origin Private File System (WICG). La conferencia donde se presenta el trabajo y el contexto académico del área pueden consultarse en la página de DIMVA: DIMVA. También es útil revisar cómo las interfaces de E/S nativas como io_uring influyeron en investigaciones previas sobre filtrado por disco: io_uring — Linux kernel documentation.