CVE-2023-40547 – evitar confiar incorrectamente en los encabezados HTTP

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

Una vulnerabilidad crítica (CVE-2023-40547) en el cargador de arranque shim usado para Secure Boot de Linux permite escrituras fuera de límites cuando confía en los encabezados HTTP `Content-Length`, lo que potencialmente permite a atacantes eludir Secure Boot en escenarios de arranque por red y en ciertos escenarios locales o de MITM. Los comentaristas explican cómo encaja shim en la cadena de Secure Boot, por qué el manejo de HTTP/HTTPS a nivel de firmware es difícil y por qué este fallo es grave pese a aparecer solo en una ruta de arranque HTTP menos común. El hilo también revisita preocupaciones de larga data sobre el control de Microsoft sobre las claves de firma UEFI, los requisitos anti‑tivoización de GPLv3 y si Secure Boot protege realmente a los usuarios o principalmente impone control del proveedor.

Vulnerabilidad y contexto

  • El error está en el código de arranque HTTP de shim: asigna un búfer en función del encabezado Content-Length, pero copia según la longitud real del cuerpo recibido, lo que permite una escritura fuera de límites si el encabezado miente.
  • Esto existe en compilaciones de shim que incluyen soporte de arranque HTTP; shim se usa principalmente como un cargador Secure Boot firmado por Microsoft que luego aplica su propia política mediante Machine Owner Keys (MOK).
  • Los titulares anteriores que insinuaban “cada cargador de arranque de Linux” fueron corregidos: es un error de shim, introducido hace ~8 años.

Superficie de ataque y gravedad

  • No se limita al arranque HTTP explícito:
    • Local: malware con privilegios puede sobrescribir la EFI System Partition o las variables EFI y forzar el arranque HTTP o encadenar shim→GRUB2→shim por HTTP.
    • Red adyacente: PXE boot más MITM se puede encadenar para cargar shim por HTTP.
    • Remoto: MITM sobre arranque HTTP contra una víctima que usa arranque HTTP.
  • Algunos sostienen que, una vez que un atacante puede modificar variables EFI/ESP, ya son posibles otros ataques (por ejemplo, añadir MOKs o usar binarios firmados antiguos); otros replican que el objetivo de Secure Boot es precisamente resistir ese tipo de manipulación.
  • Discrepancia sobre la calificación “Critical”: algunos la ven como una defensa en profundidad esencial, otros creen que es menos significativa si el servidor o el sistema local ya están fuertemente comprometidos.

HTTP frente a HTTPS y detalles de implementación

  • HTTPS no impide servidores maliciosos; principalmente detiene MITM.
  • Varios comentaristas señalan que el código UEFI/de arranque puede omitir la validación adecuada de certificados HTTPS (tamaño del almacén de CA, complejidades de actualización y revocación, desfase horario), lo que hace realista el MITM incluso sobre HTTPS.
  • Debate sobre la semántica de HTTP: en HTTP/1.1, se supone que Content-Length es autoritativo; si una implementación en cambio confía en una medición separada de “bodyLength”, ambas deben reconciliarse cuidadosamente; ese desajuste llevó al error.

Shim, Secure Boot, MOK y revocación

  • El uso típico es shim → GRUB → kernel en disco local; el arranque HTTP es de nicho, pero existe.
  • Shim verifica el binario del siguiente estadio frente a su propia lista MOK; la revocación de Secure Boot mediante UEFI DBX puede invalidar binarios vulnerables de shim, pero muchos sistemas probablemente nunca actualizan DBX.
  • El measured boot y TPM pueden, en principio, vincular las claves de descifrado del disco a componentes de arranque específicos, pero esto se considera complejo y rara vez se usa por usuarios típicos.

GPLv3, anti‑tivoización y la política de firma de Microsoft

  • Gran subhilo sobre por qué Microsoft evita firmar cargadores de arranque GPLv3 como GRUB:
    • Se cita la cláusula de “Installation Information” de GPLv3: los distribuidores de dispositivos con componentes GPLv3 deben proporcionar los métodos o claves de autorización necesarios para que los usuarios instalen y ejecuten versiones modificadas en ese dispositivo.
    • Al principio algunos dudan de que esto se aplique a claves de firma, luego conceden que el lenguaje (“authorization keys”) más el comentario de la FSF sobre anti‑tivoización respaldan esa interpretación.
    • Otros argumentan que permitir a los usuarios registrar sus propias claves (en lugar de proporcionar claves privadas del proveedor) debería satisfacer la licencia, y señalan que las implementaciones deficientes de Secure Boot que bloquean claves de usuario son el problema real.
    • Hay debate sobre si las firmas son relevantes para copyright en absoluto, y sobre si simplemente firmar un binario (sin distribuirlo) puede activar obligaciones de GPL; las posturas entran en conflicto y el estado legal sigue describiéndose como incierto.
  • Shim está licenciado bajo MIT para eludir las restricciones de GPLv3, lo que permite que Microsoft lo firme mientras hace cumplir su propia política de confianza (MOK).

Visiones sobre Secure Boot y el ecosistema

  • Algunos ven Secure Boot como una defensa en profundidad válida, especialmente contra ataques de “evil maid” en ESP no cifradas, y sostienen que los proveedores deberían permitir el control de las claves por parte del usuario.
  • Otros son duramente críticos:
    • Afirman que Secure Boot principalmente consolida el control del proveedor (especialmente la clave predeterminada de Microsoft) y se parece más a DRM que a seguridad para el usuario.
    • Citan dispositivos en los que Secure Boot no puede desactivarse o no se pueden añadir claves de usuario, y donde activar Secure Boot causa problemas de usabilidad (por ejemplo, hibernación, avisos “aterradores”, fricción con Linux).
    • Temen que la plataforma PC se esté moviendo hacia un jardín vallado, comparándolo con problemas antimonopolio anteriores.

Arranque por red y decisiones de diseño

  • Varias personas describen el arranque HTTP/PXE como “pesadillas de seguridad” o, al menos, como algo muy arriesgado, aunque otras señalan que es útil para pruebas de laboratorio y aprovisionamiento.
  • Algunos cuestionan por qué shim implementa directamente el arranque HTTP en lugar de delegarlo a un binario EFI separado firmado con MOK.
  • Hay críticas de que un error tan obvio en la confianza de un encabezado no debería haber pasado la revisión de código, con comentarios que lo comparan con un error de principiante, y comentarios marginales sobre limpiezas menores (por ejemplo, correcciones de erratas) en el parche.