{"id":104320,"date":"2022-06-08T15:36:43","date_gmt":"2022-06-08T13:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2022-06-08T15:36:43","modified_gmt":"2022-06-08T13:36:43","slug":"uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vulnerabilidades en GRUB2 que permiten eludir UEFI Secure Boot.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se han corregido 7 vulnerabilidades en el cargador GRUB2 que permiten eludir el mecanismo UEFI Secure Boot y ejecutar c\u00f3digo no verificado, como la inyecci\u00f3n de malware que opera a nivel del cargador o del n\u00facleo. Adem\u00e1s, se ha se\u00f1alado una vulnerabilidad en la capa shim, que tambi\u00e9n permite eludir UEFI Secure Boot. Este grupo de vulnerabilidades ha recibido el nombre en clave Boothole 3, similar a problemas anteriores identificados en el cargador. <\/p>\n

Para corregir los problemas en GRUB2 y shim, las distribuciones podr\u00e1n utilizar el mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cuyo soporte est\u00e1 implementado para GRUB2, shim y fwupd. SBAT ha sido desarrollado conjuntamente con Microsoft e implica a\u00f1adir metadatos adicionales a los archivos ejecutables de los componentes UEFI, que incluyen informaci\u00f3n sobre el fabricante, el producto, el componente y la versi\u00f3n. Los metadatos se firman digitalmente y pueden ser incluidos, por separado, en las listas de componentes permitidos o prohibidos para UEFI Secure Boot. <\/p>\n

En la mayor\u00eda de las distribuciones de Linux, para la carga verificada en modo UEFI Secure Boot se utiliza una peque\u00f1a capa shim, firmada digitalmente por Microsoft. Esta capa verifica GRUB2 con su propio certificado, lo que permite a los desarrolladores de distribuciones no firmar cada actualizaci\u00f3n del n\u00facleo y GRUB en Microsoft. Las vulnerabilidades en GRUB2 permiten la ejecuci\u00f3n de c\u00f3digo propio en la fase despu\u00e9s de la verificaci\u00f3n exitosa de shim, pero antes de cargar el sistema operativo, interrumpiendo la cadena de confianza en modo Secure Boot activo y obteniendo el control total del proceso de carga posterior, incluyendo la carga de otro sistema operativo, la modificaci\u00f3n de componentes del sistema operativo y la elusi\u00f3n de la protecci\u00f3n de Lockdown. <\/p>\n

Para corregir los problemas en el cargador, las distribuciones tendr\u00e1n que generar nuevas firmas digitales internas y actualizar instaladores, cargadores, paquetes del n\u00facleo, firmware fwupd y la capa shim. Antes de la implementaci\u00f3n de SBAT, la actualizaci\u00f3n de la lista de certificados revocados (dbx, UEFI Revocation List) era un requisito obligatorio para el bloqueo completo de la vulnerabilidad, ya que un atacante, sin importar el sistema operativo utilizado, pod\u00eda comprometer UEFI Secure Boot utilizando un medio de arranque con una versi\u00f3n antigua y vulnerable de GRUB2, firmada digitalmente. <\/p>\n

En lugar de revocar, las firmas SBAT permiten bloquear su uso para versiones espec\u00edficas de componentes sin necesidad de revocar las claves para Secure Boot. El bloqueo de vulnerabilidades a trav\u00e9s de SBAT no requiere el uso de la lista de certificados revocados de UEFI (dbx), y se realiza a nivel de reemplazo de la clave interna para la formaci\u00f3n de firmas y actualizaci\u00f3n de GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones. Actualmente, el soporte para SBAT ya se ha a\u00f1adido a la mayor\u00eda de las distribuciones populares de Linux. <\/p>\n

Vulnerabilidades detectadas: <\/p>\n