En un artículo anterior hablamos sobre un fallo que no puede ser solucionado en los procesadores Intel anteriores a los de décima generación y ahora en esta ocasión se dio a conocer un fallo que afecta a los procesadores AMD. Y es que un equipo de investigadores de la Universidad Tecnológica de Graz (Austria), anteriormente conocido por desarrollar métodos de ataque para MDS, NetSpectre, Throwhammer y ZombieLoad.

Ahora trabajaron para realizar una investigación sobre optimizaciones de hardware específicas de AMD y desarrolló dos nuevos métodos para atacar canales de terceros que manipulan fugas de datos durante la predicción de canales caché del primer nivel de procesadores AMD.

Los métodos se pueden usar para reducir la protección ASLR, restaurar claves en implementaciones AES vulnerables y aumentar la eficiencia del ataque Spectre.

En su investigación informan que identificaron problemas en la implementación del mecanismo de predicción de canal (predictor de forma) en la memoria caché de datos de la CPU de primer nivel (L1D), utilizada para predecir qué canal de la memoria caché se refleja una dirección de memoria específica.

La optimización utilizada en los procesadores AMD se basa en la verificación de etiquetas μ. μTag se calcula aplicando una función hash específica a la dirección virtual. Durante la operación, el mecanismo de predicción de canal usa μTag para determinar el canal de caché de la tabla.

Por lo tanto, μTag permite que el procesador se limite a acceder solo a un canal específico, sin enumerar todas las opciones, lo que reduce significativamente el consumo de energía de la CPU.

La vulnerabilidad se manifiesta en procesadores AMD basados ​​en microarquitecturas Bulldozer, Piledriver, Steamroller, Zen (Ryzen, Epic), Zen + y Zen2.

AMD fue notificado del problema el 23 de agosto de 2019, pero aún no ha publicado un informe con información sobre el bloqueo de la vulnerabilidad.

Según los investigadores, el problema puede bloquearse en el nivel de actualización de microcódigo al proporcionar bits MSR para deshabilitar selectivamente el sistema de predicción de canales, de forma similar a como lo hizo Intel para administrar el apagado de los mecanismos de predicción de transición.

Durante la ingeniería inversa de la implementación del sistema de predicción de canales en varias generaciones de procesadores AMD fabricados entre 2011 y 2019, se revelaron dos nuevas técnicas para atacar canales de terceros:

• Collide+Probe: permite a un atacante rastrear el acceso a la memoria para los procesos que se ejecutan en el mismo núcleo lógico de la CPU.
  La esencia del método es usar direcciones virtuales que causan colisiones hash de la función utilizada para calcular μTag para rastrear el acceso a la memoria. A diferencia de los ataques Flush+Reload y Prime+Probe utilizados en los procesadores Intel, Collide+Probe no utiliza memoria compartida y funciona sin conocer las direcciones físicas.
• Load+Reload: permite determinar con mucha precisión los rastros de acceso a la memoria en el mismo núcleo físico de la CPU. El método se basa en el hecho de que una celda de memoria física puede ubicarse en la caché L1D solo una vez.
  Es decir el acceso a la misma ubicación de memoria en una dirección virtual diferente forzará a la celda a salir de la caché L1D, lo que le permite rastrear el acceso a la memoria. A pesar de que el ataque depende de la memoria compartida, no restablece las líneas de caché, lo que hace posible llevar a cabo ataques ocultos que no desplazan los datos del caché de último nivel.

Basado en las técnicas Collide+Probe y Load+Reload, los investigadores demostraron varios escenarios de ataque a través de canales de terceros:

Se muestra la posibilidad de utilizar métodos para organizar un canal de comunicación indirecto oculto entre dos procesos, que permite transmitir datos a velocidades de hasta 588 kB por segundo.

Utilizando colisiones en μTag, fue posible reducir la entropía para diferentes variantes de la asignación aleatoria del diseño del espacio de direcciones (ASLR) y evitar la protección ASLR en el núcleo en un sistema Linux completamente actualizado.

Se muestra la posibilidad de un ataque para reducir la entropía ASLR tanto de las aplicaciones de usuario como del uso del código JavaScript ejecutado en el entorno sandbox y el código que se ejecuta en otro entorno invitado.

from Linux Adictos https://ift.tt/3333yHX
via IFTTT

Investigadores de Positive Technologies han identificado una nueva vulnerabilidad (CVE-2019-0090) que permite el acceso físico al equipo para extraer la clave raíz de la plataforma (la clave del chipset), que se utiliza como la raíz de la confianza en la autenticación de varios componentes de la plataforma, incluido TPM (firmware del Módulo de plataforma confiable) y UEFI.

La vulnerabilidad es causada por un error en el hardware y en el firmware Intel CSME, que se encuentra en la ROM de arranque, lo cual es bastante grave ya que este error no puede ser solucionado de ninguna manera.

La vulnerabilidad CVE-2019-0090 se refiere al motor de gestión y seguridad convergente (CSME) en la mayoría de las CPU Intel lanzadas en los últimos cinco años, siendo esas iteraciones de décima generación la excepción.

Es un gran problema porque proporciona las verificaciones criptográficas de bajo nivel cuando la placa base arranca, entre otras cosas. Es lo primero que se ejecuta al presionar el interruptor de encendido y la raíz de la confianza para todo lo que sigue.

Debido a la presencia de una ventana durante el reinicio de Intel CSME por ejemplo, al salir del modo de suspensión.

A través de manipulaciones con DMA, se pueden escribir datos en la memoria estática Intel CSME y cambiar las tablas de páginas de memoria Intel CSME ya inicializadas para interceptar la ejecución, extraer la clave de la plataforma y recibir control sobre la generación de claves de cifrado para módulos Intel CSME. Se planea publicar detalles de la explotación de la vulnerabilidad más adelante.

Además de extraer la clave, el error también permite la ejecución de código en el nivel de privilegio cero de Intel CSME (motor de seguridad y capacidad de administración convergentes).

Intel se dio cuenta del problema hace aproximadamente un año y en mayo de 2019 se lanzaron actualizaciones de firmware que, aunque no pueden cambiar el código vulnerable en la ROM, aun que segun informan que “están tratando de bloquear posibles rutas operativas a nivel de módulos Intel CSME individuales”.

De acuerdo con Positive Technologies, la solución solo cierra un vector de explotación. Creen que existen más métodos de ataque y algunos no requieren acceso físico.

“Podría haber muchas formas de explotar esta vulnerabilidad en la ROM, no todas requieren acceso físico, algunas solo acceso relacionado con malware local”.

Según Mark Ermolov, especialista principal de seguridad de SO y hardware en Positive Technologies, debido a su ubicación, la falla es similar al exploit ROM de arranque Checkm8 para dispositivos iOS que se reveló en septiembre y se considera un jailbreak permanente.

Entre las posibles consecuencias de obtener la clave raíz de la plataforma, se menciona la compatibilidad con el firmware del componente Intel CSME, el compromiso de los sistemas de cifrado de medios basados ​​en Intel CSME, así como la posibilidad de falsificar EPID (ID de privacidad mejorada) para pasar su computadora a otra para evitar la protección DRM.

En el caso de que los módulos CSME individuales se vean comprometidos, Intel ha proporcionado la capacidad de regenerar las claves asociadas con ellos utilizando el mecanismo SVN (Número de versión de seguridad).

En caso de acceso a la clave raíz de la plataforma, este mecanismo no es efectivo ya que la clave raíz de la plataforma se usa para generar una clave para el cifrado del Blob de valor de control de integridad (ICVB), cuyo recibo, a su vez, permite falsificar el código de cualquiera de los módulos de firmware Intel CSME.

Este podría ser el mayor problema al que se estaría enfrentando Intel, ya que problemas anteriores como specter o meltdown se han podido mitigar, pero este es un gran problema debido a que el fallo se encuentra en la ROM y como mencionan los investigadores este fallo no puede ser solucionado de ninguna forma.

Y aunque Intel este trabajando para poder “tratar de bloquear” las posibles rutas, hagan lo que hagan es imposible solucionar el fallo.

from Linux Adictos https://ift.tt/2TB1LGX
via IFTTT