Los desarrolladores de Linux están en el proceso de parchear 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 shim, que en el contexto de Linux es un pequeño componente que se ejecuta en el firmware en las primeras etapas del proceso de arranque, antes de que se inicie el sistema operativo. Más específicamente, 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 integrada en la mayoría de los dispositivos informáticos modernos para garantizar que cada enlace en el proceso de arranque provenga de un proveedor verificado y confiable. La explotación exitosa de la vulnerabilidad permite a los atacantes neutralizar este mecanismo ejecutando firmware malicioso en las primeras etapas del proceso de arranque antes del inicio. Interfase Extensible de Firmware Unificado
La vulnerabilidad, identificada como CVE-2023-40547, es lo que se conoce como desbordamiento de búfer, un error de codificación que permite a los atacantes ejecutar el 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 Internet. Los atacantes pueden aprovechar la vulnerabilidad de ejecución de código en varios escenarios, prácticamente todos después de alguna forma de compromiso exitoso del dispositivo objetivo o del servidor o la red desde donde arranca el dispositivo.
“Un atacante tendría que ser capaz de obligar a un sistema a arrancar desde HTTP si aún no lo está haciendo, y estar en condiciones de ejecutar el servidor HTTP en cuestión o el tráfico .M hacia él”, dijo Matthew Garrett, desarrollador de seguridad y uno de los autores originales de las cuñas, escribió en una entrevista en línea. “Un atacante (físicamente presente o que ya haya comprometido la raíz del sistema) podría usar esto para subvertir el arranque seguro (agregar una nueva entrada de arranque a un servidor que controla, comprometer el shim, ejecutar código arbitrario)”.
Dicho de otra manera, estos escenarios incluyen:
- Adquirir la capacidad de comprometer un servidor o realizar una suplantación de un adversario en el medio para apuntar a un dispositivo que ya está configurado para arrancar mediante HTTP.
- Ya tener acceso físico a un dispositivo u obtener control administrativo mediante la explotación de una vulnerabilidad separada.
Si bien estos obstáculos son grandes, de ninguna manera son imposibles, particularmente la capacidad de comprometer o hacerse pasar por un servidor que se comunica con dispositivos a través de HTTP, que no está cifrado y no requiere autenticación. Estos escenarios particulares podrían resultar útiles si un atacante ya ha obtenido cierto nivel de acceso dentro de una red y busca tomar el control de los dispositivos conectados de los usuarios finales. Sin embargo, estos escenarios se solucionan en gran medida si los servidores usan HTTPS, la variante de HTTP que requiere que un servidor se autentique. En ese caso, el atacante primero tendría que falsificar el certificado digital que utiliza el servidor 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 el control administrativo mediante la explotación de una vulnerabilidad separada en el sistema operativo es difícil y permite a los atacantes lograr todo tipo de objetivos maliciosos.