Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Se dieron a conocer los detalles de dos vulnerabilidades en el cargador de arranque GRUB2 que podrían conducir a la ejecución de código al usar fuentes especialmente diseñadas y manejar ciertas secuencias Unicode.

Se menciona que las vulnerabilidades detectadas se pueden utilizar para omitir el mecanismo de arranque verificado UEFI Secure Boot. Las vulnerabilidades en GRUB2 permiten ejecutar código en la etapa posterior a la verificación exitosa de shim, pero antes de cargar el sistema operativo, rompiendo la cadena de confianza con el modo de arranque seguro activo y obteniendo control total sobre el proceso de arranque posterior, por ejemplo, para iniciar otro sistema operativo, modificar los componentes del sistema operativo y omitir la protección de bloqueo.

Sobre las vulnerabilidades identificadas, se menciona lo siguiente:

• CVE-2022-2601: un desbordamiento de búfer en la función grub_font_construct_glyph() al procesar fuentes especialmente diseñadas en formato pf2, que ocurre debido al cálculo incorrecto del parámetro max_glyph_size y la asignación de un área de memoria que es obviamente más pequeña de lo necesario para colocar glifos.
• CVE-2022-3775: escritura fuera de los límites al representar algunas secuencias Unicode en una fuente personalizada. El problema está presente en el código de manejo de fuentes y se debe a la falta de controles adecuados para garantizar que el ancho y el alto del glifo coincidan con el tamaño del mapa de bits disponible. Un atacante puede recoger la entrada de tal manera que haga que se escriba una cola de datos fuera del búfer asignado. Se observa que a pesar de la complejidad de explotar la vulnerabilidad, no se excluye llevar el problema a la ejecución del código.

La mitigación completa contra todos los CVE requerirá correcciones actualizadas con el SBAT más reciente (Secure Boot Advanced Targeting) y datos proporcionados por distribuciones y proveedores.
Esta vez no se utilizará la lista de revocación de UEFI (dbx) y la revocación de los rotos
los artefactos se realizarán solo con SBAT. Para obtener información sobre cómo aplicar el
últimas revocaciones de SBAT, consulte mokutil(1). Las correcciones del proveedor pueden explícitamente permitir el arranque de artefactos de arranque más antiguos conocidos.

Se actualizarán GRUB2, shim y otros artefactos de arranque de todos los proveedores afectados. estará disponible cuando se levante el embargo o algún tiempo después.

Se hace mención de que la mayoría de las distribuciones de Linux utilizan una pequeña capa de corrección, firmada digitalmente por Microsoft, para el arranque verificado en el modo de arranque seguro UEFI. Esta capa verifica GRUB2 con su propio certificado, lo que permite que los desarrolladores de distribución no certifiquen cada actualización de kernel y GRUB con Microsoft.

Para bloquear la vulnerabilidad sin revocar la firma digital, las distribuciones pueden usar el mecanismo SBAT (UEFI Secure Boot Advanced Targeting), que es compatible con GRUB2, shim y fwupd en las distribuciones de Linux más populares.

SBAT se desarrolló en colaboración con Microsoft e implica agregar metadatos adicionales a los archivos ejecutables del componente UEFI, que incluyen información sobre el fabricante, el producto, el componente y la versión. Los metadatos especificados están firmados digitalmente y se pueden incluir por separado en las listas de componentes permitidos o prohibidos para UEFI Secure Boot.

SBAT permite bloquear el uso de una firma digital para números de versión de componentes individuales sin necesidad de revocar claves para el Arranque seguro. El bloqueo de vulnerabilidades a través de SBAT no requiere el uso de una UEFI CRL (dbx), sino que se realiza a nivel de reemplazo de la clave interna para generar firmas y actualizar GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones.

Antes de la introducción de SBAT, la actualización de la lista de certificados revocados (dbx, Lista de revocación de UEFI) era un requisito previo para bloquear completamente la vulnerabilidad, ya que un atacante, independientemente del sistema operativo utilizado, podría usar medios de arranque con una versión antigua vulnerable de GRUB2 certificado por una firma digital para comprometer UEFI Secure Boot.

Finalmente cabe mencionar que la solución se ha publicado como un parche, para solucionar problemas en GRUB2, no basta con actualizar el paquete, también deberá crear nuevas firmas digitales internas y actualizar los instaladores, cargadores de arranque, paquetes del kernel, fwupd-firmware y shim-layer.

El estado de corrección de vulnerabilidades en las distribuciones se puede evaluar en estas páginas: Ubuntu, SUSE, RHEL, Fedora y Debian.

Puedes consultar más al respecto en el siguiente enlace.