Kedd óta elgé nagy a nyüzsgés a Windows TCP/IP stackjének hibájával kapcsolatban, amit a Microsoft az MS11-083 jelű csomaggal javított. Mint az ismeretes, egy zárt portra küldött UDP folyammal triggerelhető a hiba, ami igen meglepő, és (látszólag) jelentősen megnöveli a kihasználás lehetőségét, hiszen gyakorlatilag minden rendszeren találunk zárt UDP portot. 

A problémát egy 32-bites referenciaszámláló túlcsordulása okozza. A referenciaszámlálók azt tartják nyilván, hogy egy struktúrára hány helyről hivatkoznak - ha nincs hivatkozás, a struktúra által elfoglalt memóriaterület felszabadítható. A fent említett UDP csomagfolyam küldésével elméletileg elérhető, hogy a számláló elérje a maximumát, ezután pedig egy újabb inkrementáció nullázza az értéket (a számláló átfordul). Ezt azt eredményezi, hogy a kernel úgy fogja hinni, hogy a hivatkozott struktúra felszabadítható, a felszabadítás pedig meg is történik például egy egyszerű ICMP echo üzenet fogadása esetében. Ez után a hivatkozott (már szabad) memóriaterületen a támadó elhelyezheti saját kódját, amire azonban még néhány kernel objektum hivatkozni fog, így elméletileg elérhető rendszer szintű kódfuttatás. (A PaX patch már egyébként 2008 óta védelmet nyújt a hasonló sebezhetőségekkel szemben Linuxon)

Van azonban néhány bökkenő. Először is egyszerű matematikával az ember kiszámolhatja, hogy a számláló átfordulásához szükséges 2^32 csomag elküldéséhez hétköznapi hálózaton hosszú hetek (mérések szerint nagyjából 50 nap) szükségesek. Ha ezt sikerül kivárnunk, jó eséllyel kékhalállal megpusztul a rendszer, de a legtöbb támadó valószínűleg inkább kibérelne egy botnetet néhány dollárért, mint hogy ennyi ideig malmozzon és várja, mikor szúrják ki a hálózaton a masszív UDP adatfolyamot - ha egyáltalán elérhető a célpont UDP-vel. Egy nem túl profi PoC exploit erre az esetre elérhető, működését az idő rövidsége miatt még nyilván nem sikerült ellenőrizni.

És akkor még nem beszéltünk a kódfuttatás esélyeiről: hogyan helyezzünk távolról egy megfelelő byte-szekvenciát a megfelelő memóriaterületre, éppen a felszabadulás után, de még éppen a számunka megfelelő kernel objektum hivatkozása előtt? Jó kérdés...

Mindent összevetve kétségtelenül egy érdekes hibáról van szó, az azonban nem túl valószínű, hogy a gyakorlatban erre támaszkodva fognak támadásokat végrehajtani. 

Zárszóként álljon itt egy kamu videó, aminek legalább a zenéje jó :)