En el cargador GRUB2 8 vulnerabilidades. La más peligrosa (), apodada BootHole, eludir el mecanismo UEFI Secure Boot y permitir la instalación de malware no verificado. Una característica de esta vulnerabilidad es que para corregirla no basta con actualizar GRUB2, ya que un atacante puede utilizar un medio de arranque con una versión vulnerable antigua firmada digitalmente. El atacante puede comprometer el proceso de verificación no solo de Linux, sino también de otros sistemas operativos, incluyendo .
El problema se soluciona solo mediante la actualización del (dbx, UEFI Revocation List), pero en este caso se perderá la posibilidad de utilizar antiguos medios de instalación 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 distribuciones de Linux.
Para corregir 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 las actualizaciones instaladas 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 generalmente se coloca en la partición ESP (EFI System Partition) y puede ser editado por un atacante con derechos de administrador, sin comprometer la integridad de los archivos ejecutables firmados shim y GRUB2. Debido a 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 finalizaba el programa. El peligro de la vulnerabilidad se reduce a la necesidad de tener acceso privilegiado al sistema, sin embargo, el problema puede ser útil para implementar rootkits ocultos cuando se tiene acceso físico al hardware (si se puede 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 tener que firmar cada actualización del núcleo y GRUB en Microsoft. Una vulnerabilidad permite, mediante la modificación del contenido de grub.cfg, ejecutar su propio código en el momento posterior a la verificación exitosa de shim, pero antes de que se inicie el sistema operativo, insertándose en la cadena de confianza durante el modo Secure Boot activo y obteniendo el control total del proceso de arranque posterior, incluida la carga 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 asignada en grub_malloc;
- — desbordamiento de enteros en grub_squash_read_symlink, que puede conducir a la escritura de datos fuera del búfer asignado;
- — desbordamiento de enteros en read_section_from_string, que puede conducir a la escritura de datos fuera del búfer asignado;
- — desbordamiento de enteros en grub_ext2_read_link, que puede conducir a la escritura de datos fuera del búfer asignado;
- — permite cargar núcleos no firmados durante el arranque directo en modo Secure Boot sin la capa shim;
- — acceso a un área de memoria ya liberada (use-after-free) al volver a definir una función en tiempo de ejecución;
- — desbordamiento de enteros 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
