El regreso de Spectre suena como la próxima película de James Bond, pero en realidad es el descubrimiento de dos nuevos ataques de CPU estilo Spectre.
Vladimir Kiriansky, un candidato en el MIT, y el investigador independiente Carl Waldspurger encontraron los últimos dos agujeros de seguridad. Desde entonces, han publicado un documento de MIT, Desbordamientos de búferes especulativos: ataques y defensas, que repasa estos errores con gran detalle. En conjunto, estos problemas se denominan “ataques especulativos de canal lateral”.
Estos descubrimientos en realidad no pueden ser una sorpresa. Spectre y Meltdown son una nueva clase de agujeros de seguridad. Están profundamente integrados en el diseño fundamental de las generaciones recientes de procesadores. Para ir más rápido, los chips modernos usan una combinación de canalización, ejecución fuera de orden, predicción de bifurcación y ejecución especulativa para ejecutar la siguiente rama de un programa antes de invocarlo. De esta forma, no se desperdicia tiempo si su aplicación sigue ese camino. Desafortunadamente, Specter y Meltdown ha demostrado que las implementaciones de los fabricantes de chips utilizadas para maximizar el rendimiento tienen fallos de seguridad fundamentales.
Desde los descubrimientos iniciales de Spectre y Meltdown, se han encontrado muchos otros agujeros de estilo espectral. En su última investigación, Kiriansky y Waldspurger descubrieron dos nuevos problemas de seguridad: Spectre 1.1 y Spectre 1.2.
Spectre 1.1 utiliza almacenes de datos especulativos para crear desbordamientos de búfer especulativos. Al igual que los clásicos ataques de desbordamiento de búfer, las bases especulativas fuera de límites pueden cambiar los datos y puntos de código. Peor aún, tales ataques pueden eludir algunas mitigaciones de Spectre originales, ya sea directamente o redirigiendo el flujo de control. Los ataques de flujo de control permiten la ejecución de código especulativo arbitrario, que a su vez puede eludir otras mitigaciones de software para ataques previos de ejecución especulativa. Para colmo de males, los investigadores informan que “es fácil construir gadgets orientados a la devolución (ROP) que se pueden usar para construir cargas alternativas de ataque”.
Spectre 1.2 puede dañar las CPU que no hacen cumplir las protecciones de lectura / escritura. Con esto, las bases especulativas pueden sobrescribir los datos de solo lectura y los puntos de código para abrir brechas. Con esta habilidad, un atacante puede poseer una máquina.
Intel ha agradecido a Kiriansky y Waldspurger por informar sobre las nuevas vulnerabilidades al fabricante de chips. La compañía ha pagado a Kiriansky 100,000 dólares a través de su programa HackerOne bug bounty.
Entonces, ¿qué puedes hacer con estos ataques? Prepárate para hacer una gran cantidad de reprogramación.
Esto no será fácil. Los investigadores afirman que no hay herramientas de programación, como el análisis estático o la instrumentación del compilador, que genéricamente detectan o mitigan Spectre 1.1.
De hecho, “si tenemos que confiar en las mitigaciones del software que requieren que los desarrolladores razonen de forma manual sobre la necesidad de mitigación, podemos enfrentar décadas de ataques de ejecución especulativa”.
No son optimistas después de todo, el primer gusano informático, el infame gusano Morris, tiene 30 años y usó un desbordamiento de búfer para eliminar gran parte del Internet temprano. Hoy, todavía vemos agujeros de seguridad de desbordamiento de búfer que aparecen en los programas.
Aún así, “El lado positivo es que los mismos patrones de codificación son vulnerables a los desbordamientos de búfer especulativos. Un buen primer paso para prevenirlos sería fortalecer las comprobaciones existentes contra desbordamientos de pila, desbordamientos de pila, desbordamientos de enteros, etc.” Todavía podemos estar lejos de ser perfectos para mitigar los desbordamientos del búfer, pero al menos sabemos cómo debemos solucionarlos.
Intel agrega: “Estos dos métodos de ataque pueden mitigarse modificando el software mediante la inserción de una instrucción de serialización para restringir la especulación en diputados confundidos. Dichas instrucciones aseguran que todas las instrucciones en la tubería de instrucciones del procesador se resuelvan antes de las instrucciones posteriores. en la tubería puede ejecutarse. Esto evita que el procesador tenga acceso especulativo a datos a los que el usuario no debería tener acceso, porque no se pueden ejecutar operaciones especulativas hasta que la operación de verificación de límites finalice “.
En resumen, obtendrás un programa más lento, ya que este método bloquea todas las operaciones especulativas, pero serás mucho más seguro.
ARM afirma que “la mayoría de los procesadores ARM no se ven afectados por ninguna variación de este mecanismo de especulación de canal lateral”. Dicho esto, “este método depende del malware que se ejecuta localmente, lo que significa que es imperativo que los usuarios practiquen una buena seguridad de la seguridad al mantener su software actualizado y evitar enlaces sospechosos o descargas”.
AMD aún no ha dicho qué, si es que tiene alguno de sus chips, es vulnerable y qué debe hacer al respecto si lo es.
Las compañías de sistemas operativos también están en la pelota. “Microsoft ha lanzado actualizaciones para ayudar a mitigar estas vulnerabilidades. Para obtener todas las protecciones disponibles, se requieren firmware (microcódigo) y actualizaciones de software. Esto puede incluir microcódigo de OEM de dispositivos y en algunos casos actualizaciones de software AV también. En algunos casos, la instalación estas actualizaciones tendrán un impacto en el rendimiento. También hemos tomado medidas para proteger nuestros servicios en la nube “.
Windows no será el único sistema operativo para ver un golpe de rendimiento. Todos los sistemas operativos verán ralentizaciones. ¿Cuánto cuesta? No lo sabemos todavía
Red Hat informa que la ejecución especulativa de los ataques de canal lateral afecta al kernel Linux utilizado en Red Hat Enterprise Linux (RHEL) 5, 6 y 7. Esto sugiere que casi todas las distribuciones Linux modernas son vulnerables. Los desarrolladores del kernel de Linux ya están trabajando en parches para el problema.
Cuando los parches y el microcódigo estén fuera, actualizar los sistemas. Por ahora, no hay ataques conocidos que usen estos errores. Eso no será cierto por mucho tiempo.
