Fallo de ejecución de código en firmware UEFI amenaza a la mayoría de los servidores del planeta Tierra

Artículo original ↗ Discusión en Hacker News ↗

Una vulnerabilidad recién divulgada en la pila de red EDK2 UEFI, explotable mediante paquetes ICMP manipulados durante el arranque PXE, genera preocupación porque puede eludir Secure Boot, el cifrado de disco basado en TPM y la atestación remota, permitiendo potencialmente una intrusión persistente a nivel de firmware. Quienes comentan sostienen que el impacto real está limitado —requiere sistemas con arranque por red habilitado, acceso de red específico y, a menudo, mala configuración—, pero lo ven como otro ejemplo de cómo las grandes y complejas pilas de firmware crean riesgos sistémicos. El hilo también destaca un impulso creciente hacia firmware de arranque minimalista y especializado, y hacia microkernels, como respuesta estructural al aumento de la facilidad para descubrir vulnerabilidades con herramientas de IA.

Condiciones de explotación y modelo de amenaza

  • La vulnerabilidad está en la pila de arranque en red de UEFI (manejo de PXE / ICMP).
  • La explotación requiere:
    • Que el arranque PXE o por red esté habilitado y realmente se use.
    • Capacidad para enviar un error ICMP unicast manipulado al IP del cliente.
    • Alcance de red durante el arranque temprano, a menudo en una red de gestión o interna.
  • Algunos sostienen que esto, en su mayoría, solo permite a insiders, estados-nación o atacantes que ya tengan una base de apoyo en la red interna.
  • Otros subrayan que sigue siendo grave porque muchos entornos comparten redes de gestión y puede que no filtren ICMP de forma estricta.

Impacto en Secure Boot y el cifrado de disco

  • La ejecución de código en el firmware puede:
    • Eludir el arranque medido y socavar la atestación.
    • Romper flujos de trabajo en los que máquinas arrancadas por PXE atestiguan su estado antes de recibir secretos.
    • Actuar como una omisión del cifrado de disco basado en BitLocker / TPM, especialmente cuando no se usa una contraseña.
  • Incluso con contraseña, una intrusión en el firmware podría permitir fuerza bruta.

¿Qué tan común es PXE / el arranque por red?

  • Las opiniones difieren:
    • Algunos llaman a PXE “de nicho” y frágil; muchos servidores arrancan desde medios locales y rara vez se reinician.
    • Otros dicen que PXE/netboot es “increíblemente común” en servidores, flotas de hosting bare-metal, clientes ligeros y escritorios corporativos reciclados.
  • Preocupa que muchos dispositivos vengan con PXE habilitado por defecto, aunque esté al final del orden de arranque.

Detalles de explotabilidad y mitigaciones

  • Los atacantes podrían inundar las redes con ICMP malicioso y esperar reinicios; no hace falta sincronizar un solo paquete si puedes enviar de forma continua.
  • Los cortafuegos del host no pueden ayudar durante el arranque del firmware; el filtrado debe hacerse en switches/cortafuegos o mediante redes de gestión separadas.
  • Las redes de gestión bien segmentadas y un filtrado estricto de ICMP elevan significativamente la dificultad.
  • Dispositivos personales:
    • Si el arranque por red UEFI está habilitado y es accesible, teóricamente son vulnerables.
    • Varios comentarios afirman que los dispositivos de consumo suelen tener PXE deshabilitado; otros dicen que lo han visto activo habitualmente.

Diseño de UEFI y complejidad del firmware

  • Fuerte crítica a UEFI:
    • Se lo considera “del tamaño de un sistema operativo”, demasiado complejo e inevitablemente propenso a errores.
    • Hay sospecha de que tanta complejidad es innecesaria frente a código pequeño y sencillo al estilo BIOS.
  • Defensas de UEFI:
    • Proporciona interfaces estandarizadas (almacenamiento, red, framebuffer, ACPI/device trees), haciendo viable el arranque genérico de sistemas operativos en hardware diverso.
    • Se lo considera mejor que muchas cadenas de arranque improvisadas de ARM/SBC.
  • Tema más amplio: “menos es más” en código de confianza:
    • Ejemplo de reemplazar firmware genérico de un millón de líneas por ~cientos de líneas de ensamblador especializado.
    • Llamados a minimizar la superficie de ataque, las dependencias y la complejidad en tiempo de ejecución (microkernels, kernels verificados formalmente como seL4, firmware más simple).

Systemd, dependencias y filosofía Unix

  • Un subhilo usa este incidente para criticar bases de código enormes y de rápida evolución (p. ej., systemd) frente a las pequeñas y estables (p. ej., el init clásico).
  • Contraargumento: systemd reemplaza muchos scripts y demonios dispersos, y algunos reportan que es extremadamente fiable.
  • Hay acuerdo general en que la proliferación de dependencias y las grandes superficies de ataque hacen cada vez más insostenible “parchar el planeta”.

Puntuación de severidad y encuadre mediático

  • Algunos ven el titular (“amenaza a la mayoría de los servidores del planeta Tierra”) como alarmismo, especialmente dadas las condiciones previas.
  • Otros argumentan que sigue siendo notable porque permite escalada de privilegios y elusión de atestación en configuraciones realistas.
  • Discusión sobre CVSS:
    • Comparación con vulnerabilidades recientes de PHP; confusión sobre por qué esto recibe 9.5 frente al 9.2 de PHP.
    • Explicación de que CVSS está impulsado por vectores concretos (red vs adyacente, complejidad, etc.) y es imperfecto, con incentivos perversos para obtener puntuaciones altas.
    • Varios comentarios dicen que los números de CVSS a menudo son engañosos y no deben sobreinterpretarse.

IA, puertas traseras y divulgación

  • Varios comentarios señalan que los LLM hacen barato encontrar vulnerabilidades en bases de código grandes, abrumando el modelo de “encontrar y parchear”.
  • Algunos especulan que la IA también expondrá puertas traseras previamente ocultas o intencionales; otros dicen que cada vez es más difícil distinguir errores de puertas traseras.
  • Frustración con los plazos de “divulgación coordinada” en la era de la IA; sensación de que el secreto temprano puede ser irrealista una vez que las herramientas de IA se generalicen.

Preocupaciones para el usuario final y la nube

  • Para los PCs personales típicos:
    • El riesgo depende de si PXE está habilitado y es accesible desde una red hostil.
    • Muchos usuarios pueden verse afectados indirectamente a través de proveedores de nube y empresas de hosting que dependen en gran medida de PXE y UEFI.
  • Preocupación especial para:
    • Proveedores de hosting bare-metal y centros de datos compartidos.
    • Portátiles corporativos y dispositivos “cerrados” si PXE está mal configurado pero habilitado.