Se han revelado detalles sobre dos vulnerabilidades en el cargador GRUB2, que pueden llevar a la ejecución de código al usar fuentes especialmente diseñadas y al procesar ciertas secuencias Unicode. Las vulnerabilidades pueden ser utilizadas para eludir el mecanismo de verificación de arranque UEFI Secure Boot.
Vulnerabilidades detectadas:
- CVE-2022-2601 — 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 a la asignación de un área de memoria que es deliberadamente menor de lo necesario para acomodar los glifos.
- CVE-2022-3775 — escritura fuera del área de memoria asignada al dibujar algunas secuencias Unicode con una fuente especialmente diseñada. El problema está presente en el código de manejo de fuentes y es causado por la falta de las comprobaciones adecuadas de coincidencia entre el ancho y la altura del glifo y el tamaño del mapa de bits disponible. Un atacante puede manipular la entrada de tal manera que provoque la escritura de datos fuera del búfer asignado. Se observa que a pesar de la complejidad de exploitation, no se puede descartar la posibilidad de llevar el problema a la ejecución de código.
Se ha publicado una corrección en forma de parche. El estado de la mitigación de las vulnerabilidades en las distribuciones se puede evaluar en las siguientes páginas: Ubuntu, SUSE, RHEL, Fedora, Debian. Para resolver los problemas en GRUB2, no es suficiente con simplemente actualizar el paquete, también será necesario generar nuevas firmas digitales internas y actualizar los instaladores, cargadores, paquetes del núcleo, firmware fwupd y la capa shim.
En la mayoría de las distribuciones de Linux, para la carga verificada en modo UEFI Secure Boot se utiliza una pequeña 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ón del núcleo y GRUB en Microsoft. Las vulnerabilidades en GRUB2 permiten la ejecución de código propio en la fase después de la verificación 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ón de componentes del sistema operativo y la elusión de la protección de Lockdown.
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ía de las distribuciones populares de Linux. SBAT ha sido desarrollado en conjunto con Microsoft e implica la adición de metadatos adicionales a los archivos ejecutables de componentes UEFI, que incluyen información sobre el fabricante, el producto, el componente y la versión. Estos metadatos están firmados digitalmente y pueden incluirse por separado en listas de componentes permitidos o prohibidos para UEFI Secure Boot.
SBAT permite bloquear el uso de firmas digitales para versiones específicas de componentes sin necesidad de revocar claves para Secure Boot. El bloqueo de vulnerabilidades a través de SBAT no requiere el uso de la lista de certificados revocados UEFI (dbx), sino que se realiza a nivel de reemplazo de la clave interna para la formación de firmas y la actualización de GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones. Antes de la implementación de SBAT, la actualización de la lista de certificados revocados (dbx, UEFI Revocation List) era un requisito obligatorio para el bloqueo completo de una vulnerabilidad, ya que un atacante, independientemente del sistema operativo utilizado, podía comprometer UEFI Secure Boot utilizando un medio de arranque con una versión antigua y vulnerable de GRUB2, firmada digitalmente.
Fuente: opennet.ru
