Los Googlers no solo han descubierto cómo romper la seguridad de AMD, permitiéndoles cargar un microcódigo no oficial en sus procesadores para modificar el comportamiento del silicio como desean, sino que también demostró esto produciendo un parche de microcódigo que hace que las chips siempre salgan 4 cuando se les pidió un número aleatorio.
Y esta capacidad de cambiar el microcódigo no solo permite a Google y a otros personalizar el funcionamiento de sus chips AMD, por razones buenas y no buenas, sino que también aplasta las características seguras de virtualización cifrada del fabricante de EPYC y las características de seguridad de la raíz de la red.
Fondo
Microcode es un bloque especial de programas típicamente cargados en un procesador durante el inicio del sistema que define la forma en que funciona el chip. Al proporcionar microcódigo a los usuarios, AMD puede agregar algunas características, solucionar ciertos problemas y extender alguna funcionalidad sin tener que rediseñar y volver a emitir el silicio físico. Es un parche que actualiza su chip, Intel tiene similar, y se supone que solo AMD es capaz de producir actualizaciones de microcódigos de trabajo para sus productos.
AMD hornea un mecanismo de seguridad criptográfico en sus procesadores que verifica una actualización de microcódigo realmente proviene de AMD antes de aceptarlo. El formato del microcódigo tampoco está documentado públicamente y es altamente patentado y protegido. Todo esto es para evitar que alguien se le ocurra su propio microcódigo viable y haga que un procesador AMD haga las cosas que no debería o de una manera no estándar.
Bueno, los Boffins de Google han descubierto una forma de elaborar su propio microcódigo que aceptan los procesadores AMD y cambia con éxito la operación de Silicon. Dicen que su técnica funciona en todos los chips AMD a base de zen, todas las partes Ryzen y Epyc, básicamente.
Cómo (no muy) aleatorio
Para hacer una copia de seguridad de estas afirmaciones, los Googlers se publicaron esta semana detalles iniciales de sus hallazgos, y una actualización de microcódigos de prueba de concepto para chips de servidor EPYC de Milan-Family y procesadores de escritorio Ryzen 9 Phoenix-Family Ryzen 9. Este microcódigo de demostración Fuerza a la lectura de un chip al azar (Rdrand) instrucción para generar siempre el valor 4 en lugar de un número aleatorio real, probablemente una referencia a Xkcd.
Los Googlers castraron cuidadosamente su prueba de concepto, observamos. La instrucción RDRAND alterada siempre borra el indicador de transporte del núcleo de la CPU a cero, lo que indica a las aplicaciones el valor no es válido. Por lo tanto, si alguien comenzara a distribuir el parche, las aplicaciones y las bibliotecas bien escritas deberían negarse a usar el número estático en procesadores cojeados. Esto es importante porque el software utiliza RDRAND para generar valores aleatorios para un cifrado seguro y otras criptografía; Un valor de siempre 4 destruirá en silencio esa protección de datos.
Las implicaciones de esto son bastante grandes. Demuestra cómo las instrucciones de software pueden ser alteradas o extendidas por parches de microcódigos no oficiales, que Google puede crear tales parches, y que estos parches podrían usarse para bien, mejorar las operaciones de la CPU, y malos, como debilitar o romper la seguridad. Ha habido investigaciones previas sobre el formato de microcódigo de AMD (por ejemplo, aquí y aquí) Aunque el trabajo de Google cubre las últimas piezas de AMD hasta aquellos envíos en 2017.
Esta vulnerabilidad podría ser utilizada por un adversario para comprometer las cargas de trabajo informáticas confidenciales
De manera crucial, necesita acceso a nivel de núcleo, Ring-0 en un sistema para cargar el microcódigo, por lo que esto solo puede usarse una vez que tenga suficientes privilegios. Esto hace que esta técnica sea más útil para aquellos que personalizan sus propios sistemas, o para malware privilegiado que realmente quiere comprometer profundamente una computadora infectada.
Pero considere un escenario en el que está ejecutando una máquina virtual en un host remoto en el que no puede confiar plenamente, por lo que confía en la virtualización cifrada segura de AMD para protege tu VM del anfitrión; Ahora el host puede usar el enfoque de Google para cargar microcódigo que socava o quita esa seguridad.
El problema
Por lo que podemos decir, el equipo de Google pudo producir actualizaciones de microcódigos que parecen ser firmadas digitalmente por AMD, o firmado de una manera que el procesador espere, al tiempo que contiene un código que no es de AMD. Se nos logra explotando un algoritmo de hash débil en el chip.
«Hemos demostrado la capacidad de elaborar parches de microcódigos maliciosos arbitrarios en Zen 1 a Zen 4 CPU», explicó el equipo de seguridad de Google en su aviso el lunes.
«La vulnerabilidad es que la CPU utiliza una función hash insegura en la validación de firma para actualizaciones de microcódigos.
«Esta vulnerabilidad podría ser utilizada por un adversario para comprometer las cargas de trabajo informáticas confidenciales protegidas por la versión más reciente de la virtualización cifrada segura AMD, SEV-SNP o para comprometer la raíz dinámica de la medición de la confianza».
Arreglándolo
AMD y Google consideran esta carga de parches de CPU no oficiales como una vulnerabilidad de seguridad, que obtuvimos un vistazo En enero, cuando Asus saltó el arma revelando accidentalmente una solución de seguridad relacionada con el microcódigo.
El defecto, listado como CVE-2024-56161 con un puntaje CVSS de 7.2 de 10, fue descubierto e informado en AMD en septiembre, y se ideó una solución en diciembre. Esa remediación se está implementando en forma de, irónicamente, una actualización oficial de microcódigos a través de fabricantes de sistemas de AMD. Hasta ahora parece AMD ha emitido parches para procesadores de clase Datacenter e integrado, y nada oficialmente para sus chips informáticos personales.
Dicho esto, la fuga de ASUS de anteriormente fue una actualización beta de BIOS para las placas base para juegos con EMD que solucionó este problema de seguridad del microcódigo, por lo que las actualizaciones para los componentes Ryzen y ThreadRipper pueden estar en camino. Estamos buscando aclaraciones.
AMD subrayó CVE-2024-56161 es explotable solo por alguien con acceso de administrador del host. «Una vez que se alcanza ese nivel de acceso, casi cualquier cosa es posible», dijo un portavoz a El registro.
También observamos que el agujero no puede ser explotado por un administrador en un invitado virtualizado; Necesita acceso a Ring-0 a nivel de kernel en el host, fuera de cualquier máquina virtual en ejecución.
«AMD ha puesto a disposición una mitigación para este problema que requiere actualizar el microcódigo en todas las plataformas impactadas para ayudar a evitar que un atacante cargue microcódigo malicioso», explicó el diseñador de chips.
«Además, se requiere una actualización de firmware de SEV para que algunas plataformas admitan el certificado SEV-SNP. La actualización de la imagen del BIOS del sistema y el reiniciado de la plataforma permitirá la certificación de la mitigación. Un invitado confidencial puede verificar la mitigación en la plataforma de destino a través de la plataforma de destino El informe de certificación SEV-SNP «.
Los procesadores EPYC que se remontan a 2017 se ven afectados, al menos. Google lanzará más detalles el próximo mes.
«Debido a la cadena de suministro profunda, la secuencia y la coordinación necesarias para solucionar este problema, no compartiremos los detalles completos en este momento para darle a los usuarios tiempo para restablecer la confianza en sus cargas de trabajo confidenciales de la competencia», la g- El equipo escribió. «Compartiremos detalles y herramientas adicionales el 5 de marzo de 2025».
AMD agradeció a los Googlers Josh Eads, Kristoffer Janke, Eduardo ‘Vela’ Nava, Tavis Ormandy y Matteo Rizzo por su ayuda para identificar y solucionar el problema. ®