Korábbi posztok alkalmával már felmerült, hogy érdemes lenne kicsit részletesebben körbejárni a népszerű böngészők aktuális megerősítő megoldásait, hogy minél többen képbe kerüljenek az oprendszer szintű védelmek, sandboxok és védett módok útvesztőjében. Szerencsére a Microsoft nem rég kihozott egy áttekintő posztot az Internet Explorer 10 biztonsági újdonságairól, remek motivációt adva számomra a sorozat elkezdéséhez :

Ez az elemzés nem tér ki a védelmekkel kapcsolatos összes aspektusra (pl. tényleges ASLR entrópia a különböző konfigurációkban, SW vs. HW DEP), ehhez egyedül kevés vagyok. Javítások, kiegészítések, új teszt eredmények kommentbe jöhetnek, a posztot ezek alapján folyamatosan fogom frissíteni.

Frissítés 2012.04.09: Balássy György javaslata alapján frissült az ASLR-ről szóló rész és írtam az Windows 8 AppContainerről is (Eric Law cikke alapján)

A táblázatban csak a leggyakoribb drive-by exploitok elleni védelmeket szedtem össze, az ActiveX porblémákról, XSS védelemről, URL szűrésről és más nyalánkásgokról nem lesz szó.

Védett mód

A legismertebb védelmi mechanizmus, alapvetően a Mandatory Integrity Control nevű megközelítés megvalósítása. Az új Windows változatokban a folyamatokat és az ezek által használható erőforrásokat integrtitási szintekhez rendelik, egy folyamat pedig csak a vele megegyező vagy alacsonyabb szintű erőforrásokat használhatja. Az Internet Explorer fő megjelenítő folyamatai Alacsony integritásúak, így pl. csak a fájlrendszer egy erősen korlátozott részéhez (ideiglenes fájlok könyvtára, sütitár, stb.) illetve a Registry számukra kijelölt ágaihoz férhetnek hozzá, valamint az IPC mechanizmusok is erősen korlátozottak. Ez természetesen problémát okozhat egyes funkciók illetve kiterjesztések esetén, így az IE két brókerfolyamatot tart fent, melyeken keresztül szabályozott körülmények között (pl. felhasználói megerősítássel) válnak hozzáférhetővé a Közepes illetve Magas integritási szintű erőforrások.

Az elmúlt években persze több példa is volt arra (legutóbb a Pwn2Own-on), hogy a támadóknak sikerült átverekedniük magukat ezeken a korlátozásokon. Mint minden szoftverváltozás megvalósításakor, itt is becsúszhattak hibák, a kernel-szintű oprendszer bugokat ez a mechanizmus csak korlátozott mértékben tudja visszafogni, nem beszélve a magasabb integritási szinten futó kiegészítők okozta poklokról, lásd még a Flash/Java részt! Ezzel együtt a Védett Mód bevezetése kiemelte a böngészőt a könnyű prédák sorából, jelentősen megemelve a teljes értékű exploitok megírásához szükséges erőbefektetést, hiszen egy szimpla IE bug már nem elég a boldoguláshoz.

Address Space Layout Randomization (ASLR)

Az először a PaXTeam által felvetett és megvalósított módszer lényege, hogy a támadó dolgát a folyamatok memóriaterületének véletlen elrendezésével nehezítik meg. Komoly fejtörést okozhat ugyanis, ha az ember nem tudja, merre hagyta a shellkódját, vagy hogy tulajdonképpen hol is vannak a szépen felsorakoztatott ROP gadgetjei (ROP-ról is kéne már egy poszt...).

Sajnos erre a trükkre nincs minden DLL felkészítve, ezért sokszor lehetőség van a mindig azonos helyeken látszó könyvtárak kódjának újrahasznosítására, ezen kívül böngészők esetében bevett módszer a heap-spraying alkalmazása, mely során a kívánt adatokat szétszórjuk egy nagyobb memóriaterületen, és reménykedünk benne, hogy a vezérlés erre a területre kerül. 

A Windows 8 és az IE10 két jelentős újdonsága a 64-bites címtereket kihasználó High-Entropy ASLR, valamint a nem /DYNAMICBASE-el forgatott könyvtárakat is randomizáló EnforcedASLR lesz. Fontos apróság, hogy a HEASLR az alacsony integritíási szinten futó ún. Content folyamatokban csak akkor lesz alapértelmezetten engedélyezett, ha a böngésző a Metro felületen fut.

Data Execution Prevention (DEP)

A folyamatok memóriaterületének bizonyos részei nem-futtathatóként jelölhetők meg, így ha az ide helyezett adatokat nem tudjuk kódként lefuttatni. Megkerülésére alkalmasak a különböző könyvtárakhoz visszatérő támadások (szimuláljunk eljáráshívást, szépen berendezve a stacket, majd átadva a vezérlést egy beépíttett, könyvtári függvénynek), illetve a ROP.

Pointer kódolás

(Rázártam a tabot arra a cikkre, amiben le volt írva, hogy az IE hogy áll ezen a téren :(( )

Előfordulhat, hogy egy memória korrupciós hiba nem enged közvetlen EIP vezérlést, de a támadónak alkalma nyílik felülírni néhány függvénypointert, melyeket későb az alkalmazás felhasznál, így a támadó által meghatározott helyre adva a vezérlést. A programozónak azonban lehetősége van arra, hogy a pointereket inicializáláskor egyszerű XOR eljárással kódolja, majd felhasználáskor visszakódolja azokat. A kódolás kulcsa rendszerindításonként más és más lesz, így egy támadó nem fogja tudni, hogy mi az az új pointer érték, ami felhasználáskor a kívánt címre dekódolódik.

SafeSEH

A Windowsban alkalmazott strukturált kivételkezeléskor az operációs rendszer egy kivételkezelő eljárások mutatóit tartalmazó láncolt listán lépked végig abban a reményben, hogy megtalálja a megfelelő kivételkezelő eljárást. Amennyiben (tipikusan stack túlcsordulásnak köszönhetően) egy támadónak sikerül átírnia a struktúra pointereit, átveheti a vezérlést a program futása felett a következő kivétel érkezésekor.

A SafeSEH egy fordítás idejű védelem, ami metaadatokat rendel a generált állományokhoz, melyek megadják a biztonságosan hívható kivételkezelők listáját. Ezt a listát az operációs rendszer kivétel keletkezésekor ellenőrzi.

SEHOP

A SEHOP egy futásidejű védelem ami a folyamatok betöltésekor a strukturált kivételkezelő lánc végére egy speciális kivételkezelőt helyez. Kivétel keletkezésekor az operációs rendszer ellenőrzi, hogy a láncolt listán el lehet-e jutni eddig a speciális eljárásig - ha nem, az azt jelenti, hogy valaki matatott a mutatókkal, tehát jobb, ha lelőjük a program futását. 

AppContainer

A Windows 8 újdonsága az AppContainer, ami egy, az Android alkalmazás jogosultság-kezeléséhez hasonló védelmi réteget vezet be az operációs rendszerre. Minden telepített alkalmazáshoz megadhatók különböző jogosultság igények, melyeket egyrészt tudomásul kell vennie a felhasználónak telepítéskor, másrészt a futás során csak az engedélyezett műveleteket végezheti el a program. Az Internet Explorer jogosultságai igen koráltozottak lesznek, a böngésző nem fogadhat bejövő kapcsolatokat, de nem férhet hozzá a helyi hoszt vagy hálózat szolgáltatásaihoz sem, ami érdekes problémákat eredményezhet (bővebb infó itt), de az exploit payloadok mozgásterést is erősen behatárolja. 

Flash/Java

Windows 7-en az IE9 Alacsony integritású folyamatban futtatja a Flash Playert, vagyis a lejátszó is védett módú.

A Java Windows 7-en Közepes integritású folyamatban fut, vagyis egy Java bug mindent visz.