Los investigadores demuestran una falla de seguridad AMD SEV en los procesadores Epyc Rome y Milan

Los investigadores demuestran una falla de seguridad AMD SEV en los procesadores Epyc Rome y Milan

La virtualización cifrada segura (SEV) de AMD es uno de los aspectos más destacados de los procesadores Epyc de AMD. Básicamente, ofrece protección a las máquinas virtuales en entornos que no son de confianza a través de la memoria y el cifrado de registros. Al aprovechar un procesador seguro AMD (AMD-SP) separado para ejecutar operaciones sensibles, los ataques a los núcleos x86 primarios son menos efectivos. A diferencia de las extensiones de protección de software (SGX) de Intel, que se centran en proteger partes de una aplicación, SEV protege las máquinas virtuales completas.

La protección en tiempo de ejecución de las máquinas virtuales se logra mediante el cifrado transparente de la memoria de una máquina virtual. La función de atestación remota de SEV permite a los clientes de la nube validar la implementación correcta de la VM. Desde su introducción en 2016, AMD ha introducido dos extensiones de SEV que agregan funciones de protección adicionales a SEV. Si bien SEV-ES agrega cifrado para los registros de máquinas virtuales invitadas, SEV-SNP presenta, entre otros, protección de integridad basada en software y un Trusted
Función de control de versiones de Computing Base (TCB) para Chip Endorsement Key (CEK).

El CEK vincula criptográficamente la plataforma de destino a la raíz de confianza de AMD. Tanto la protección en tiempo de ejecución como la función de atestación remota requieren que el hipervisor utilice una interfaz proporcionada por un firmware dedicado que se ejecuta en AMD-SP. El firmware de SEV es responsable de administrar las claves de cifrado de memoria de las VM y de implementar la función de atestación remota de SEV.

Este documento presenta un nuevo enfoque para atacar las máquinas virtuales (VM) protegidas por SEV dirigidas a AMD-SP. Presentamos un ataque de falla de voltaje que permite a un atacante ejecutar cargas útiles personalizadas en los AMD-SP de todas las microarquitecturas que admiten SEV actualmente en el mercado (Zen 1, Zen 2 y Zen 3). Los métodos presentados nos permiten implementar un firmware SEV personalizado en el AMD-SP, que permite a un adversario descifrar la memoria de una máquina virtual. Además, utilizando nuestro enfoque, podemos extraer claves de respaldo de CPU habilitadas para SEV, lo que nos permite falsificar informes de atestación o hacernos pasar por un objetivo válido para la migración de VM sin necesidad de acceso físico al host de destino. Además, aplicamos ingeniería inversa al mecanismo de clave de aprobación de chip versionado (VCEK) introducido con SEV Secure Nested Paging (SEV-SNP). El VCEK vincula las claves de aprobación a la versión de firmware de los componentes TCB relevantes para SEV. Sobre la base de la capacidad de extraer las claves de aprobación, mostramos cómo derivar VCEK válidas para versiones de firmware arbitrarias. Con nuestros hallazgos, demostramos que SEV no puede proteger adecuadamente los datos confidenciales en entornos de nube de los atacantes internos, como los administradores de rouge, en las CPU disponibles actualmente.

Escenario 1: Anulación de depuración. La API SEV proporciona funciones de depuración que permiten descifrar y cifrar la memoria de una máquina virtual. Existe una característica similar para SEV-SNP. Las funciones de depuración de SEV y SEV-SNP están sujetas a una verificación de políticas impuesta por el firmware de SEV. Solo si un propietario invitado habilitó explícitamente la depuración durante la implementación inicial, el firmware SEV permitirá los comandos de la API de depuración. Al alterar el firmware de SEV, un atacante podría anular la aplicación de esta política para permitir los comandos de depuración independientemente de la política del propietario invitado. Con ese fin, el atacante debe reemplazar el firmware SEV en la máquina física que aloja la VM de destino.

Alternativamente, el atacante podría primero migrar la máquina virtual objetivo a un sistema previamente preparado. El atacante puede usar las llamadas API de depuración mencionadas anteriormente para descifrar la memoria de una máquina virtual independientemente de la política especificada por el propietario invitado.

Escenario 2: Certificación de falsificación. En este segundo escenario, el atacante tiene acceso a la interfaz de control del hipervisor para iniciar migraciones de VM protegidas por SEV. Sin embargo, a diferencia del primer escenario, el atacante no necesita alterar el firmware del host objetivo. En cambio, el atacante necesita extraer las claves de respaldo específicas de la CPU de la misma microarquitectura de CPU que la CPU del host objetivo. Estas claves de aprobación desempeñan un papel central en la función de atestación remota de la tecnología SEV. Para descifrar la memoria de una máquina virtual, el atacante podría falsificar la certificación.
informe durante la implementación o la migración para engañar a una máquina virtual para que acepte un agente de administración malicioso. El MA es parte de la TCB de una VM y tiene acceso a la Clave de cifrado sin conexión (OEK) de las VM exportadas. Con el OEK, un agente de administración malintencionado puede descifrar la memoria de una máquina virtual. Para los sistemas anteriores a SEV-SNP, se ha propuesto un ataque similar. Ambos escenarios de ejemplo presentados requieren que el atacante obtenga la ejecución de código en el AMD-SP.

Leer más aquí.

0 0 votes
Puntuación de la entrada
Subscribe
Notify of
0 Comentarios
Inline Feedbacks
View all comments
A %d blogueros les gusta esto: