Hoy os traemos CVE-2025-3052, un bug UEFI tan elegante que consigue desactivar Secure Boot desde dentro, sin romper nada, sin errores, y con firma digital validada por Redmond. Pura artesanía.
Todo empieza con un módulo firmado: Dtbios-efi64.efi. Lo firma Microsoft, lo carga el firmware en arranque, y tú te quedas tranquilo pensando que el sistema está protegido. El problema es que ese binario accede directamente a una variable de NVRAM llamada IhisiParamBuffer y la trata como un puntero sin comprobar nada. Literalmente, coge lo que haya y empieza a trabajar con ello. ¿Qué puede salir mal?
Porque si tú puedes escribir en esa variable NVRAM desde un sistema comprometido (y créeme, puedes), puedes decirle al binario que ejecute código arbitrario durante el arranque. Y aquí viene lo bueno: puedes sobrescribir el protocolo EFI_SECURITY2_PROTOCOL, que es el que implementa la verificación de firmas en Secure Boot. En otras palabras, puedes decirle que todas las imágenes están firmadas y validadas, aunque sean una ISO del infierno.
Lo mejor es que el sistema operativo no se entera. Para Windows, para Linux, todo sigue bien. Secure Boot aparece como habilitado en el firmware, y todas las herramientas que lo consultan te dirán que está activado y funcionando. Pero en realidad estás arrancando lo que te dé la gana, sin restricciones.
Este ataque, descubierto por los cracks de Binarly, afecta a cualquier sistema que confíe en la CA de Microsoft UEFI de 2011. O sea: casi todo. Desde laptops modernos hasta servidores y sistemas embebidos que usen shim para arrancar Linux.
Los investigadores identificaron al menos 14 binarios vulnerables, todos con firmas válidas. Para protegernos, Microsoft publicó una actualización del dbx (la lista de revocaciones de Secure Boot) durante el Patch Tuesday del 10 de junio de 2025. Esa actualización revoca los hashes de los binarios afectados, evitando su ejecución.
| Name | Authenticode SHA256 hash |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
Pero claro, eso solo sirve si tu firmware aplica correctamente la nueva dbx. Y si no lo hace —o si tú mismo estás jugando con binarios UEFI personalizados, como en muchos entornos Linux— estás tan expuesto como antes.
Técnicamente, esto es un bug de acceso arbitrario a punteros en un entorno donde no debería haber ninguno. El IhisiParamBuffer está en NVRAM, se puede escribir desde el SO, y el binario lo usa como estructura interna sin sanear. El vector de ataque es brutal porque se ejecuta en la fase pre-OS, lo que permite plantar bootkits, loaders maliciosos, rootkits que persisten reinstalaciones… Todo el catálogo de firmware "chungo".
Por supuesto, esto no es una RCE: necesitas acceso privilegiado para explotar esta vulnerabilidad. Pero una vez lo tienes (y muchas amenazas persistentes lo logran), puedes hacer cosas muy feas. Como que tu sistema nunca vuelva a arrancar de forma segura, aunque reinstales el SO cien veces.
¿Quieres saber si tu sistema está en riesgo? En Linux, mira tu /boot/efi y usa fwupdmgr o efibootmgr para inspeccionar los binarios cargados. También puedes buscar IhisiParamBuffer en tus variables de firmware:
En Windows, la forma más sencilla es usar PowerShell y comprobar si tu dbx está actualizado. Pero, de nuevo, no te fíes solo del GUI: que el icono diga "Secure Boot activo" no significa que esté realmente verificando nada.
Esto no es solo un bug, es una lección. Firmar algo no lo hace seguro. Ni siquiera si lo firma Microsoft. Y si encima estás en un entorno donde el firmware no se actualiza o el fabricante ni sabe lo que es dbx, pues buena suerte.
Así que: parchea, actualiza el firmware si puedes, y si tienes acceso a máquinas en producción, asegúrate de que no estén ejecutando binarios sospechosos desde la EFI. Porque este tipo de ataques ya no son teóricos: son reales, son efectivos, y son extremadamente difíciles de detectar una vez implantados.
Comentarios
Publicar un comentario