Meltdown y Spectre, un resumen y chequeos
A continuación una explicación más detallada acerca del funcionamiento de Meltdown y Spectre que puede encontrarse en los papers oficiales publicados. Aquí mostramos aquí un breve resumen de ambos.
¿Qué es la out-of-order execution? Es una característica de los procesadores modernos (y por modernos nos referimos desde principios de los 90) que permite que cuando una instrucción en memoria llegue a la CPU, si los operandos de dicha instrucción no están disponibles, esta instrucción deje paso a la siguiente en cola para ser ejecutada más adelante. Anteriormente, lo que se hacía era inyectar una así llamada burbuja o bubble en el procesador, lo que quiere decir a grandes rasgos que se retrasa la ejecución de la instrucción sin dejar el paso, con el consecuente impacto en rendimiento.
Lo interesante es que se ha descubierto que en las operaciones ejecutadas mediante out-of-order las búsquedas en memoria utilizan la memoria caché. En un principio esto no representa un problema, dado que el mismo procesador realiza una comprobación de que el proceso tenga permiso para ver esos datos antes de entregárselos. Sin embargo, mediante un ataque de canal encubierto (covert channel) sobre la memoria caché, estos datos pueden ser accedidos. Es de esta manera como podemos ver incluso datos de nivel kernel desde un proceso sin permisos.
El remedio para esta vulnerabilidad pasa porque los sistemas operativos implementen una serie de contramedidas conocidas como KPTI (kernel page-table isolation o aislamiento de tablas de páginas del kernel), anteriormente conocidas como KAISER. Básicamente aísla de una manera diferente (mejor) la memoria de usuario y la memoria de kernel. Está plenamente implementada en Linux, y por lo visto también en Windows y Mac con las actualizaciones de este mes. En principio, Meltdown está parcheado.
Se ha hablado de que el parche aplicado ralentiza el procesador entre un 5 y un 30%. En principio, las últimas pruebas indican que el impacto a nivel general con los parches finales no es tan grave, aunque hay que tener en cuenta que nuevas comprobaciones al realizar accesos a memoria llevan inevitablemente a una ralentización.
Igual que la out-of-order execution, es una mejora en los procesadores modernos que permite mejorar el rendimiento. La predicción de saltos trata de, bajo ciertas condiciones, especular el resultado de una operación de salto cuyo destino depende de un valor en memoria que aún no se conoce, y ejecutar el código encontrado tal el salto especulado para ganar tiempo. Una vez se conoce el valor desconocido, se decide si continuar o descartar el resultado si ha fallado la predicción.
El problema viene cuando se induce a la víctima del ataque a realizar operaciones especulativas que normalmente no ocurrirían en la ejecución normal. Mediante diversas técnicas como ataques de canal laterales (side channel attacks), ataques de fallo (fault attacks) y return-oriented programming (ganar el control de la call stack para manipular el flujo del programa) pueden llegarse a leer posiciones aleatorias de la memoria de un proceso, posteriormente recuperadas de nuevo mediante un canal lateral. Las instrucciones ejecutadas una vez hecha la especulación y antes de comprobar su veracidad son llamadas instrucciones transitorias (transient instruction), dado que su resultado es potencialmente volátil a no ser que se confirme.
De nuevo, dado que en principio el procesador está diseñado para descartar el resultado de esta especulación en caso de ser errónea volviendo a un estado anterior, no parecía haber problemas de seguridad. El problema está de nuevo en que podemos llegar a leer la caché en la que se almacena, de nuevo utilizando un canal encubierto. Asusta leer en el paper (y demostrado en el mismo) que puede ser incluso explotado en un navegador mediante JavaScript.
El remedio no es tan "fácil" como en Spectre, dado que no puede ser directamente arreglado mediante software. Aquí viene el gran revuelo de la vulnerabilidad, dado que dependemos de que el mismo hardware de nuestro equipo sea compatible con las contramedidas, y no solamente de parchear el sistema operativo o nuestros programas. A día de hoy, muchos fabricantes han lanzado nuevo firmware y BIOS que permite que el sistema operativo active las contramedidas. Sin embargo, sigue habiendo un número enorme de dispositivos que, aun teniendo las contramedidas software instaladas, no pueden activarlas por falta de soporte del hardware. En este caso, no queda otra que consultar a nuestro fabricante acerca de cuándo sacará el nuevo firmware.
Microsoft ha lanzado un módulo para PowerShell que permite realizar comprobaciones acerca del estado de nuestro equipo respecto a las contramedidas. En la página enlazada podemos encontrar más datos e instrucciones, pero los comandos a ejecutar son los siguientes:
Salida de Get-SpeculationControlSettings sin soporte hardware En caso de que todo esté correctamente parcheado y el firmware proporcione soporte hardware:
Salida de Get-SpeculationControlSettings con soporte hardware En caso de Linux, podemos utilizar la herramienta spectre-meltdown-checker que podemos encontrar en GitHub, publicada por el usuario speed47. De forma muy similar al script de PowerShell anterior, nos avisa de si nuestro equipo es vulnerable a Spectre y Meltdown de forma simple.
Descargar y ejecutar el script es sencillo si habéis clonado proyectos de GitHub anteriormente. Por si acaso, los comandos a ejecutar son los siguientes:
Ejecución del script en un sistema vulnerable En caso de que tengamos el sistema actualizado, podemos tener un resultado variable dependiendo de nuestra distribución. El parche para remediar Meltdown está ya ampliamente disponible en el kernel oficial, pero se sigue trabajando en Spectre. Algunas distribuciones han integrado parches por su cuenta en sus kernel personalizados, pero dependerá mucho. Si solamente tenemos los parches para Meltdown, el resultado será algo parecido a esto:
Ejecución del script en un sistema con Meltdown parcheado En cuanto a ataques con navegador, tanto Chrome como Firefox han sacado actualizaciones para remediar Meltdown.
Fuente: Fwhibbit
Meltdown (CVE-2017-5754)
Meltdown [PDF] según el mismo paper, explota los efectos secundarios de la ejecución fuera de orden (out-of-order execution) y permite leer localizaciones arbitrarias en memoria, incluída la memoria de kernel, es decir, privilegiada y del propio sistema operativo. En la práctica, esto quiere decir que se puede conocer cualquier contenido en memoria, rompiendo el principio de aislamiento de la memoria entre procesos, sin siquiera necesitar permisos o privilegios de administración.¿Qué es la out-of-order execution? Es una característica de los procesadores modernos (y por modernos nos referimos desde principios de los 90) que permite que cuando una instrucción en memoria llegue a la CPU, si los operandos de dicha instrucción no están disponibles, esta instrucción deje paso a la siguiente en cola para ser ejecutada más adelante. Anteriormente, lo que se hacía era inyectar una así llamada burbuja o bubble en el procesador, lo que quiere decir a grandes rasgos que se retrasa la ejecución de la instrucción sin dejar el paso, con el consecuente impacto en rendimiento.
Lo interesante es que se ha descubierto que en las operaciones ejecutadas mediante out-of-order las búsquedas en memoria utilizan la memoria caché. En un principio esto no representa un problema, dado que el mismo procesador realiza una comprobación de que el proceso tenga permiso para ver esos datos antes de entregárselos. Sin embargo, mediante un ataque de canal encubierto (covert channel) sobre la memoria caché, estos datos pueden ser accedidos. Es de esta manera como podemos ver incluso datos de nivel kernel desde un proceso sin permisos.
El remedio para esta vulnerabilidad pasa porque los sistemas operativos implementen una serie de contramedidas conocidas como KPTI (kernel page-table isolation o aislamiento de tablas de páginas del kernel), anteriormente conocidas como KAISER. Básicamente aísla de una manera diferente (mejor) la memoria de usuario y la memoria de kernel. Está plenamente implementada en Linux, y por lo visto también en Windows y Mac con las actualizaciones de este mes. En principio, Meltdown está parcheado.
Se ha hablado de que el parche aplicado ralentiza el procesador entre un 5 y un 30%. En principio, las últimas pruebas indican que el impacto a nivel general con los parches finales no es tan grave, aunque hay que tener en cuenta que nuevas comprobaciones al realizar accesos a memoria llevan inevitablemente a una ralentización.
Spectre (CVE-2017-5753, CVE-2017-5715)
La segunda de estas vulnerabilidades es Spectre [PDF]. Este es algo más complicado que el anterior. Tal como el anterior explota una característica de los procesadores modernos, esto hace lo mismo con otras dos: la predicción de saltos (branch prediction) y la ejecución especulativa (speculative logic).Igual que la out-of-order execution, es una mejora en los procesadores modernos que permite mejorar el rendimiento. La predicción de saltos trata de, bajo ciertas condiciones, especular el resultado de una operación de salto cuyo destino depende de un valor en memoria que aún no se conoce, y ejecutar el código encontrado tal el salto especulado para ganar tiempo. Una vez se conoce el valor desconocido, se decide si continuar o descartar el resultado si ha fallado la predicción.
El problema viene cuando se induce a la víctima del ataque a realizar operaciones especulativas que normalmente no ocurrirían en la ejecución normal. Mediante diversas técnicas como ataques de canal laterales (side channel attacks), ataques de fallo (fault attacks) y return-oriented programming (ganar el control de la call stack para manipular el flujo del programa) pueden llegarse a leer posiciones aleatorias de la memoria de un proceso, posteriormente recuperadas de nuevo mediante un canal lateral. Las instrucciones ejecutadas una vez hecha la especulación y antes de comprobar su veracidad son llamadas instrucciones transitorias (transient instruction), dado que su resultado es potencialmente volátil a no ser que se confirme.
De nuevo, dado que en principio el procesador está diseñado para descartar el resultado de esta especulación en caso de ser errónea volviendo a un estado anterior, no parecía haber problemas de seguridad. El problema está de nuevo en que podemos llegar a leer la caché en la que se almacena, de nuevo utilizando un canal encubierto. Asusta leer en el paper (y demostrado en el mismo) que puede ser incluso explotado en un navegador mediante JavaScript.
El remedio no es tan "fácil" como en Spectre, dado que no puede ser directamente arreglado mediante software. Aquí viene el gran revuelo de la vulnerabilidad, dado que dependemos de que el mismo hardware de nuestro equipo sea compatible con las contramedidas, y no solamente de parchear el sistema operativo o nuestros programas. A día de hoy, muchos fabricantes han lanzado nuevo firmware y BIOS que permite que el sistema operativo active las contramedidas. Sin embargo, sigue habiendo un número enorme de dispositivos que, aun teniendo las contramedidas software instaladas, no pueden activarlas por falta de soporte del hardware. En este caso, no queda otra que consultar a nuestro fabricante acerca de cuándo sacará el nuevo firmware.
¿Cómo comprobar si soy vulnerable?
Primero queremos destacar que aunque se ha hablado mucho de la actualización de seguridad Intel-SA-00086 y de la herramienta que permite comprobar si somos vulnerables, las vulnerabilidades de las que habla dicha actualización no son estas, sino referentes a unos CVE anteriores. Por tanto, aunque viene bien comprobar las otras también, por supuesto, no nos sirve para este caso. La actualización Intel-SA-00088 sí que refiere a Spectre y Meltdown, pero no incluye herramienta de comprobación.Microsoft ha lanzado un módulo para PowerShell que permite realizar comprobaciones acerca del estado de nuestro equipo respecto a las contramedidas. En la página enlazada podemos encontrar más datos e instrucciones, pero los comandos a ejecutar son los siguientes:
PS> Install-Module SpeculationControl
PS> # Save the current execution policy so it can be reset
PS> $SaveExecutionPolicy = Get-ExecutionPolicy
PS> Set-ExecutionPolicy RemoteSigned -Scope Currentuser
PS> Import-Module SpeculationControl
PS> Get-SpeculationControlSettings
PS> # Reset the execution policy to the original state
PS> Set-ExecutionPolicy $SaveExecutionPolicy -Scope Currentuser
En caso de que tengamos la actualización instalada pero no tengamos soporte en el hardware y toque esperar a la actualización de nuestro firmware, aparecerá seguramente este resultado:Descargar y ejecutar el script es sencillo si habéis clonado proyectos de GitHub anteriormente. Por si acaso, los comandos a ejecutar son los siguientes:
git clone https://github.com/speed47/spectre-meltdown-checker.git
cd spectre-meltdown-checker
sudo sh spectre-meltdown-checker.sh
A continuación, en esta imagen vemos una salida de un equipo que aún no ha aplicado los parches necesarios:Fuente: Fwhibbit
Via: feedproxy.google.com
Meltdown y Spectre, un resumen y chequeos
Reviewed by Zion3R
on
8:19
Rating: