Una sola variable incorrecta en una sola línea en XQUIC, la biblioteca QUIC y HTTP/3 de Alibaba, permite que un cliente remoto bloquee un servidor con una breve ráfaga de tráfico perfectamente legítimo. No hay parches.
El investigador de FoxIO, Sébastien Féry, reveló la falla el 8 de julio y la apodó XRING. Dice que no se requiere ningún inicio de sesión ni paquetes con formato incorrecto, y que alrededor de 260 bytes de tráfico QPACK normal provocarán la caída del proceso del servidor.
Dado que XQUIC es de código abierto, el riesgo no es sólo para Alibaba. Cualquier servidor que incorpore XQUIC y sirva HTTP/3 con la configuración QPACK predeterminada está en riesgo. Eso incluye Tengine, el servidor web basado en Nginx de Alibaba, que según FoxIO sirve como nube y CDN de la compañía para sitios como Taobao y Alipay.
Todas las versiones hasta la última v1.9.4 se ven afectadas. A partir del 10 de julio, no hay versiones de corrección ni CVE. Hasta que se publique una solución, los operadores pueden desactivar las tablas dinámicas para QPACK configurando SETTINGS_QPACK_MAX_TABLE_CAPACITY en 0, o eliminar completamente la compatibilidad con HTTP/3.
Este error existe en la forma en que HTTP/3 comprime los encabezados. Para evitar enviar los mismos encabezados (como el agente de usuario) una y otra vez, HTTP/3 usa QPACK. Mantiene una tabla compartida que el cliente le dice al servidor que cree y cambie de tamaño a través de un canal de control dedicado, el flujo del codificador.
XQUIC almacena los bytes de su tabla en un búfer de anillo. Un búfer en anillo es un bloque fijo de memoria que se ajusta desde el final hasta el principio cuando los datos están llenos.
Cuando un cliente solicita hacer crecer una tabla, XQUIC asigna un búfer más grande y copia los datos antiguos. Hay cuatro casos para esta copia, dependiendo de si los datos están empaquetados en el búfer antiguo, en el búfer nuevo, en ambos o en ninguno. En uno de ellos, el código determina el tamaño de los datos finales restantes en función de la capacidad de un búfer nuevo y más grande en lugar del búfer antiguo. Está tremendamente sobrevalorado.
Si extiende una tabla en 64 bytes con un cursor de escritura cerca del final y cambia su tamaño a 65, XQUIC piensa que hay 70 bytes finales para mover, cuando en realidad hay 6 bytes.
Ese número incorrecto fluye hacia la copia de memoria. La longitud de la copia es el valor menor menos el recuento excesivo. Dado que esta longitud es un size_t sin firmar, se desborda y se ajusta a un número cercano al máximo, lo que hace que la copia se ejecute hasta el final de la memoria.
En las versiones de FoxIO basadas en Ubuntu 26.04, _FORTIFY_SOURCE=2 de glibc detectó una longitud incorrecta y finalizó el proceso. Sin esta verificación, la copia escribirá fuera del rango del búfer antiguo más allá del final del nuevo búfer. El ferry mostró un accidente, pero no se comprobó si la corrupción podría explotarse aún más.
Ninguno de los valores incluidos en el ataque viola las reglas de QPACK. XQUIC anuncia un límite de tabla dinámica de 16 KiB de forma predeterminada. La carga útil solicita 64 bytes y luego 65 bytes. El cliente solo necesita llevar la tabla al diseño ajustado exacto que llega a la rama defectuosa. FoxIO dice que el error ha estado presente en XQUIC desde su primer lanzamiento público en enero de 2022 y la prueba de concepto está disponible públicamente.
XRING es el último de una serie de fallas remotas en las pilas HTTP/2 y HTTP/3. Hace tres semanas, THN informó un uso después de la liberación (CVE-2026-42530) en el módulo HTTP/3 de NGINX. La idea es que un cliente remoto no autenticado pueda acceder a él a través del mismo flujo del codificador QPACK que XRING está explotando, una clase de error diferente para la misma superficie de ataque.
En junio, la bomba HTTP/2 de Calif provocó una denegación remota de servicio contra Nginx, Apache, IIS y Envoy al explotar HPACK, la compresión de encabezados de HTTP/2, que es el predecesor de QPACK.
En febrero, HAProxy solucionó dos fallos de QUIC. Uno era un desbordamiento de números enteros durante la validación del token, el mismo tipo de error detrás de XRING, pero requería paquetes con formato incorrecto que XRING no necesitaba. Esta diferencia es importante. Entrada válida, un cálculo aritmético, servidor inactivo.
FoxIO demostró fallas en lugar de ejecución de código y no informó ninguna explotación real. La compañía envió un correo electrónico a Alibaba el 7 de abril a través de la política de seguridad del proyecto, prometiendo una respuesta dentro de los tres días hábiles, pero no recibieron respuesta hasta la publicación, y le dieron seguimiento cuatro veces más hasta el 9 de mayo.
Hacker News preguntó a Alibaba si se planean correcciones y CVE, y si los cinco intentos de divulgación de FoxIO han llegado al equipo de seguridad de la empresa. FoxIO preguntó si esta falla se está explotando en la naturaleza y si las escrituras del montón subyacentes pueden sobrevivir al fallo. La historia se actualizará si hay una respuesta.
Source link
