En ny angrebsteknik er blevet præsenteret for implementeringer af HTTP/2-protokollen, der forenkler udførelsen af angreb for at forårsage service-nedbrud ved at udtømme serverressourcer. Sårbarheden har kodenavn MadeYouReset og muliggør gennem manipulation af kontrolrammerne i HTTP/2 at oversvømme serveren med et stort antal anmodninger, der omgår de opstillede grænser.
Kernen i problemet er, at klienten kan oprette et meget stort antal samtidig behandlede streams, uafhængigt af grænsen SETTINGS_MAX_CONCURRENT_STREAMS, ved at nulstille hver stream i starten. En sådan nulstilling betyder, at klienten ikke behøver at vente på svaret fra den etablerede HTTP/2-forbindelse for at sende en ny anmodning, server og kan straks sende et stort kontinuerligt antal anmodninger, alt efter hvad båndbredden tillader.
Klienten bliver uafhængig af forsinkelserne mellem afsendelse af anmodningen og modtagelse af svaret (RTT, round-trip time) og kan udføre angreb med minimale omkostninger, samtidig med at serveren fortsat bruger ressourcer på at behandle de indkommende anmodninger. For eksempel tildeler serveren data-strukturer til nye streams, parser anmodningen, udpakker headeren og matcher URL’en med ressourcen. Ved angreb på reverse proxyer kan angrebet sprede sig til backend-systemerne, som proxyen når at dirigere anmodningen til, inden den bliver nulstillet.
Sårbarheden minder om det tidligere kendte problem Rapid Reset (CVE-2023-44487) og skyldes en diskrepans i logikken for nulstilling af streams, som er defineret i specifikationen for HTTP/2-protokollen og implementeret i de endelige produkter. I specifikationen er der mulighed for at nulstille en stream af både klienten og serveren på ethvert tidspunkt, men i mange implementeringer af HTTP/2,servere fortsætter anmodningen med at blive behandlet efter en sådan nulstilling. Den vigtigste forskel i det nye angreb er, at nulstillingen af behandlingen af anmodningen sker på initiativ af serveren og ikke ved at klienten sender et ramme med RST_STREAM-flaget.
Server-triggered resets occur when invalid requests are received, but such requests are discarded immediately without starting their full processing or passing them to the backend. To achieve a complete processing cycle, the attacker may first send a valid HTTP request, but then follow it up with an invalid sequence of HTTP/2 control frames. Such activity will cause the server to begin processing the request fully, but later, due to an error processing the subsequent frames, it will reset the stream (sending the stream with the valid request into the RST_STREAM state).
The presence of the problem has been confirmed in HTTP servers including Apache Tomcat, Netty, Eclipse Jetty, Fastly, Varnish, Lighttpd, and Zephyr RTOS. The problem also manifests on websites and server services from Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed, and HAProxy are not susceptible to this issue. The status of the vulnerability in nginx is undetermined.
Kilde: opennet.ru
