Vészhelyzeti javítást kapott a .NET a kritikus Brotli-sebezhetőség miatt

A modern webes infrastruktúra gerincét alkotó adatátviteli optimalizációk újabb sérülékenységi pontot fedtek fel. A szoftverfejlesztők széles körében alkalmazott Brotli tömörítő C-nyelvű kibontó moduljában olyan súlyos biztonsági rést találtak, amely a feldolgozó folyamatok memóriájának összeomlásához vagy jogosulatlan manipulációjához vezethet.

A biztonsági közösségben „Broccoli2Shell”, „Node2Shell” és „HTTP2Shell” néven ismertté vált sebezhetőség azért rendkívül veszélyes, mert a támadáshoz nincs szükség előzetes hitelesítésre . Egy speciálisan összeállított, tömörített HTTP-adatfolyam beküldésével a távoli támadók szolgáltatásmegtagadást (DoS), memóriaszivárgást vagy akár tetszőleges programkód futtatását érhetik el a célrendszeren .

Fontos: A Microsoft a havi rendszeres javítási cikluson kívül, úgynevezett out-of-band (soron kívüli) frissítésként tette közzé a javítócsomagokat . Ez a lépés egyértelműen jelzi, hogy a gyártó a sérülékenységet a legmagasabb kockázati besorolásúnak tekinti .

A problémát hivatalosan a CVE-2026-111497 azonosító alatt tartják nyilván, és a Google 9,2-es CVSS kockázati pontszámmal értékelte a lehetséges 10-ből . A sérülékenység forrása egy puffer-túlcsordulás (out-of-bounds write), amely a Brotli kicsomagoló komponensét érinti az 1.0.3-as és az 1.2.0-s verziók között .

A hibát az OpenAI Codex Security csapata fedezte fel egy biztonsági szimuláció során. Bár a mögöttes forráskódbeli hibát a nyílt forráskódú projektben már korábban módosították, hivatalos biztonsági figyelmeztetés és stabil kiadás hiányában a sérülékeny kód beépült számos népszerű futtatókörnyezetbe és fejlesztői csomagba .

A láncreakció a múlt héten indult a Node.js ökoszisztémában, majd a felhős környezetek vizsgálata során kiderült, hogy a Brotli könyvtárat beágyazva használó eszközök tömege érintett . A felhőbiztonsági elemzések szerint a nyilvános felhős környezetek több mint 90%-ában jelen van a sebezhető kód valamelyik implementációja . A Microsoft most a .NET futtatókörnyezet, a Visual Studio és a PowerShell érintett verzióihoz tette elérhetővé a védelmet nyújtó frissítéseket .

Hogyan működik a hiba a .NET-ben?

A hiba lényege a streaming (folyamatos adatfolyamú) kicsomagolás során fellépő állapotkezelési anomália. Amikor a kicsomagoló egy érvénytelen blokkváltást kap a bemeneten, azt nem formátumhibaként kezeli, hanem úgy érzékeli, mintha további adatokra lenne szüksége. Ennek következtében a beérkező bájtokat folyamatosan hozzáfűzi egy rögzített, 8 bájtos belső pufferhez, túllépve annak határait, ami felülírja a szomszédos memóriaterületeket .

A Microsoft hivatalos biztonsági tájékoztatója szerint egy alapértelmezett, „dobozos” .NET vagy ASP.NET Core telepítés nem aktiválja automatikusan a Brotli kibontást . Az alkalmazások akkor válnak közvetlenül sebezhetővé, ha az alábbi három funkció valamelyikét explicit módon bekapcsolták vagy használják a kódban :

Kérés-kitömörítés (ASP.NET Core request decompression): amikor a bejövő HTTP kérések törzsét a szerver automatikusan kibontja .
Válasz-kitömörítés (HttpClient response decompression): amikor a .NET alapú kliensprogramok külső szerverek tömörített válaszait fogadják és automatikusan dekompresszálják .
Közvetlen API-hívások: a System.IO.Compression névtérben található natív Brotli interfészek (BrotliStream) közvetlen programozói meghívása .

csharp

// Sebezhető konfigurációs minta, ha nincs frissítve a futtatókörnyezet:
builder.Services.AddRequestDecompression(options =>
{
    options.Decompressors.Add("br", () => new BrotliDecompressorProvider());
});

Amennyiben egy publikus weboldal vagy API-végpont fogad tömörített adatokat, a támadó anélkül küldhet be manipulált kérést, hogy bármilyen felhasználói névvel vagy jelszóval rendelkezne . A memóriahiba kihasználásával a támadó leállíthatja a webszolgáltatást, kiolvashatja a folyamat memóriájában tárolt titkokat, vagy emelt jogosultságokat szerezhet a szerveren .

A sebezhetőség a modern szoftverfejlesztés és üzemeltetés szinte minden rétegére hatással van:

Szoftverfejlesztők és szoftverházak: Különösen azok a csapatok, amelyek .NET 8, .NET 9, .NET 10 vagy .NET 11 Release Candidate verziókon fejlesztenek nagy forgalmú mikroszolgáltatásokat vagy webalkalmazásokat .
Rendszergazdák és DevOps mérnökök: Akik Windows és Linux szervereken konténereket (Docker, Kubernetes) és webes végpontokat üzemeltetnek .
API-integrációt végző vállalatok: Bármely szervezet, amelynek belső rendszerei a háttérben külső partnerek webszolgáltatásait hívják meg HttpClient használatával .

A hazai vállalati szférában a Microsoft technológiai ökoszisztémája hagyományosan piacvezető. Magyarországon a pénzügyi intézmények, banki háttérrendszerek, biztosítók, valamint a hazai KKV-k egyedi ERP- és webalkalmazásai túlnyomórészt a .NET keretrendszerre épülnek. Egy ilyen súlyú, hálózaton keresztül kihasználható távoli kódfuttatási rés közvetlen fenyegetést jelent a hazai kritikus infrastruktúrákra.

Európai uniós szinten az incidens közvetlenül kapcsolódik a szigorodó szabályozási környezethez:

NIS2 irányelv: A kiberbiztonsági tanúsításra és incidenskezelésre kötelezett szervezetek számára a kritikus (CVSS 9.0 feletti) sebezhetőségek soron kívüli javítása kötelező elvárás. A javítatlanul hagyott, internet felé nyitott végpontok súlyos megfelelőségi bírságot és vizsgálatot vonhatnak maguk után.
Szoftveres ellátási lánc biztonsága (Cyber Resilience Act): Az eset tökéletesen rávilágít a beágyazott nyílt forráskódú komponensek kockázatára, ahol egy kis méretű C-könyvtár sebezhetősége egyszerre rázza meg a Node.js, a Python és a .NET világát .

Érdemes tudni: Bár a biztonsági kutatók már közzétettek működő demonstrációs kódokat (Proof-of-Concept) a nyilvános felületeken, aktív, vadonbeli visszaélésekről egyelőre nem érkezett hivatalos jelentés . Ugyanakkor a javítócsomagok megjelenésével a támadók órák alatt visszafejthetik a hibát, és automatizált scannerekkel kezdhetik pásztázni a nyitott webkiszolgálókat .

A legnagyobb gyakorlati csapdát a saját függőségekkel csomagolt (self-contained) alkalmazások és a konténerek jelentik . Ha a rendszergazda pusztán a kiszolgáló operációs rendszerén frissíti a .NET futtatókörnyezetet, az nem javítja automatikusan azokat az alkalmazásokat, amelyek saját magukba fordítva hordozzák a .NET futtatóállományait . Ezeket a konténer-image-eket és önálló programokat a frissített SDK-val újra kell fordítani és újra kell telepíteni .

Javasolt teendők és védelmi lépések

Futtatókörnyezetek azonnali frissítése: Telepítse a kiadott soron kívüli biztonsági frissítéseket a .NET 8 (8.0.33), .NET 9 (9.0.22), .NET 10 (10.0.14) és .NET 11 RC3 verziókra .
Fejlesztői környezetek karbantartása: Frissítse a munkaállomásokon futó Visual Studio és PowerShell szoftvereket a legfrissebb alverziókra .
Konténerek újrafordítása: Az összes olyan Docker- és OCI-konténer alapimage-et (base image) frissíteni kell, amely .NET runtime-ot tartalmaz, majd a konténereket újra kell publikálni az éles rendszerekben .

Ideiglenes védelmi intézkedések (ha az azonnali frissítés nem kivitelezhető):

Brotli tiltása a tűzfalon: Állítsa be a peremhálózati fordított proxyt (reverse proxy), terheléselosztót vagy alkalmazásszintű tűzfalat (WAF) úgy, hogy blokkolja vagy távolítsa el a Content-Encoding: br fejléccel érkező bejövő kéréseket .
Kitömörítés lekapcsolása az alkalmazásban: Az alkalmazás konfigurációjában ideiglenesen kapcsolja ki a kérés- és válaszkibontási modulokat a javítás telepítéséig .

Összegzés

A Brotli-sebezhetőség és a Microsoft vészhelyzeti válaszlépése intő példa arra, hogy a modern szoftveres ellátási láncban a legalapvetőbb hálózati segédprogramok is globális láncreakciót indíthatnak el . A 9,2-es súlyosságú rés nem hagy teret a halogatásnak: a tömörített adatokat fogadó .NET környezetek azonnali foltozása vagy a hálózati szintű átmeneti szűrés elengedhetetlen a vállalati szerverek védelmében .

Hogyan működik a hiba a .NET-ben?

Javasolt teendők és védelmi lépések

Összegzés

Források

Az IT-hét, esszenciában.