Eine neue Angriffstechnik auf Implementierungen des HTTP/2-Protokolls wurde vorgestellt, die die Durchführung von Denial-of-Service-Angriffen durch Ressourcenerschöpfung auf Servern erleichtert. Die Schwachstelle trägt den Code-Namen MadeYouReset und ermöglicht es, Server durch Manipulation der Steuerrahmen von HTTP/2 mit einer großen Anzahl von Anfragen zu überfluten, um die festgelegten Beschränkungen zu umgehen.
Der Kern des Problems besteht darin, dass der Client eine sehr große Anzahl von gleichzeitig verarbeiteten Streams erstellen kann, unabhängig vom LIMIT SETTINGS_MAX_CONCURRENT_STREAMS, indem er jeden Stream zu Beginn zurücksetzt. Ein solcher Reset führt dazu, dass der Client für das Senden einer neuen Anfrage in der etablierten HTTP/2-Verbindung nicht auf die Antwort warten muss von Server und sofort einen großen kontinuierlichen Strom von Anfragen senden kann, soweit es die Bandbreite der Verbindung erlaubt.
Der Client ist nicht mehr von den Verzögerungen zwischen dem Senden der Anfrage und dem Empfang der Antwort (RTT, Round-Trip-Time) abhängig und kann einen Angriff mit minimalen Nebenkosten durchführen, während der Server weiterhin Ressourcen für die Bearbeitung der eingehenden Anfragen verbraucht. Beispielsweise tätigt der Server Zuweisungen für Datenstrukturen für neue Streams, analysiert Anfragen, entpackt Header und verknüpft die URL mit der Ressource. Bei Angriffen auf Rückwärtsproxies kann sich der Angriff auf die Backend-Systeme ausbreiten, an die der Proxy die Anfrage weiterleitet, bevor sie zurückgesetzt wird.
Die Schwachstelle erinnert an das frühere bekannte Problem Rapid Reset (CVE-2023-44487) und wird durch eine Diskrepanz zwischen der logischen Strukturierung von Stream-Resets, wie sie in der Spezifikation des HTTP/2-Protokolls definiert ist, und der in den Endprodukten umgesetzten Logik verursacht. In der Spezifikation wird die Möglichkeit eines Resets von Streams durch den Client und den Server zu jedem Zeitpunkt vorgesehen, jedoch in vielen HTTP/2-ImplementierungenServer wird nach einem solchen Reset die Anfrage weiterhin verarbeitet. Der entscheidende Unterschied zum neuen Angriff besteht darin, dass der Reset der Anfrageverarbeitung auf Initiative des Servers erfolgt und nicht durch das Senden eines Frames mit dem RST_STREAM-Flag durch den Client.
Der Server-Kick erfolgt bei Empfang inkorrekter Anfragen, wobei diese sofort verworfen werden, ohne ihre vollständige Bearbeitung zu beginnen und ohne sie an das Backend weiterzuleiten. Um den vollständigen Verarbeitungszyklus einer Anfrage zu erreichen, kann der Angreifer zunächst eine korrekte HTTP-Anfrage senden, gefolgt von einer inkorrekten Sequenz von Steuerrahmen für HTTP/2. Eine solche Aktivität führt dazu, dass der Server die Anfrage vollständig zu verarbeiten beginnt, aber dann aufgrund eines Fehlers bei der Verarbeitung der folgenden Rahmen den Stream zurücksetzt (den Stream mit der korrekten Anfrage in den Zustand RST_STREAM versetzt).
Das Problem wurde bei HTTP-Servern wie Apache Tomcat, Netty, Eclipse Jetty, Fastly, varnish, lighttpd und Zephyr RTOS bestätigt. Das Problem tritt auch auf Websites und Serverdiensten von Mozilla auf. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed und HAProxy sind nicht betroffen. Der Status der Verwundbarkeit in nginx ist nicht definiert.
Quelle: opennet.ru
