Google: el software nunca podrá solucionar errores de tipo Spectre

0
578
Spectre bugs

Investigadores de Google que investigan el alcance y el impacto del ataque de Specter han publicado un artículo que afirma que las vulnerabilidades similares a Specter probablemente sean una característica continua de los procesadores y, además, que las técnicas basadas en software para protegerse de ellas impondrán un alto costo de rendimiento. En cualquier caso, continúan los investigadores, el software será inadecuado: algunas fallas de Specter no parecen tener una defensa efectiva basada en software. Como tal, Specter será una característica continua del panorama informático, sin una resolución directa.

El descubrimiento y desarrollo de los ataques Meltdown y Spectre fue, sin duda, la gran historia de seguridad de 2018. Primero se reveló en enero pasado, luego se hicieron nuevas variantes y descubrimientos relacionados durante el resto del año. Ambos ataques se basan en discrepancias entre el comportamiento arquitectónico teórico de un procesador, el comportamiento documentado del que dependen los programadores y contra el que escriben sus programas, y el comportamiento real de las implementaciones.

Específicamente, todos los procesadores modernos realizan ejecuciones especulativas; hacen suposiciones acerca de, por ejemplo, un valor que se lee de la memoria o si una condición if es verdadera o falsa, y permiten que su ejecución se ejecute en función de estas suposiciones. Si las suposiciones son correctas, los resultados especulados se mantienen; Si no lo es, los resultados especulados se descartan y el procesador rehace el cálculo. La ejecución especulativa no es una característica arquitectónica del procesador; es una característica de las implementaciones, por lo que se supone que es completamente invisible para ejecutar programas. Cuando el procesador descarta la mala especulación, debe ser como si la especulación nunca hubiera ocurrido.

Pasos dejados atrás

Lo que descubrieron los investigadores de Meltdown y Specter es que la ejecución especulativa no es del todo invisible y que, cuando el procesador descarta los resultados especulados, queda alguna evidencia de la mala especulación. Por ejemplo, la especulación puede cambiar los datos almacenados en el caché del procesador. Los programas pueden detectar estos cambios midiendo el tiempo para leer los valores de la memoria.

Con una construcción cuidadosa, un atacante puede hacer que el procesador especule en función de algún valor de interés y usar los cambios de caché para revelar lo que realmente fue ese valor especulado. Esto se vuelve particularmente amenazante en aplicaciones como los navegadores web: un JavaScript malintencionado puede usar los datos revelados de esta manera para conocer el diseño de memoria del proceso en el que se está ejecutando y luego usar esta información para aprovechar otras fallas de seguridad para ejecutar código arbitrario. Los desarrolladores de navegadores han asumido que pueden construir espacios seguros dentro del proceso del navegador, por lo que los scripts no pueden aprender sobre el diseño de memoria de su proceso de contención. Arquitectónicamente, esas suposiciones son sólidas. Pero la realidad tiene Specter, y elimina esas suposiciones fuera del agua.

El ataque Meltdown, enfrentado por chips de Intel, Apple y otros fabricantes que construyen ciertos diseños ARM estándar, fue una variante particularmente desagradable de esto. Permitió que un programa malicioso extrajera datos del kernel del sistema operativo. Inmediatamente después del descubrimiento de Meltdown, se realizaron cambios en los sistemas operativos para ocultar la mayor parte de sus datos de dichos programas maliciosos. Intel ha realizado cambios específicos en sus procesadores para hacer frente a Meltdown, por lo que sus procesadores más recientes ya no necesitan activar estos cambios en el sistema operativo.

Un nombre apropiado

Pero Specter, que es mejor considerado como un estilo particular de ataque, con muchas variantes e iteraciones diferentes, ha demostrado ser más insidioso. Se ha ideado una variedad de técnicas de software para evitar que el procesador ejecute código sensible de forma especulativa o para limitar la información que puede revelarse mediante la ejecución especulativa.

La investigación de Google encontró que estas medidas de software dejan mucho que desear. Algunas medidas, como bloquear todas las especulaciones después de cargar valores de la memoria, protegen contra muchos ataques pero son demasiado debilitantes para usar en la práctica. Los investigadores estaban experimentando con versiones modificadas del motor V8 JavaScript de Chrome, y el uso indiscriminado de esta técnica hizo que el rendimiento cayera entre un tercio y un quinto de lo que era sin mitigación. Otras mitigaciones fueron menos punitivas: por ejemplo, la protección de los accesos de un determinado tipo de divulgación tuvo un costo de rendimiento del 10 por ciento.

Pero en todos los casos hubo concesiones; La mitigación no está protegida contra todas las variantes de Spectre, por lo que se debe utilizar una combinación de técnicas, y para las técnicas que no se pueden usar de manera indiscriminada, existe un gran desafío incluso para identificar dónde se deben aplicar las mitigaciones. Además, Google ideó un ataque de la familia Specter de propósito general que no podía ser derrotado con ninguna de las técnicas de mitigación conocidas.

Un elemento importante de los ataques de Specter es un sistema de tiempo para medir los cambios de caché. Una de las ideas que las personas han tenido para contrarrestar a Specter es hacer que los relojes estén disponibles para las aplicaciones con menos precisión. La teoría de trabajo es que, si necesita medir diferencias de caché que duren unos nanosegundos, el reloj que tiene una resolución de, por ejemplo, milisegundos será demasiado aproximado. Los investigadores idearon una técnica para amplificar pequeñas diferencias de tiempo, y esta amplificación puede vencer cualquier intento de hacer que los temporizadores se vuelvan más gruesos.

Sin final a la vista

Como tal, la compañía concluyó que no podemos depender de las correcciones de software para protegernos contra Specter. La mitigación del hardware podría ser posible, pero esta es actualmente una pregunta abierta: a diferencia de Meltdown, que tenía una resolución clara, Specter parece ser mucho más intrínseco a la ejecución especulativa. Y abandonar la ejecución especulativa tampoco es una opción; es una característica de cada procesador de alto rendimiento, y con una buena razón, brinda una ventaja de rendimiento sustancial.

Por ahora, entonces, las aplicaciones que intentan construir entornos seguros tendrán que confiar en las garantías que ofrece el hardware: la protección entre procesos. Por ejemplo, Chrome se ha modificado para no permitir que el contenido de varios dominios se ejecute dentro del mismo proceso. Esto todavía no protege al recinto de seguridad de Chrome del ataque mediante scripts, pero sí significa que un script no puede atacar el contenido de otros dominios.

Con todo, la investigación muestra que Specter fue nombrado apropiadamente. Va a perseguir a los desarrolladores de software y hardware en los próximos años, y no hay un final claro a la vista.