En el cargador GRUB2 8 vulnerabilidades. La más peligrosa (), conocida como BootHole, eludir el mecanismo UEFI Secure Boot y lograr la instalación de malware no verificado. La particularidad de esta vulnerabilidad es que no basta con actualizar GRUB2 para solucionarla, ya que el atacante puede utilizar un medio de arranque con una versión vulnerable anterior, firmada digitalmente. El atacante puede comprometer el proceso de verificación no solo de Linux, sino también de otros sistemas operativos, incluidos .
El problema se resuelve únicamente actualizando el sistema (dbx, UEFI Revocation List), pero en este caso se perderá la posibilidad de usar medios de instalación antiguos con Linux. Algunos fabricantes de hardware ya han incluido en sus firmware una lista actualizada de certificados revocados; en tales sistemas, en modo UEFI Secure Boot, solo se podrán cargar versiones actualizadas de las distribuciones de Linux.
Para mitigar la vulnerabilidad en las distribuciones también será necesario actualizar los instaladores, cargadores, paquetes del núcleo, firmware 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, así como cargar la lista de certificados revocados (dbx) en el firmware UEFI. Hasta que se actualice el dbx en UEFI, el sistema seguirá siendo vulnerable independientemente de la instalación de actualizaciones en el SO.
Vulnerabilidad desbordamiento de búfer, que puede ser explotado para ejecutar código arbitrario durante el proceso de arranque.
La vulnerabilidad se manifiesta al analizar el contenido del archivo de configuración grub.cfg, que suele ubicarse en la partición ESP (EFI System Partition) y puede ser editado por un atacante con privilegios de administrador sin comprometer la integridad de los archivos ejecutables firmados shim y GRUB2. Debido a un error en el código del analizador de configuración, el manejador de errores fatales de análisis YY_FATAL_ERROR solo emitía una advertencia, pero no terminaba el programa. El riesgo de la vulnerabilidad se reduce ante la necesidad de acceso privilegiado al sistema; sin embargo, el problema puede ser atractivo para la implementación de rootkits ocultos si se tiene acceso físico al hardware (con la posibilidad de arrancar desde su propio medio).
En la mayoría de las distribuciones de Linux, se utiliza una pequeña , 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 de GRUB en Microsoft. La vulnerabilidad permite la ejecución de código propio en la etapa posterior a la verificación exitosa del shim, pero antes de que se inicie el sistema operativo, infiltrándose en la cadena de confianza en modo Secure Boot activo y obteniendo control total sobre el proceso de inicio, incluyendo el arranque de otro sistema operativo, la modificación de componentes del sistema operativo y la elusión de la protección. .
Otras vulnerabilidades en GRUB2:
- — desbordamiento de búfer debido a la falta de verificación del tamaño del área de memoria reservada en grub_malloc;
- — desbordamiento entero en grub_squash_read_symlink, que puede dar lugar a la escritura de datos fuera del búfer reservado;
- — desbordamiento entero en read_section_from_string, que puede dar lugar a la escritura de datos fuera del búfer reservado;
- — desbordamiento entero en grub_ext2_read_link, que puede dar lugar a la escritura de datos fuera del búfer reservado;
- — permite cargar núcleos no firmados al iniciar directamente en modo Secure Boot sin la capa shim;
- — acceso a un área de memoria ya liberada (use-after-free) al sobreescribir una función durante la ejecución;
- — desbordamiento entero en el manejador de tamaño initrd.
Se han lanzado actualizaciones de paquetes con correcciones para , , y . Para GRUB2 un conjunto de parches.
Fuente: opennet.ru
