Se ha encontrado una vulnerabilidad (CVE-2023-40547) en la capa Shim, utilizada en la mayor\u00eda de las distribuciones de Linux para la carga verificada en modo UEFI Secure Boot, que puede llevar a la ejecuci\u00f3n remota de c\u00f3digo y a eludir el mecanismo de carga verificada UEFI Secure Boot. Un atacante que controle el servidor HTTP al que accede Shim puede devolver una respuesta especialmente dise\u00f1ada, lo que podr\u00eda resultar en una escritura controlada fuera del l\u00edmite del b\u00fafer para ejecutar c\u00f3digo en una etapa temprana de la carga. <\/p>\n
La vulnerabilidad es causada por un error en el c\u00f3digo de carga de archivos a trav\u00e9s de HTTP, que se manifiesta al procesar respuestas incorrectas devueltas por el servidor HTTP al que se dirige el shim. El modo HTTPBoot en Shim ha sido compatible desde 2016 y permite organizar la carga a trav\u00e9s de la red, utilizando el protocolo HTTP para extraer el archivo con el cargador que se invoca en la siguiente etapa. Al cargar archivos a trav\u00e9s de HTTP, Shim asigna un b\u00fafer para los datos recibidos, considerando no el tama\u00f1o real de los datos, sino el tama\u00f1o indicado en el encabezado HTTP 'Content-Length'. Por lo tanto, al devolver un valor menor en el encabezado Content-Length, se puede lograr que la cola de la solicitud se escriba en la memoria fuera del b\u00fafer. <\/p>\n
Shim est\u00e1 firmado digitalmente por Microsoft y verifica GRUB2 con su propio certificado, lo que permite a los desarrolladores de distribuciones no tener que firmar cada actualizaci\u00f3n del n\u00facleo y de GRUB en Microsoft. La vulnerabilidad en Shim permite interferir en la cadena de confianza durante el modo Secure Boot activo y obtener un control total sobre el proceso de carga posterior, por ejemplo, para cargar otro sistema operativo, modificar componentes del sistema operativo y eludir la protecci\u00f3n Lockdown. <\/p>\n
La vulnerabilidad se ha corregido en la versi\u00f3n de Shim 15.8, pero para bloquear completamente el ataque a trav\u00e9s de Shim es necesario certificar la nueva versi\u00f3n en Microsoft e implementar esta en las distribuciones. El estado de la correcci\u00f3n de la vulnerabilidad en las distribuciones se puede evaluar en las siguientes p\u00e1ginas: Debian, Ubuntu, SUSE, RHEL, Fedora. El problema es que sin la revocaci\u00f3n de la firma de la versi\u00f3n antigua, la correcci\u00f3n es in\u00fatil, ya que un atacante podr\u00eda utilizar un medio de arranque con la versi\u00f3n vulnerable de Shim para comprometer UEFI Secure Boot. Pero la revocaci\u00f3n de la firma provocar\u00e1 la imposibilidad de cargar las distribuciones de manera verificada que sigan utilizando la versi\u00f3n antigua de Shim. <\/p>\n
Para bloquear la vulnerabilidad sin revocar la firma digital, las distribuciones pueden utilizar el mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cuyo soporte se ha implementado para GRUB2, shim y fwupd en la mayor\u00eda de las distribuciones populares de Linux. SBAT ha sido desarrollado en conjunto con Microsoft e implica la adici\u00f3n de metadatos adicionales a los archivos ejecutables de componentes UEFI, que incluyen informaci\u00f3n sobre el fabricante, el producto, el componente y la versi\u00f3n. Estos metadatos est\u00e1n firmados digitalmente y pueden incluirse por separado en listas de componentes permitidos o prohibidos para UEFI Secure Boot. <\/p>\n
SBAT permite bloquear el uso de firmas digitales para n\u00fameros de versi\u00f3n individuales de componentes sin necesidad de revocar claves para Secure Boot. El bloqueo de vulnerabilidades a trav\u00e9s de SBAT no requiere utilizar la lista de certificados revocados de UEFI (dbx), y se lleva a cabo a nivel de reemplazo de la clave interna para la generaci\u00f3n de firmas y la actualizaci\u00f3n de GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones. <\/p>\n
Adem\u00e1s de la vulnerabilidad discutida, en Shim 15.8 se han corregido varios problemas menos graves explotados localmente: <\/p>\n