Se ha revelado información sobre 8 vulnerabilidades en el cargador GRUB2 que permiten eludir el mecanismo UEFI Secure Boot y lograr la ejecución de código no verificado, como la implementación de malware que opera a nivel de cargador o núcleo.
Recordemos que en la mayoría de las distribuciones de Linux, se utiliza una pequeña capa shim, firmada digitalmente por Microsoft, para la carga verificada en modo UEFI Secure Boot. 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 de GRUB en Microsoft. Las vulnerabilidades en GRUB2 permiten la ejecución de código propio en la etapa posterior a la verificación exitosa de shim, pero antes de cargar el sistema operativo, infiltrándose en la cadena de confianza mientras el modo Secure Boot está activo y obteniendo control total sobre el proceso de arranque, incluida la carga de otro SO, la modificación de componentes del sistema operativo y la elusión de la protección Lockdown.
Al igual que en el caso de la vulnerabilidad BootHole del año pasado, no es suficiente con actualizar el cargador para bloquear el problema, ya que el atacante, independientemente del sistema operativo utilizado, puede comprometer UEFI Secure Boot utilizando un medio de arranque con una versión antigua y vulnerable de GRUB2 firmada digitalmente. El problema se resuelve solo actualizando la lista de certificados revocados (dbx, UEFI Revocation List), pero en este caso se perderá la posibilidad de usar antiguos medios de instalación de Linux.
En sistemas con firmware en los que se ha actualizado la lista de certificados revocados, en modo UEFI Secure Boot solo se podrán cargar las versiones actualizadas de las distribuciones de Linux. Las distribuciones deberán actualizar los instaladores, cargadores, paquetes del núcleo, firmwares fwupd y la capa shim, generando nuevas firmas digitales para ellos. Los usuarios deberán actualizar las imágenes de instalación y otros medios de arranque, y además cargar la lista de certificados revocados (dbx) en el firmware UEFI. Hasta que se actualice dbx en UEFI, el sistema seguirá siendo vulnerable independientemente de las actualizaciones instaladas en el SO. El estado de la remediación de vulnerabilidades se puede evaluar en estas páginas: Ubuntu, SUSE, RHEL, Debian.
Para abordar los problemas que surgen con la distribución de certificados revocados, se planea implementar en el futuro un mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cuyo soporte ha sido integrado en GRUB2, shim y fwupd. A partir de las siguientes actualizaciones, se utilizará en lugar de la funcionalidad proporcionada por el paquete dbxtool. SBAT se ha desarrollado en colaboración con Microsoft e implica la adición de metadatos a los archivos ejecutables de los componentes UEFI, que incluyen información sobre el fabricante, el producto, el componente y la versión. Estos metadatos se firman digitalmente y pueden ser incluidos adicionalmente en listas de componentes permitidos o prohibidos para UEFI Secure Boot. Así, SBAT permitirá manipular los números de versión de los componentes al revocar, sin necesidad de regenerar las claves para Secure Boot o crear nuevas firmas para el núcleo, shim, grub2 y fwupd.
Vulnerabilidades detectadas:
- CVE-2020-14372 — mediante el comando acpi en GRUB2, un usuario privilegiado del sistema local puede cargar tablas ACPI modificadas, colocando un SSDT (Secondary System Description Table) en el directorio /boot/efi y modificando las configuraciones en grub.cfg. A pesar de que el modo Secure Boot esté activo, el SSDT propuesto será ejecutado por el núcleo y puede ser utilizado para desactivar la protección LockDown, que bloquea las rutas de elusión de UEFI Secure Boot. Como resultado, el atacante puede lograr cargar su módulo del núcleo o ejecutar código a través del mecanismo kexec, sin verificación de la firma digital.
- CVE-2020-25632 — el acceso a un área de memoria ya liberada (use-after-free) en la implementación del comando rmmod se manifiesta al intentar descargar cualquier módulo sin tomar en cuenta sus dependencias relacionadas. La vulnerabilidad no excluye la posibilidad de crear un exploit que podría conducir a la ejecución de código eludiendo la verificación de Secure Boot.
- CVE-2020-25647 — escritura fuera de los límites del búfer en la función grub_usb_device_initialize(), llamada durante la inicialización de dispositivos USB. El problema puede ser explotado a través de la conexión de un dispositivo USB especialmente preparado, que proporciona parámetros de tamaño que no coinciden con el tamaño del búfer asignado para las estructuras USB. El atacante puede lograr la ejecución de código no verificado en Secure Boot, mediante manipulaciones con dispositivos USB.
- CVE-2020-27749 — desbordamiento de búfer en la función grub_parser_split_cmdline(), que puede ser provocado al especificar en la línea de comandos de GRUB2 variables de más de 1 KB. Esta vulnerabilidad permite ejecutar código eludiendo el Secure Boot.
- CVE-2020-27779 — el comando cutmem permite a un atacante eliminar un rango de direcciones de la memoria para eludir el Secure Boot.
- CVE-2021-3418 — los cambios en shim_lock crearon un vector adicional para explotar la vulnerabilidad del año pasado CVE-2020-15705. Al instalar en dbx un certificado utilizado para firmar GRUB2, GRUB2 permitía cargar cualquier núcleo directamente sin verificar la firma.
- CVE-2021-20225 — posibilidad de escribir datos fuera del búfer al ejecutar comandos con un número muy grande de opciones.
- CVE-2021-20233 — posibilidad de escribir datos más allá del búfer debido a un cálculo incorrecto del tamaño del búfer al usar comillas. En el cálculo del tamaño se asumió que se necesitaban tres caracteres para escapar una comilla simple, cuando en realidad se requieren cuatro.
Fuente: opennet.ru
