Se ha revelado información sobre dos vulnerabilidades en el gestor de arranque GRUB2, que pueden provocar la ejecución de código al utilizar fuentes especialmente diseñadas y al procesar determinadas secuencias Unicode. Las vulnerabilidades se pueden utilizar para omitir el mecanismo de arranque verificado UEFI Secure Boot.
Vulnerabilidades identificadas:
- CVE-2022-2601: desbordamiento del búfer en la función grub_font_construct_glifo() al procesar fuentes especialmente diseñadas en formato pf2, que ocurre debido a un cálculo incorrecto del parámetro max_glifo_size y la asignación de un área de memoria que obviamente es más pequeña de lo necesario para acomodar los glifos.
- CVE-2022-3775 Se produce una escritura fuera de límites al representar algunas secuencias Unicode en una fuente con un estilo especial. El problema está en el código de procesamiento de fuentes y se debe a la falta de comprobaciones adecuadas para garantizar que el ancho y el alto del glifo coincidan con el tamaño del mapa de bits disponible. Un atacante puede diseñar la entrada de tal manera que haga que el final de los datos se escriba en el exterior del búfer asignado. Cabe señalar que, a pesar de la complejidad de explotar la vulnerabilidad, no se excluye llevar el problema a la ejecución del código.
La solución se publicó como parche. El estado de eliminación de vulnerabilidades en distribuciones se puede valorar en estas páginas: Ubuntu, SUSE, RHEL, Fedora, Debian. Para solucionar problemas en GRUB2, no basta con actualizar el paquete; también necesitará generar nuevas firmas digitales internas y actualizar los instaladores, los cargadores de arranque, los paquetes del kernel, el firmware fwupd y la capa shim.
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 a los desarrolladores de distribuciones no certificar cada kernel y actualización de GRUB con Microsoft. Las vulnerabilidades en GRUB2 le permiten ejecutar su código en la etapa posterior a la verificación exitosa de shim, pero antes de cargar el sistema operativo, ingresando a la cadena de confianza con el modo de arranque seguro activo y obteniendo control total sobre el proceso de arranque posterior, incluido el arranque de otro. OS, modificando el sistema de componentes del sistema operativo y evitando la protección de bloqueo.
Para bloquear la vulnerabilidad sin revocar la firma digital, las distribuciones pueden utilizar 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 fue desarrollado conjuntamente con Microsoft e implica agregar metadatos adicionales a los archivos ejecutables de los componentes UEFI, que incluyen información sobre el fabricante, producto, componente y versión. Los metadatos especificados están certificados con una firma digital y se pueden incluir por separado en las listas de componentes permitidos o prohibidos para UEFI Secure Boot.
SBAT le permite bloquear el uso de firmas digitales para números de versión de componentes individuales sin tener que revocar claves para el arranque seguro. El bloqueo de vulnerabilidades a través de SBAT no requiere el uso de una lista de revocación de certificados UEFI (dbx), sino que se realiza al nivel de reemplazar 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 revocación de certificados (dbx, UEFI Revocation List) era un requisito previo para bloquear completamente la vulnerabilidad, ya que un atacante, independientemente del sistema operativo utilizado, podía utilizar un dispositivo de arranque con una versión antigua y vulnerable de GRUB2. certificado por una firma digital, para comprometer el arranque seguro UEFI.
Fuente: opennet.ru