Ubuntu

Omisión de arranque seguro GRUB2 2021

Omisión de arranque seguro GRUB2 2021

En agosto de 2020, se reveló un conjunto de vulnerabilidades de seguridad en GRUB2 (GRand Unified Bootloader versión 2) conocidas colectivamente como BootHole. Hoy, se reveló otro conjunto de vulnerabilidades en GRUB2, con implicaciones similares. Debido a que GRUB2 es un componente clave del proceso de arranque, las vulnerabilidades en él pueden permitir a los atacantes violar las promesas de integridad de UEFI Secure Boot. En esta publicación de blog, discutiremos estas vulnerabilidades, así como los cambios que se han realizado en Ubuntu tanto para mitigarlas como para facilitar el proceso de actualización para futuros escenarios similares.

Como se discutió en agosto de 2020, el proceso de arranque seguro UEFI en Ubuntu es compatible con varios componentes diferentes, todos trabajando juntos para garantizar que solo los cargadores de arranque y los sistemas operativos confiables puedan ejecutarse. Estos consisten en el firmware de la plataforma UEFI (también conocido como UEFI BIOS), shim, el cargador de arranque GRUB2 y el kernel de Linux. Los últimos 3 de estos son componentes de Ubuntu, mientras que el primero lo proporciona el OEM del dispositivo. En este caso, tanto shim como GRUB2 tienen (o pronto recibirán actualizaciones) para mitigar estas vulnerabilidades y para ayudar a garantizar que el proceso de arranque seguro no confíe en las versiones vulnerables anteriores de GRUB2 y no se puedan usar para cargar código malicioso.

A raíz de la divulgación original de BootHole, Chris Coulson del equipo de seguridad de Ubuntu y los investigadores externos descubrieron vulnerabilidades adicionales en GRUB2 que podrían usarse para eludir el arranque seguro. Al revelar esto a los desarrolladores de GRUB2, se estableció un esfuerzo renovado para tratar de identificar cualquier vulnerabilidad adicional que aún estuviera al acecho en GRUB2. A través de una combinación de pruebas de fuzz, análisis estático e inspección manual de código, un equipo de ingenieros de seguridad de varias organizaciones de la industria descubrió en total 8 vulnerabilidades en GRUB2 (6 de las cuales afectan a Ubuntu) para esta actualización, y a cada una se le asignó un CVE como se detalla. debajo:

  • CVE-2020-14372: grub2: el comando acpi permite al usuario privilegiado cargar tablas ACPI diseñadas cuando el arranque seguro está habilitado
  • CVE-2021-20233: grub2: escritura fuera del límite del montón debido a un cálculo incorrecto del espacio requerido para la cotización
  • CVE-2020-25632: grub2: use-after-free en el comando rmmod
  • CVE-2020-27779: grub2: el comando cutmem permite al usuario privilegiado deshabilitar ciertas regiones de memoria, deshabilitando así las protecciones de arranque seguro
  • CVE-2021-20225: grub2: escritura fuera de límites del montón en el analizador de opciones de formato corto
  • CVE-2020-27749: grub2: desbordamiento del búfer de pila en grub_parser_split_cmdline

La séptima vulnerabilidad fue identificada por Dimitri John Ledkov del equipo de Ubuntu Foundations; esto solo afectó a GRUB2 ascendente pero no a Ubuntu (que se había abordado previamente durante la actualización de BootHole):

  • CVE-2021-3418 – grub2: GRUB 2.05 reintrodujo CVE-2020-15705, GRUB2 no valida las firmas del kernel cuando se inicia directamente sin shim, lo que permite omitir el inicio seguro.

La octava vulnerabilidad afectó al módulo USB GRUB2, que no está incluido en los módulos incluidos en la imagen EFI firmada de Ubuntu y, por lo tanto, no afecta a Ubuntu:

  • CVE-2020-25647: grub2: la corrupción de la memoria de los descriptores de dispositivos USB diseñados permite que un usuario local ejecute código arbitrario cuando el arranque seguro está habilitado

Un GRUB2 para gobernarlos a todos

Para garantizar un enfoque unificado, la versión de GRUB2 para sistemas UEFI utilizada en versiones anteriores de Ubuntu se actualiza para que se pueda usar una única versión de GRUB2 para todos; esto asegura que tanto las últimas correcciones de seguridad como las funciones de mitigación se puedan adoptar más fácilmente en estos lanzamientos anteriores. Como esto tiene el potencial de causar problemas en lo que es un componente fundamental del proceso de arranque (debido a la gran cantidad de cambios tanto en GRUB2 como en la forma en que se distribuye en Ubuntu), esta actualización se implementará cuidadosamente a través de el bolsillo de actualizaciones del archivo de paquetes de Ubuntu.

Debido a que el arranque seguro no se aplica a los entornos de arranque basados ​​en BIOS, no publicaremos actualizaciones para GRUB2 en esos sistemas.

¿Qué tiene en sus bolsillos?

El archivo de paquetes de Ubuntu consta de varios compartimentos para cada versión de Ubuntu: versión, seguridad, actualizaciones y propuesta. El bolsillo de lanzamiento contiene esos paquetes y su versión particular que componían el lanzamiento inicial. El bolsillo de seguridad se utiliza para proporcionar actualizaciones de seguridad para paquetes. Los bolsillos propuestos y de actualizaciones se utilizan para proporcionar actualizaciones de corrección de errores a través del proceso de actualizaciones de versión estable de dos pasos: los primeros paquetes se cargan en el bolsillo propuesto y solo después de que se hayan probado y validado lo suficiente, luego migran al bolsillo de actualizaciones. Los bolsillos de lanzamiento, seguridad y actualizaciones están habilitados de forma predeterminada en las nuevas instalaciones de Ubuntu, pero el bolsillo propuesto no lo está; sin embargo, se puede habilitar manualmente con fines de prueba y verificación. Al dividir el archivo de Ubuntu entre las actualizaciones y los bolsillos de seguridad, esto permite a los usuarios más conservadores elegir recibir solo correcciones de seguridad (pero no de errores) al deshabilitar el bolsillo de actualizaciones. Estos bolsillos se diferencian no solo por lo que está permitido en cada bolsillo, sino también por la forma en que se aplican las actualizaciones de paquetes de cada bolsillo. Para garantizar la entrega oportuna de las actualizaciones de seguridad, las nuevas versiones de paquetes lanzadas en este bolsillo están disponibles de inmediato para los usuarios finales, y herramientas como las actualizaciones desatendidas garantizan que se instalen automáticamente en las versiones más recientes de Ubuntu. En comparación, los paquetes en el bolsillo de actualización se lanzan progresivamente para garantizar que cualquier posible regresión solo afecte a un pequeño subconjunto de usuarios al detener las actualizaciones de los paquetes que se consideran problemáticos.

Como esta actualización toca los paquetes que son críticos para que los sistemas Ubuntu se inicien con éxito, se publicarán a través de los bolsillos propuestos y luego los de actualizaciones en este caso, para limitar el impacto de cualquier posible regresión (aunque sea poco probable). Si bien esto retrasa la entrega de la actualización de GRUB2 a los usuarios de Ubuntu, en este caso, el impacto de este retraso es mínimo, ya que la actualización asociada para shim también se retrasa, como se explica a continuación.

Uno no simplemente revoca múltiples binarios GRUB2

En la actualización GRUB2 anterior para BootHole, el UEFI Forum lanzó una actualización asociada para la base de datos UEFI DBX. La base de datos DBX se utiliza para enumerar los componentes que deben no ser de confianza durante el arranque seguro, pero que de otra manera sería: en ese caso, se usó para enumerar las múltiples versiones anteriores de GRUB2 que eran vulnerables a BootHole. Sin embargo, la gran mayoría de las plataformas que admiten UEFI Secure Boot solo tienen un espacio limitado para almacenar esta información, y la actualización anterior de DBX para BootHole consumió una cantidad significativa de este almacenamiento: consumir todo el almacenamiento haría que las máquinas no pudieran arrancar. Como tal, se requería otro mecanismo para permitir la enumeración de GRUB2 inseguros (u otros componentes de arranque) para que no se les permitiera arrancar. Trabajando en conjunto con Microsoft y otros, un Segmentación avanzada de arranque seguro (SBAT) El esquema se diseñó para shim, que proporciona un medio más flexible para proporcionar una lista de GRUB2 (u otros binarios) en los que no se debe confiar como parte del proceso de arranque seguro. Además, la cuña apoya el concepto de un proveedor DBX, que permite a los distribuidores de shim (como Ubuntu) enviar su propia lista de binarios en los que no se debe confiar. Para esta actualización, hemos agregado la lista de todos los binarios GRUB2 más antiguos enviados en Ubuntu que contienen este nuevo conjunto de vulnerabilidades, así como las versiones que eran vulnerables a las vulnerabilidades originales de BootHole para este proveedor DBX dentro de shim como parte del paquete shim actualizado. para Ubuntu ..

Debido al corto período de tiempo entre el desarrollo de las funciones SBAT para shim y el deseo de garantizar que sean estables, así como a la necesidad de que Microsoft las valide para firmar como una nueva pieza confiable para un arranque seguro, una versión retrasada coordinada de shim se ha establecido, por lo que se espera que estas actualizaciones asociadas para shim estén disponibles en unas pocas semanas después de las actualizaciones de GRUB2. También debe tenerse en cuenta que, a diferencia de la actualización anterior relacionada con BootHole para GRUB2 en Ubuntu, para esta actualización, los binarios shim anteriores que fueron firmados por Microsoft para Ubuntu ahora se agregarán a la lista de revocación de DBX del Foro UEFI anterior. Esto no se hizo durante la actualización de BootHole ya que, en cambio, se revocó el certificado que se usó para firmar esos antiguos binarios de GRUB2. Para completar esta transición, este certificado antiguo ahora se agregará al proveedor DBX de shim además de los binarios de GRUB2 mencionados anteriormente.

Finalmente, también esperamos lanzar una actualización para fwupd en Ubuntu. Este paquete se utiliza para instalar actualizaciones de firmware UEFI y también es de confianza como componente de arranque seguro, por lo que también requiere una actualización para admitir SBAT.

Ahí y de vuelta…

Cuando se anunciaron por primera vez las vulnerabilidades de BootHole originales, se destacó el arranque seguro de UEFI y, en particular, GRUB2 como parte de ese ecosistema. Si bien en ese momento se hizo un gran esfuerzo para intentar enumerar y resolver todas las posibles vulnerabilidades similares en GRUB2, esta era una tarea inconclusa. Esta última ronda de actualizaciones busca resolver las vulnerabilidades recién descubiertas, así como hacer que el proceso para futuras actualizaciones de este tipo sea un viaje más fácil tanto para los desarrolladores de Ubuntu como para los usuarios finales. Para obtener más información sobre estas actualizaciones, visite el artículo de la Base de conocimientos de seguridad de Ubuntu.

Leave a Comment

You may also like