Új HTTP/2 Bomb DoS támadás sújtja az Nginx, Apache, IIS, Envoy és Pingora rendszereket

enlightened Ez az oldal a közösségért készül. heart Kövess minket máshol is:  Linux Mint Magyar Közösség a Mastodon-on  Telegram csatorna – csak hírek  Beszélgessünk a Telegram – Linux csevegő csoport  Hírek olvasása RSS segítségével  Linux Mint Hivatalos Magyar Közösség a Facebook-on      Linux Mint Baráti Kör a Facebook-on
wink Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát Ko-fi vagy Paypal segítségével. laugh

kami911 képe

Az újonnan felfedezett HTTP/2 Bomb néven ismert szolgáltatásmegtagadási támadás több jelentős webszervert és HTTP/2 implementációt érint, beleértve az Nginx, Apache HTTP Server, Microsoft IIS, Envoy és Cloudflare Pingora rendszereket.

A kaliforniai kutatók közzétették ezt a problémát, amelyet a default HTTP/2 konfigurációkat célzó távoli támadásként írnak le. A hagyományos szolgáltatásmegtagadási támadásokkal ellentétben a HTTP/2 Bomb a protokoll standard viselkedését használja arra, hogy a szerverek nagy mennyiségű memóriát allokáljanak és megtartsanak.

A támadás két technikát alkalmaz. Először is, kihasználja az HPACK-ot, a HTTP/2 fejléc tömörítést, azzal, hogy kis indexelt fejlécreferenciákat küld, amelyek sokkal nagyobb szerveroldali allokációkká bővülnek. Másodszor, a HTTP/2 áramlásvezérlést használja a válaszok leállítására, megakadályozva ezzel a szervert abban, hogy felszabadítsa az allokált memóriát.

Ez lehetővé teszi, hogy egy korlátozott sávszélességű kliens jelentős RAM-ot fogyasszon egy sebezhető szerveren. A kutatók szerint a teszteredmények azt mutatják, hogy az Envoy 1.37.2 10 másodperc alatt 32 GB memóriát ért el, az Apache httpd 2.4.67 18 másodperc alatt, az Nginx 1.29.7 45 másodperc alatt, míg a Microsoft IIS a Windows Server 2025-ön 45 másodperc alatt 64 GB-ot ért el.

A kutatók azt is megjegyzik, hogy a probléma nem csupán a dekódolt fejléc méretére korlátozódik. Számos védelem korlátozza a teljes dekódolt fejléc méretét, de ez a támadás számos kis fejlécmezőt használ ki, ahol a memóriahasználat a fejlécenkénti nyilvántartásból és a szerveroldali feldolgozásból ered, nem pedig a payload méretéből.

A cookie kezelés további hozzájárulást jelent a problémához egyes implementációkban. A HTTP/2 lehetővé teszi a Cookie fejléc külön mezőkre bontását, és az érintett esetekben ezeket nem számolták megfelelően a kérés mezőkorlátok ellen. Ez lehetővé tette a támadók számára, hogy sok fejlécobjektumot hozzanak létre, miközben a várt védelmi küszöbök alatt maradtak.

Az Apache httpd problémát CVE-2026-49975 néven követik. A javítás elérhető a mod_http2 2.0.41 verziójában, ahol a cookie fejlécet a LimitRequestFields ellen számolják. A javítás a httpd trunkban is megtalálható, bár a közzététel időpontjában még nem volt része a 2.4.x kiadásnak.

Az Nginx a 1.29.8 verzióban oldotta meg a problémát a

max_headers

direktíva bevezetésével, amely alapértelmezés szerint 1000-re van állítva. Azok az adminisztrátorok, akik nem tudják frissíteni, ideiglenesen letilthatják a HTTP/2-t a

http2 off;

parancs használatával.

Az Apache httpd telepítések számára, amelyek nem tudnak frissíteni a javított mod_http2 kiadásra, a javasolt megoldás a HTTP/2 letiltása a

Protocols http/1.1

beállításával. A

LimitRequestFieldSize

csökkentése szintén csökkentheti a hatást minden egyes áramlás esetén, de ez csak részleges megoldás, mivel a támadás áramlások és kapcsolatok között is megsokszorozható.

A Microsoft IIS, Envoy és Cloudflare Pingora esetében a közzététel időpontjában nem állt rendelkezésre megerősített javítócsomag. Később a kaliforniai kutatók arról számoltak be, hogy az Envoy javítócsomagokat adott ki június 3-án, bár a validálás még folyamatban volt. Ha nincs elérhető javítás, az adminisztrátoroknak le kell tiltaniuk a HTTP/2-t, vagy olyan komponenst kell használniuk, amely szigorú fejlécszámlálási korlátot érvényesít minden kérésnél.

A nyilvános HTTP/2 szolgáltatások adminisztrátorainak fel kell mérniük, hogy érinti-e őket a probléma, mielőbb alkalmazniuk kell a rendelkezésre álló frissítéseket, és biztosítaniuk kell, hogy a kérés fejlécszámlálási korlátok érvényesítve legyenek. Ha azonnali intézkedés nem lehetséges, a HTTP/2 letiltása a legbiztonságosabb ideiglenes megoldás.

További részletekért lásd az Openwall üzenetet.