Nada extraño, cero dramas… Pero se ha descubierto otra vulnerabilidad, la CVE-2020-10713, que afecta al gestor de arranque GRUB2 y Secure Boot. Una publicación del equipo de investigación de Eclypsium es el que ha estado detrás de este hallazgo y al que han bautizado como BootHole. Incluso Microsoft ha publicado una entrada en su portal de seguridad alertando de ella y alegando que hay complicada solución por el momento.
BootHole es una vulnerabilidad tipo buffer overflow que afecta a miles de millones de dispositivos con GRUB2 e incluso a otros sin GRUB2 que emplean Secure Boot como Windows. En la clasificación del sistema CVSS se ha puntuado como 8.2 sobre 10, lo que significa que es de alto riesgo. Y es que un atacante podría aprovechar esto para poder ejecutar código arbitrario (incluido malware) introducido durante el proceso de arranque, incluso con Secure Boot habilitado.
Tanto dispositivos de red, servidores, estaciones de trabajo, sobremesas y portátiles, así como otros dispositivos como los SBC, ciertos dispositivos móviles, dispositivos IoT, etc., se verían afectados.
Además, según Eclypsium, será complicada de mitigar y tardará en encontrarse una solución. Requerirá una revisión profunda de los gestores de arranque y los proveedores deberían lanzar nuevas versiones de bootloaders firmadas por la UEFI CA. Se requerirán esfuerzos coordinados entre los desarrolladores de la comunidad de código abierto y colaboración de Microsoft y otros propietarios de sistemas afectados para acabar con BootHole.
De hecho, han confeccionado una lista de tareas para poder solucionar BootHole en GRUB2 y se necesita:
- Parche para actualizar GRUB2 y eliminar la vulnerabilidad.
- Que los desarrolladores de las distribuciones Linux y otros proveedores lancen las actualizaciones para sus usuarios. Tanto a nivel de GRUB2, instaladores y shims.
- Las nuevas shims tienen que estar firmadas por la Microsoft UEFI CA para terceros.
- Los administradores de los sistemas operativos tendrán que actualizar evidentemente. Pero se debe incluir tanto el sistema instalado, imágenes de instalador y también medios de recuperación o arranque que tengan creados.
- La lista de revocación UEFI (dbx) también deberá actualizarse en el firmware de cada sistema afectado para evitar la ejecución de código durante el arranque.
Lo peor es que cuando se trata del firmware hay que ir con pies de plomo y ser cauteloso para no terminar con problemas y que los ordenadores se queden en modo «brick».
Por el momento, empresas como Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team y fabricantes de OEMs, así como proveedores de software, ya están trabajando para solucionarlo. No obstante, habrá que esperar para ver los primeros parches.
ACTUALIZACIÓN
Pero menospreciar la eficacia de los desarrolladores y de la comunidad sería estúpido. Ya hay varios candidatos de parches para mitigarlo que están llegando desde empresas como Red Hat, Canonical, etc. Se han marcado este problema como algo de prioridad máxima y está dando sus frutos.
¿El problema? El problema es que estos parches están generando problemas adicionales. Me recuerda a lo que sucedió con los parches para Metldown y Spectre, que a veces es peor el remedio que la enfermedad…