Este artículo demuestra un devastador ataque de sincronización de caché basado en Javascript que permite el seguimiento de VM cruzado de movimientos del mouse y otros Actividades por páginas web.
Es la única forma de evitar que el kernel (1) realice una búsqueda basada en caché para que nunca ejecute procesos desconfiados mutuamente en el mismo CPU al mismo tiempo y (2) vacíe todos los cachés en todos los cambios de contexto entre desconfianza mutua procesos?
¿Leyó las páginas 11 y 12 de este documento, capítulo 5.1, sobre Prevalencia de sistemas vulnerables y 5.2: Contramedidas ?
Si su sistema es realmente vulnerable, entonces sí, debe vaciar el caché de información sensible antes de acceder a las páginas web sospechosas.
Pero si su herramienta criptográfica usa memoria no almacenada en caché , no son vulnerables ...
Puede usar una CPU de un solo núcleo o que no sea Intel ... o asegurarse de que no se utilicen en su hardware, ni Sandy Bridge ni Ivy Bridge, ni microarquitecturas de Broadwell.
Y mantenga sus servidores basados en Intel lejos de JavaScript optimizado.
Para mi comprensión, este documento es más una prueba de concepto que un libro de recetas de exploits .
Quiero decir, si esto fue posible en esta configuración específica, mediante el uso de este método y un javascript optimizado, debemos tener en cuenta que:
Es posible un ataque de caché.
Independientemente del requisito para la demostración this
De hecho, los nuevos procesadores de varios núcleos están insuficientemente protegidos, debido a los retos de rendimiento.
Y una nueva optimización a nivel de bibliotecas podría hacer que algunos backdoor desatendidos .
Este exploit es difícil de reproducir, pero muestra que si a los procesadores no les importa, el futuro podría volverse peligroso.
Lea otras preguntas en las etiquetas data-leakage timing-attack side-channel