Los desarrolladores de Linux están parcheando una vulnerabilidad de alta gravedad que, en ciertos casos, permite la instalación de malware que se ejecuta a nivel de firmware, dando a las infecciones acceso a las partes más profundas de un dispositivo, donde son difíciles de detectar o eliminar.
La vulnerabilidad reside en el shim, que en el contexto de Linux es un pequeño componente que se ejecuta en el firmware al principio del proceso de arranque, antes de que se haya iniciado el sistema operativo. Más concretamente, el shim que acompaña a prácticamente todas las distribuciones de Linux desempeña un papel crucial en el arranque seguro, una protección incorporada en la mayoría de los dispositivos informáticos modernos para garantizar que todos los enlaces del proceso de arranque proceden de un proveedor verificado y de confianza. La explotación exitosa de la vulnerabilidad permite a los atacantes neutralizar este mecanismo mediante la ejecución de firmware malicioso en las primeras etapas del proceso de arranque, antes de que el firmware Unified Extensible Firmware Interface se haya cargado y haya cedido el control al sistema operativo.
Vulnerabilidad detectada
La vulnerabilidad, rastreada como CVE-2023-40547, es lo que se conoce como un desbordamiento de búfer, un error de codificación que permite a los atacantes ejecutar código de su elección. Reside en una parte del shim que procesa el arranque desde un servidor central en una red utilizando el mismo HTTP en el que se basa la web. Los atacantes pueden explotar la vulnerabilidad de ejecución de código en varios escenarios, prácticamente todos después de algún tipo de compromiso exitoso de cualquiera de los dispositivos de destino o el servidor o la red del dispositivo de arranque.
"Un atacante tendría que ser capaz de obligar a un sistema a arrancar desde HTTP, si no lo está haciendo ya, y estar en condiciones de ejecutar el servidor HTTP en cuestión o el tráfico MITM a la misma", Matthew Garrett, un desarrollador de seguridad y uno de los autores originales shim, escribió en una entrevista en línea. "Un atacante (físicamente presente o que ya haya comprometido la raíz en el sistema) podría utilizar esto para subvertir el arranque seguro (añadir una nueva entrada de arranque a un servidor que controlan, comprometer shim, ejecutar código arbitrario)."
Dicho de otro modo, estos escenarios incluyen:
- Adquirir la capacidad de comprometer un servidor o realizar una suplantación de identidad de un adversario en el medio para atacar un dispositivo que ya está configurado para arrancar utilizando HTTP.
- Tener ya acceso físico a un dispositivo u obtener control administrativo explotando una vulnerabilidad independiente.
Aunque estos obstáculos son considerables, no son en absoluto imposibles, sobre todo la capacidad de comprometer o suplantar un servidor que se comunica con los dispositivos a través de HTTP, que no está cifrado y no requiere autenticación. Estos escenarios concretos podrían resultar útiles si un atacante ya ha obtenido cierto nivel de acceso dentro de una red y pretende hacerse con el control de los dispositivos de usuario final conectados. Sin embargo, estas situaciones se solucionan en gran medida si los servidores utilizan HTTPS, la variante de HTTP que requiere que un servidor se autentique. En ese caso, el atacante tendría que falsificar primero el certificado digital que el servidor utiliza para demostrar que está autorizado a proporcionar firmware de arranque a los dispositivos.
La capacidad de obtener acceso físico a un dispositivo también es difícil y se considera ampliamente como motivo para considerar que ya está comprometido. Y, por supuesto, obtener ya el control administrativo mediante la explotación de una vulnerabilidad independiente en el sistema operativo es difícil y permite a los atacantes lograr todo tipo de objetivos maliciosos.
Dicho esto, obtener la capacidad de ejecutar código durante el proceso de arranque, antes de que se inicie el sistema operativo principal, constituye una escalada importante de cualquier acceso que un atacante ya tenga. Significa que el atacante puede neutralizar muchas formas de protección de puntos finales diseñadas para detectar situaciones comprometidas. Como tal, el ataque permite la instalación de un bootkit, el término para el malware que se ejecuta antes del sistema operativo. Sin embargo, a diferencia de muchos bootkits, el creado mediante la explotación de CVE-2023-40547 no sobrevivirá al borrado o reformateo de un disco duro.
explicó Garrett:
En teoría, esto no debería dar a un atacante la capacidad de comprometer el firmware en sí, pero en realidad le da la ejecución de código antes de ExitBootServices (el traspaso entre el firmware que todavía ejecuta el hardware y el sistema operativo que toma el control) y eso significa una superficie de ataque mucho mayor contra el firmware - la suposición habitual es que sólo el código de confianza se ejecuta antes de ExitBootServices. Creo que a esto se le seguiría llamando kit de arranque: es capaz de modificar el gestor de arranque y el kernel del sistema operativo antes de su ejecución. Pero no sería totalmente persistente (si borras el disco, desaparece).
Corregir la vulnerabilidad implica algo más que eliminar el desbordamiento del búfer del código shim. También requiere actualizar el mecanismo de arranque seguro para revocar las versiones vulnerables del cargador de arranque. Esto, a su vez, aumenta el nivel de riesgo. Paul Asadoorian, principal evangelista de seguridad de Eclypsium y autor de la que dio a conocer la vulnerabilidad, explicó:
Los usuarios podrían encontrarse con una situación en la que se aplica una actualización DBX (lista de revocación) a su sistema que define el gestor de arranque instalado actualmente como no válido en Secure Boot. En este caso, al reiniciar, Secure Boot detendría el proceso de arranque. Siempre que el usuario pueda acceder a la configuración de su BIOS/UEFI, esto puede remediarse desactivando temporalmente Secure Boot (si el usuario ha establecido una contraseña en la BIOS, esto dificultaría enormemente la recuperación). La utilidad de Linux fwupd tiene facilidades para actualizar el DBX de Secure Boot y proporcionará advertencias al usuario si el gestor de arranque actualmente instalado está en la actualización DBX pendiente.
Otro reto de la actualización, según Asadoorian, tiene que ver con el espacio finito reservado para almacenar revocaciones en una parte de la UEFI conocida como DBX. Algunas listas pueden contener más de 200 entradas que deben añadirse a la DBX. Con muchas calzas que limitan el espacio a 32 kilobits, esta capacidad podría estar a punto de agotarse.
Otro paso en el proceso de parcheado es la firma de las calzas recién parcheadas mediante una autoridad de certificación de terceros de Microsoft.
Los desarrolladores que supervisan los shims de Linux han distribuido el parche a los desarrolladores de shims individuales, que lo han incorporado a cada versión de la que son responsables. Ahora han distribuido esas versiones a los distribuidores de Linux, que las están poniendo a disposición de los usuarios finales.
El riesgo de que la explotación tenga éxito se limita principalmente a escenarios extremos, como se ha señalado anteriormente. El escenario en el que la explotación es más viable -cuando los dispositivos reciben imágenes de arranque a través de un servidor HTTP sin cifrar- es uno que nunca debería ocurrir en 2024 o en la última década, para el caso.
Dicho esto, el daño de una explotación exitosa es grave y es la razón de la calificación de gravedad de 9,8 de 10 posibles. La gente debería instalar los parches rápidamente en cuanto estén disponibles.
