RingHopper, una vulnerabilidad en UEFI permite ejecución de código a nivel SMM

vulnerabilidad

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se divulgó información sobre una vulnerabilidad (ya catalogada bajo CVE- 2021-33164) detectada en el firmware UEFI, el fallo detectado permite ejecutar código en el nivel SMM (System Management Mode), que tiene una prioridad más alta que el modo hipervisor y el anillo de protección cero, y brinda acceso ilimitado a toda la memoria del sistema.

La vulnerabilidad, cuyo nombre en código es RingHopper, está relacionada con la posibilidad de un ataque de tiempo usando DMA (Acceso directo a la memoria) para corromper la memoria en el código que se ejecuta en la capa SMM.

Se puede lograr una condición de carrera que involucre el acceso y la validación de la SMRAM mediante ataques de temporización DMA que dependen de las condiciones de tiempo de uso ( TOCTOU ). Un atacante puede usar un sondeo oportuno para intentar sobrescribir el contenido de SMRAM con datos arbitrarios, lo que lleva a que el código del atacante se ejecute con los mismos privilegios elevados disponibles para la CPU (es decir, modo Ring -2 ). La naturaleza asíncrona del acceso a la SMRAM a través de los controladores DMA permite al atacante realizar dicho acceso no autorizado y eludir las verificaciones que normalmente proporciona la API del controlador SMI.

Las tecnologías Intel-VT e Intel VT-d brindan cierta protección contra los ataques de DMA mediante la Unidad de administración de memoria de entrada y salida (IOMMU) para abordar las amenazas de DMA. Aunque IOMMU puede proteger contra ataques de hardware DMA, los controladores SMI vulnerables a RingHopper aún pueden ser objeto de abuso.

Las vulnerabilidades se pueden explotar desde el sistema operativo utilizando controladores SMI vulnerables (Interrupción de administración del sistema), que requieren derechos de administrador para acceder. El ataque también puede llevarse a cabo si hay acceso físico en una etapa temprana del arranque, en una etapa anterior a la inicialización del sistema operativo. Para bloquear el problema, se recomienda a los usuarios de Linux que actualicen el firmware mediante el LVFS (Servicio de firmware del proveedor de Linux) mediante la utilidad fwupdmgr (fwupdmgr get-updates; actualización de fwupdmgr) del paquete fwupd .

La necesidad de tener derechos de administrador para realizar un ataque limita la peligrosidad del problema, pero no impide su uso como vulnerabilidad del segundo eslabón, para mantener su presencia tras la explotación de otras vulnerabilidades en el sistema o el uso de redes sociales métodos de ingeniería.

El acceso a SMM (Ring -2) permite ejecutar código a un nivel que no está controlado por el sistema operativo, que puede usarse para modificar el firmware y colocar código malicioso o rootkits ocultos en SPI Flash que no son detectados por el sistema operativo. , así como para deshabilitar la verificación en la etapa de arranque (UEFI Secure Boot, Intel BootGuard) y los ataques a los hipervisores para eludir los mecanismos de verificación de la integridad de los entornos virtuales.

El problema se debe a una condición de carrera en el controlador SMI (interrupción de administración del sistema) que se produce entre la verificación de acceso y el acceso a SMRAM. El análisis de canal lateral con DMA se puede utilizar para determinar el momento adecuado entre la verificación del estado y el uso del resultado de la verificación.

Como resultado, debido a la naturaleza asíncrona del acceso a la SMRAM a través de DMA, un atacante puede determinar el momento adecuado y sobrescribir el contenido de la SMRAM mediante DMA, sin pasar por la API del controlador SMI.

Los procesadores habilitados para Intel-VT e Intel VT-d incluyen protección contra ataques DMA basados ​​en el uso de IOMMU (Unidad de administración de memoria de entrada y salida), pero esta protección es eficaz para bloquear ataques DMA de hardware realizados con dispositivos de ataque preparados, y no no protege contra ataques a través de controladores SMI.

La vulnerabilidad ha sido confirmada en firmware de Intel, Dell e Insyde Software (se afirma que el problema afecta a 8 fabricantes, pero los 5 restantes aún no han sido revelados). El firmware de AMD, Phoenix y Toshiba no se ve afectado por el problema.

Fuente: https://kb.cert.org/

from Linux Adictos https://ift.tt/bvq4kdM
via IFTTT