Si estás usando Grub2 como tu gestor de arranque en tu equipo déjame decirte que deberías de actualizarlo ya, pues recientemente se dieron a conocer 8 vulnerabilidades en este gestor de arranque GRUB2 de las cuales una de ellas está marcada como crítica.
La más peligrosa de ellas es la que encuentra catalogado con el nombre en código BootHole (CVE-2020 a 10713). Esta vulnerabilidad detectada hace posible pasar por alto el mecanismo de arranque UEFI Secure e instalar software malicioso sin verificar.
La peculiaridad de esta vulnerabilidad es que, para solucionarlo, no es suficiente actualizar GRUB2, ya que un atacante puede usar medios de arranque con una versión vulnerable anterior certificada por una firma digital. Un atacante puede comprometer el proceso de verificación no solo para Linux, sino también para otros sistemas operativos, incluido Windows.
Y es que el problema radica en que la mayoría de las distribuciones de Linux usan una pequeña capa de shim para el arranque verificado, que está firmado digitalmente por Microsoft.
Esta capa verifica GRUB2 con su propio certificado, lo que permite a los desarrolladores de distribución no certificar cada núcleo y actualización de GRUB a Microsoft.
La vulnerabilidad permite, al cambiar el contenido de grub.cfg, lograr la ejecución de su código en la etapa posterior a la verificación exitosa de shim, pero antes de que se cargue el sistema operativo, encajándose en la cadena de confianza cuando Secure Boot está activo y ganando el control total sobre el proceso de arranque adicional, incluido el arranque de otro sistema operativo, modificando los componentes del sistema operativo y evitando la protección de bloqueo.
La vulnerabilidad es causada por un desbordamiento del búfer que puede ser explotado para ejecutar código arbitrario durante el proceso de descarga. La vulnerabilidad se manifiesta al analizar el contenido del archivo de configuración grub.cfg, que generalmente se encuentra en una partición ESP (EFI System Partition) y puede ser editado por un atacante con derechos de administrador, sin violar la integridad del shim firmado y los ejecutables GRUB2.
Por error en el código del analizador de configuración, el controlador de error de análisis fatal YY_FATAL_ERROR solo mostró una advertencia, pero no finalizó el programa. El peligro de la vulnerabilidad se reduce por la necesidad de un acceso privilegiado al sistema; sin embargo, el problema puede ser necesario para la implementación de rootkits ocultos en presencia de acceso físico al equipo (si es posible arrancar desde sus medios).
De las otras vulnerabilidades que fueron encontradas:
- CVE-2020-14308: desbordamiento del búfer debido a que no se verificó el tamaño del área de memoria asignada en grub_malloc.
- CVE-2020-14309: desbordamiento de enteros en grub_squash_read_symlink, que puede hacer que los datos se escriban fuera del búfer asignado.
- CVE-2020-14310: desbordamiento de enteros en read_section_from_string, lo que puede provocar la escritura de datos fuera del búfer asignado.
- CVE-2020-14311: desbordamiento de enteros en grub_ext2_read_link, lo que puede hacer que los datos se escriban fuera del búfer asignado.
- CVE-2020-15705: permite el arranque directo de núcleos sin firmar en el modo de arranque seguro sin una capa intermedia intercalada.
- CVE-2020-15706: acceso a un área de memoria ya liberada (use-after-free) al anular una función en tiempo de ejecución.
- CVE-2020-15707: desbordamiento de enteros en el controlador de tamaño initrd.
Soluciones
Aunque no todo está perdido, ya que, para solucionar este problema, solo se debe realizar una actualización de la lista de certificados revocados (dbx, UEFI Revocation List) en el sistema, pero en este caso, se perderá la capacidad de usar medios de instalación antiguos con Linux.
Algunos fabricantes de hardware ya han incluido una lista actualizada de certificados revocados en su firmware; en dichos sistemas, en el modo UEFI Secure Boot, solo se pueden cargar compilaciones actualizadas de distribuciones de Linux.
Para corregir la vulnerabilidad en las distribuciones, también se deberá actualizar los instaladores, cargadores de arranque, paquetes de kernel, firmware fwupd y capa de compatibilidad, generando nuevas firmas digitales para ellos.
Los usuarios deberán actualizar las imágenes de instalación y otros medios de arranque, y descargar la Lista de revocación de certificados (dbx) en el firmware UEFI. Hasta la actualización de dbx en UEFI, el sistema sigue siendo vulnerable independientemente de la instalación de actualizaciones en el sistema operativo.
Finalmente se informa que se han lanzado actualizaciones de paquetes de parches para Debian, Ubuntu, RHEL y SUSE, además que por su parte para GRUB2 se han lanzado un conjunto de parches.
Sería bueno que aclaren si estas vulnerabilidades pueden ser explotadas de forma local o remota, eso cambia la dimensión del problema.
Seria de mas utilidad el saber como se solucionan estas cosas. por que en mi caso particular no tengo idea siquiera por donde empezar
Hace un dia o dos note que me llego una actualizacion de GRUB2, no se si era el parcheo era solo un update…en fin…
hablan de actualizar firmware, certificados digitales, descargar la Lista de revocación de certificados (dbx) en el firmware UEFI, de donde o como se hace esto…
Es decir, como informacion esta bueno, pero para un novato es como si hablaran en idioma chino mandarin..
Es un critica constructiva.
Clickbait del bueno:
The vulnerability is a buffer overflow related to how GRUB2 parses its grub.cfg configuration file. An attacker with admin privileges on the targeted system can modify this file so that their malicious code is executed in the UEFI environment before the OS is loaded.
Dejad de asustar a la gente