Inundación de `CONTINUATION` en HTTP/2: detalles técnicos

Vulnerabilidad de inundación de CONTINUATION en HTTP/2: detalles técnicos

• La inundación de CONTINUATION es una categoría de vulnerabilidades encontrada en varias implementaciones del protocolo HTTP/2, y representa una amenaza más grave que el ataque Rapid Reset.
• Las consecuencias del ataque van desde caídas del servidor hasta degradación del rendimiento, y las solicitudes del ataque no aparecen en los registros de acceso HTTP.

Introducción

• En octubre de 2023 se dio a conocer el ataque HTTP/2 Rapid Reset, y se decidió iniciar una investigación sobre HTTP/2 desde una perspectiva de análisis de seguridad.

Breve introducción a HTTP/2

• La principal diferencia entre HTTP/1.1 y HTTP/2 es que este último es un protocolo binario, y que el cliente y el servidor intercambian frames en lugar de líneas de texto.
• Es necesario explicar los frames HEADERS y CONTINUATION.

Frame HEADERS

• El frame HEADERS se utiliza para transmitir los encabezados HTTP de solicitudes y respuestas, y comprime los datos de encabezado usando el algoritmo de codificación HPACK.
• En el frame se pueden establecer banderas como END_HEADERS y END_STREAM.

Frame CONTINUATION

• El frame CONTINUATION es muy similar al frame HEADERS, pero solo tiene la bandera END_HEADERS; cuando esta bandera está establecida, significa que el flujo de encabezados ha terminado.

Vulnerabilidad de inundación de CONTINUATION

• Si un cliente inicia un nuevo stream HTTP/2 y envía frames HEADERS y CONTINUATION, pero la bandera END_HEADERS nunca se establece, el servidor debe analizar y almacenar en memoria un flujo infinito de encabezados.
• En HTTP/1.1 existe protección contra encabezados infinitos mediante límites de tamaño de encabezados y tiempos de espera para solicitudes/encabezados, pero en muchos servidores HTTP/2 estas medidas de protección faltaban o estaban mal implementadas.

Consumo de CPU: caso de Golang

• Golang es un ejemplo de consumo de CPU causado por una inundación de CONTINUATION; usa una clase abstracta llamada http2MetaHeadersFrame para procesar los frames HEADERS y CONTINUATION.
• El decodificador HPACK está configurado para dejar de emitir encabezados cuando se alcanza el límite de tamaño de encabezados, pero si no existe la bandera END_HEADERS, la función no retorna y continúa decodificando encabezados.

Falta de memoria

• La falta de memoria es uno de los casos más graves; existen implementaciones que no limitan el tamaño de la lista de encabezados construida usando frames CONTINUATION.
• En implementaciones sin timeout de encabezados, una sola conexión HTTP/2 puede hacer colapsar el servidor.

Choque de aserción alcanzable: Node.js (caso especial)

• Node.js maneja correctamente un flujo infinito de frames CONTINUATION, pero aparece un bug de condición de carrera cuando la conexión se interrumpe en medio del flujo de encabezados.
• Node.js rastrea la asignación de memoria dentro del destructor de Http2Session, y cuando la conexión se corta, el valor current_nghttp2_memory_ puede actualizarse simultáneamente, lo que puede provocar una caída.

Comparación con vulnerabilidades anteriores de HTTP/2

• En el pasado se reportaron varias vulnerabilidades de HTTP/2, y la inundación de CONTINUATION funciona de manera distinta a las vulnerabilidades anteriores.
• La inundación de CONTINUATION envía muchos encabezados arbitrarios hasta el límite de tamaño de frame establecido por el servidor, en lugar de enviar encabezados vacíos.

Observaciones finales

• El tráfico HTTP/2 representa aproximadamente el 60% de todo el tráfico HTTP humano, y considerando la importancia de los proyectos afectados, una parte significativa de Internet se vio afectada por una vulnerabilidad fácil de explotar.
• Si esta vulnerabilidad se hubiera explotado en la práctica, habría sido muy difícil de depurar para los administradores de servidores sin conocimientos adecuados de HTTP/2.

Opinión de GN⁺

• Esta vulnerabilidad puede afectar gravemente la disponibilidad de los servidores y, en especial, como no queda registrada en los logs, dificulta su rastreo y respuesta.
• Los administradores de servidores deben aplicar actualizaciones de seguridad de forma regular y usar herramientas de análisis de tráfico para detectar patrones anómalos.
• Este tipo de vulnerabilidades alerta a la comunidad de ciberseguridad y subraya la importancia de diseñar e implementar protocolos más seguros.
• Desde una mirada crítica, esta vulnerabilidad revela fallas fundamentales de diseño en un protocolo ampliamente usado, lo que plantea dudas sobre la confiabilidad de la infraestructura básica de Internet.
• Si no se es un especialista con conocimientos en el área, puede ser difícil entender y responder a vulnerabilidades complejas como esta, por lo que es necesario reforzar la educación y la concientización en seguridad.

[GN⁺]

Comentarios de Hacker News

• Bandit solucionó este problema recientemente

  • Experiencia personal de haber resuelto el mismo problema en Bandit hace un mes.
  • Se proporciona la ubicación específica del código a través del enlace.
  • Desde la perspectiva de quien lo implementó, este problema era muy evidente, y pensó que otras implementaciones ya habrían preparado defensas.
  • Sin embargo, tras revisar decenas de implementaciones, incluso en servidores HTTP/2 importantes faltaban estas protecciones o estaban mal implementadas.

• Crítica a la cultura de desarrollo

  • Señala que el problema es una cultura en la que los desarrolladores están demasiado acostumbrados a que todo escale dinámicamente de forma automática, por lo que no piensan en cuánto puede crecer algo.
  • Este tipo de problema no se limita a HTTP/2, pero la complejidad de HTTP/2 puede empeorarlo aún más.
  • En la época de HTTP/1.x se usaban lenguajes como C y hacía falta atención constante para manejar la longitud de los búferes, y no se expandían indefinidamente las asignaciones de encabezados de solicitud.

• Lista de servidores/proxies inversos no afectados

  • Lista de servidores web y proxies inversos no afectados mencionados en el artículo anterior.
  • Nginx, Jetty, HAProxy, NetScaler y Varnish no se ven afectados.

• Reflexión sobre la seguridad de HTTP/1.1

  • Menciona que su sitio recibió atención durante todo el día.
  • Plantea la duda de si, cuando un sitio tiene poco tráfico, usar HTTP/1.1 sería más seguro.

• Elogios al autor

  • Elogia al autor por abordar el tema con una visión amplia, reportar de manera responsable lo que encontró y compartirlo de una forma fácil de leer.

• Mención de Slowloris v2

  • Bromea con que, si este problema se provoca lentamente, podría llamarse "slowloris v2".

• Mención de un error tipográfico

  • Le parece divertido el error tipográfico "serveral retries".

• Visión crítica sobre HTTP/2

  • Crítica a cómo HTTP/2 pudo ser empujado como una capa de transporte para la "actualización" de un protocolo de capa de aplicación.