Dado que los ataques de ejecución especulativa siguen siendo una vulnerabilidad obstinadamente persistente que afecta a los procesadores modernos, una nueva investigación ha destacado una «falla de la industria» para adoptar las mitigaciones lanzadas por AMD e Intel, lo que representa una amenaza para la cadena de suministro de firmware.
Doblado FirmwareBleed by Binarly, los ataques de filtración de información se derivan de la exposición continua de superficies de ataque de microarquitectura por parte de proveedores empresariales, ya sea como resultado de no incorporar correctamente las correcciones o solo usarlas parcialmente.
“El impacto de este tipo de ataques se centra en revelar el contenido de la memoria privilegiada (incluida la protegida por tecnologías de virtualización) para obtener datos confidenciales de los procesos que se ejecutan en el mismo procesador (CPU)”, dice la firma de protección de firmware. dijo en un informe compartido con The Hacker News.
«Los entornos de nube pueden tener un mayor impacto cuando varios usuarios o entidades legales pueden compartir un servidor físico».
En los últimos años, las implementaciones de ejecución especulativa, un técnica de optimización que predice el resultado y el objetivo de las instrucciones de bifurcación en la tubería de ejecución de un programa, se han considerado susceptibles a ataques similares a los de Spectre en las arquitecturas del procesador, lo que podría permitir que un actor de amenazas filtre claves criptográficas y otros secretos.
Esto funciona engañando a la CPU para que ejecute una instrucción que acceda a datos confidenciales en la memoria que normalmente estarían fuera del alcance de una aplicación sin privilegios y luego extraiga los datos después de que la operación se deshaga después de una predicción errónea.
Una contramedida clave para prevenir los efectos dañinos de la ejecución especulativa es una defensa de software conocida como repollo (también conocido como «Return Trampoline»), que se introdujo en 2018.
Aunque hallazgos recientes como Retbleed han demostrado de manera concluyente que la retpoline por sí sola es insuficiente para detener este tipo de ataques en ciertos escenarios, el último análisis muestra una falta de consistencia incluso en la aplicación de estas mitigaciones en primer lugar.
Específicamente, apunta a una mejor práctica llamada Return Stack Buffer (RSB) relleno introducido por Intel para evitar desbordamientos cuando se utiliza retpoline. Los RSB son predictores de direcciones para instrucciones de retorno (también conocidas como RET).
«Ciertos procesadores pueden usar predictores de bifurcación distintos del búfer de pila de retorno (RSB) cuando el RSB se desborda», Intel notas en su documentación. «Esto podría afectar el software que utiliza la estrategia de mitigación de retpoline en dichos procesadores».
«En procesadores con diferente comportamiento RSB vacío, [System Management Mode] El código debe llenar el RSB con instrucciones CALL antes de regresar de SMM para evitar interferir con el uso de la técnica de repolinización que no sea de SMM».
Intel también es recomendando Relleno de RSB como mecanismo para frustrar ataques de subdesbordamiento de búfer como Retbleed, alternativamente instando proveedores para «establecer [Indirect Branch Restricted Speculation] antes de las instrucciones RET en riesgo de subdesbordamiento debido a las pilas de llamadas profundas».
Sin embargo, la investigación de Binarly ha identificado hasta 32 firmware de HP, 59 de Dell y 248 de Lenovo que no incluyeron los parches de relleno RSB, lo que subraya una «falla en la cadena de suministro de firmware».
Además, el análisis profundo del código ha descubierto instancias en las que la mitigación estaba presente en el firmware, pero contenía errores de implementación que generaron sus propios problemas de seguridad, incluso en actualizaciones lanzadas en 2022 y para dispositivos con la generación reciente de hardware.
«Los ecosistemas de la cadena de suministro de firmware son bastante complejos y, a menudo, contienen fallas repetibles cuando se trata de aplicar nuevas mitigaciones en toda la industria o corregir vulnerabilidades del código de referencia», dijeron los investigadores. «Incluso si hay una mitigación en el firmware, no significa que se aplique correctamente sin crear agujeros de seguridad».