Se ha presentado una nueva técnica de ataque sobre las implementaciones del protocolo HTTP/2, que simplifica la ejecución de ataques de denegación de servicio mediante el agotamiento de los recursos del servidor. La vulnerabilidad ha recibido el nombre en código MadeYouReset y permite, a través de manipulaciones de los frames de control de HTTP/2, inundar al servidor con una gran cantidad de solicitudes eludiendo las restricciones establecidas.
La esencia del problema es que el cliente puede crear un número muy grande de flujos procesados simultáneamente, independientemente del límite SETTINGS_MAX_CONCURRENT_STREAMS, restableciendo cada flujo en la etapa inicial. Este tipo de restablecimiento provoca que, para enviar una nueva solicitud en la conexión HTTP/2 establecida, el cliente no necesite esperar una respuesta de servidores y puede enviar inmediatamente un gran flujo continuo de solicitudes, hasta donde lo permita el ancho de banda de la conexión.
El cliente deja de depender de los retrasos entre el envío de la solicitud y la recepción de la respuesta (RTT, tiempo de ida y vuelta) y puede llevar a cabo un ataque con costos mínimos, mientras que el servidor continúa gastando recursos en el procesamiento de las solicitudes entrantes. Por ejemplo, el servidor realiza la asignación de estructuras de datos para nuevos flujos, el análisis de la solicitud, la descompresión de encabezados y la coincidencia de URL con el recurso. En un ataque a proxies inversos, el ataque puede propagarse a los backends a los que el proxy logre redirigir la solicitud antes de su restablecimiento.
La vulnerabilidad recuerda a un problema previamente conocido como Rapid Reset (CVE-2023-44487) y es causada por una discrepancia en la lógica de restablecimiento de flujos, definida en la especificación del protocolo HTTP/2 y implementada en productos finales. La especificación prevé la posibilidad de que el flujo sea restablecido por el cliente y el servidor en cualquier momento, pero en muchas implementaciones de HTTP/2,servidores después de tal restablecimiento, la solicitud continúa siendo procesada. La principal diferencia del nuevo ataque es que el restablecimiento del procesamiento de la solicitud es llevado a cabo por iniciativa del servidor, y no mediante el envío por parte del cliente de un frame con la bandera RST_STREAM.
El reinicio por iniciativa del servidor ocurre al recibir solicitudes incorrectas, pero tales solicitudes se descartan de inmediato sin iniciar su procesamiento completo y sin ser enviadas al backend. Para lograr un ciclo completo de procesamiento de la solicitud, el atacante puede inicialmente enviar una solicitud HTTP correcta, seguida de una secuencia incorrecta de tramas de control HTTP/2. Esta actividad llevará a que el servidor comience a procesar la solicitud de manera completa, pero luego, debido a un error en el procesamiento de las tramas subsiguientes, reiniciará el flujo (cambiando el flujo con la solicitud correcta al estado RST_STREAM).
Se ha confirmado la existencia del problema en los servidores HTTP Apache Tomcat, Netty, Eclipse Jetty, Fastly, Varnish, Lighttpd y Zephyr RTOS. El problema también se manifiesta en los sitios y servicios de servidor de Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed y HAProxy no son vulnerables al problema. El estado de la vulnerabilidad en nginx no está determinado.
Fuente: opennet.ru
