Memóriavédelem a Windows Vistában
kategória: Biztonság — forrás: lacy / mstechnet — dátum: 2007-05-19 — értékelés: 3.82 —
A felhasználói fiókok felügyelete (UAC), a továbbfejlesztett tűzfal, az Internet Explorer 7 biztonsági funkciói, Defender csak hab a tortán! A teljes biztonság eléréséhez a memóriavédelem terén is új technikákat kellett kidolgozni.
ASLR - Address Space Layout Randomization
Véletlenszerű címterület elrendezés
A Windows Vista beta 2 verziója óta elérhető, alapértelmezetten bekapcsolt védelmi technika, amely lehetetlenné teszi például a puffertúlcsordulásos támadások indítását.. Lényege, hogy bootolásakor a rendszerkódok véletlenszerű helyre töltődnek be a memóriába. A rendszer így felveheti a harcot a "return-to-libc" típusú támadások ellen. Az ASLR feladata a rendszerfunkciók belépési pontjainak (entry points) szétszórása a memóriába, előre kiszámíthatatlan helyekre. Egy dll vagy exe betöltése 256 helyre lehetséges a Vista beta2-ben, így a támadónak 1/256-od esélye van arra, hogy eltalálja azt a címet ahol a fertőzni kívánt kód található.
Az ASLR a következőkre terjed ki:
- visszatérési verem (a második béta változatokban)
- heap- (vagy halom-) memória
- az operációs rendszer részeként az összes bináris állomány.
Minden más .exe vagy .dll állománynak kifejezetten kérni kell az ASLR-lehetőséget a megfelelő PE-fejlécmutató (Portable Executable Header) beállításával.
Lássuk működés közben (után?) - Néhány fontos rendszerkomponens betöltődése...
- wsock32.dll (0x73ad0000)
- winhttp.dll (0x74020000)
- user32.dll (0x779b0000)
- kernel32.dll (0x77c10000)
- gdi32.dll (0x77a50000)
Újraindítás után...
- wsock32.dll (0x73200000)
- winhttp.dll (0x73760000)
- user32.dll (0x770f0000)
- kernel32.dll (0x77350000)
- gdi32.dll (0x77190000)
Mint látható, a rendszerkomponensek mindig más memóriacímeken foglalnak helyet, így megnehezítve az exploitok életét. A technika nem garancia semmire, de megnehezíti a támadó munkáját, ám ettől még törekedni kell biztonságos kódok írására!
DEP - Data Execution Prevention
Adatfuttatás megelőzés
A helytelen memóriahasználat azt jelenti, hogy valamilyen program egy nem futtatható kódot tartalmazó memóriaterületet erővel kódfuttatásra akar használni. Tipikusan ilyenek azok a rosszindulatú programok, amelyek egy esetleges puffertúlcsordulásos sérülékenységet kihasználva tárolnak le futtatható gép utasítások sorozataként értelmezhető adatokat (="program") verem-, adat-, heap- stb területként kijelölt memóriába, majd az így betöltött kódnak adják át a vezérlést.
A Data Execution Prevention (adatfuttatás-megelőzés) vagy NoExecute (ne futtatsd) leegyszerűsítve olyan biztonsági technológia, amely a programok memóriahasználatának helyességét felügyeli. Ha a DEP észreveszi, hogy valamilyen program vagy folyamat helytelenül próbálja használni a memóriát - azaz illegális helyen akar kódot futtatni -, kíméletlenül lezárja azt, és figyelmeztést küld a felhasználónak.
A DEP a sérülékenységgel nem tud mit kezdeni, a puffertúlcsordulást és a program adatainak eltárolását nem akadályozza meg, de akkor már közbe tud avatkozni, amikor a rossz helyre tárolt kód futtatására kerülne sor. A DEP-nek két alapvető formája létezik: hardveres és szoftveres.
A Data Execution Prevention (adatfuttatás-megelőzés) vagy NoExecute (ne futtatsd) leegyszerűsítve olyan biztonsági technológia, amely a programok memóriahasználatának helyességét felügyeli. Ha a DEP észreveszi, hogy valamilyen program vagy folyamat helytelenül próbálja használni a memóriát - azaz illegális helyen akar kódot futtatni -, kíméletlenül lezárja azt, és figyelmeztést küld a felhasználónak.
A DEP a sérülékenységgel nem tud mit kezdeni, a puffertúlcsordulást és a program adatainak eltárolását nem akadályozza meg, de akkor már közbe tud avatkozni, amikor a rossz helyre tárolt kód futtatására kerülne sor. A DEP-nek két alapvető formája létezik: hardveres és szoftveres.
Hardveres DEP
A hardverrel érvényesített DEP olyan architektúrában lehetséges, amelyben a processzor támogatja azt.
A "jobb" processzorok (az összes 64bites, valamint számos 32bites AMD és Intel CPU) a memória kezelésekor belsőleg használt lapozótábla-bejegyzések utolsó bitjét NX (No eXecute) mutatóként értelmezik: 0 esetén a hivatkozott területen lehetséges, 1 értéknél tilos a kód futtatása. (Megjegyzendő, hogy az NX az eredeti AMD-s elnevezés, az Intel terminológiájában XD bitről - eXecute Disable - beszélünk.)
Előfordulhat az is, hogy legitim program futtatna adatterületen gépi kódot, de a DEP miatt nem lenne lehetséges. Az ilyen eseteken segít az a lehetőség, hogy a biztosan nem ártó szándékú programokat meg lehet jelölni; fel lehet ruházni olyan jogosultsággal, hogy az "adatokat" is futtathassák.
A Windows XP, Server 2003 és Vista változatok elég okosak ahhoz, hogy a processzort felismerve kihasználják a hardveres DEP előnyeit, sőt még ennél is okosabbak, mert ha a processzor nem támogatja, akkor emulálják.
A "jobb" processzorok (az összes 64bites, valamint számos 32bites AMD és Intel CPU) a memória kezelésekor belsőleg használt lapozótábla-bejegyzések utolsó bitjét NX (No eXecute) mutatóként értelmezik: 0 esetén a hivatkozott területen lehetséges, 1 értéknél tilos a kód futtatása. (Megjegyzendő, hogy az NX az eredeti AMD-s elnevezés, az Intel terminológiájában XD bitről - eXecute Disable - beszélünk.)
Előfordulhat az is, hogy legitim program futtatna adatterületen gépi kódot, de a DEP miatt nem lenne lehetséges. Az ilyen eseteken segít az a lehetőség, hogy a biztosan nem ártó szándékú programokat meg lehet jelölni; fel lehet ruházni olyan jogosultsággal, hogy az "adatokat" is futtathassák.
A Windows XP, Server 2003 és Vista változatok elég okosak ahhoz, hogy a processzort felismerve kihasználják a hardveres DEP előnyeit, sőt még ennél is okosabbak, mert ha a processzor nem támogatja, akkor emulálják.
Szoftveres DEP
|
Az NX vagy XD bittől független szoftveres DEP, azaz Safe Structured Exception Handling (SafeSEH - biztonságos struktúrájú kivételkezelés) esetén kicsit bonyolultabban valósítható meg - de nem lehetetlen - a verem, a heap vagy az adatszegmens rendszerszintű figyelése. A Windows esetében mint azt a név is jelzi, a szoftveres DEP a kivételkezelő mechanizmusokon keresztül érvényesül. A SafeSEH követelményeinek eleget tévő programnak rendelkezniük kell ilyen funkciókkal, és futtatáskor regisztrálniuk kell a saját kivételkezelő eljárásukat.
Persze vannak olyan (régebbi) programok, amelyek nem a SafeSEH-megfelelőség szerint készültek. A szoftveres DEP ilyenkor úgy érvényesül, hogy a rendszer a kivételnek megfelelő, az azt kezelő funció hívása előtt megvizsgálja: maga a kivételkezelő kód futtatható memóriaterületen van-e.
Végső soron a hardveres DEP is a kivételkezelésbe torkollik bele, mert az adatterületen történő kódfuttatási kísérlet kivételt generál, amit az operációs rendszer kezel.
Összegezve: akár hardveres, akár szoftveres DEP-ről van szó, a rendszer nem javítja ki például a puffertúlcsordulásos sérülékenységeket, és nem akadályozza meg a memóriaterületek felülírását. Amikor azonban a vezérlés adatterületre kerülne, akkor a hardveres esetben könyörtelenül hardveres kivétel generálódik, amelynek értelmezésével le lehet fülelni a goromba ágenseket. Szoftveres DEPnél a kivételgenerálást az operációs rendszer szoftveresen végzi. Ennek a könyörtelensége, azaz a "jósága" attól függ, mennyire érzékenyen figyel a rendszer a helytelen memóriahasználatra.
A DEP másodlagos áldásait az alkalmazásokat és eszközmeghajtókat fejlesztők használhatják ki nagyszerűen, hiszen egyrészt kényszerítve vannak a memóriaterületek respektálására, és ez megfelelő programozói gyakorlat rögzüléséhez vezet. Másrészt a programozói hibából felülírt vezérlés nem "kékíti el a képernyőjüket" fejlesztés közben.
Persze vannak olyan (régebbi) programok, amelyek nem a SafeSEH-megfelelőség szerint készültek. A szoftveres DEP ilyenkor úgy érvényesül, hogy a rendszer a kivételnek megfelelő, az azt kezelő funció hívása előtt megvizsgálja: maga a kivételkezelő kód futtatható memóriaterületen van-e.
Végső soron a hardveres DEP is a kivételkezelésbe torkollik bele, mert az adatterületen történő kódfuttatási kísérlet kivételt generál, amit az operációs rendszer kezel.
Összegezve: akár hardveres, akár szoftveres DEP-ről van szó, a rendszer nem javítja ki például a puffertúlcsordulásos sérülékenységeket, és nem akadályozza meg a memóriaterületek felülírását. Amikor azonban a vezérlés adatterületre kerülne, akkor a hardveres esetben könyörtelenül hardveres kivétel generálódik, amelynek értelmezésével le lehet fülelni a goromba ágenseket. Szoftveres DEPnél a kivételgenerálást az operációs rendszer szoftveresen végzi. Ennek a könyörtelensége, azaz a "jósága" attól függ, mennyire érzékenyen figyel a rendszer a helytelen memóriahasználatra.
A DEP másodlagos áldásait az alkalmazásokat és eszközmeghajtókat fejlesztők használhatják ki nagyszerűen, hiszen egyrészt kényszerítve vannak a memóriaterületek respektálására, és ez megfelelő programozói gyakorlat rögzüléséhez vezet. Másrészt a programozói hibából felülírt vezérlés nem "kékíti el a képernyőjüket" fejlesztés közben.
DEP Opciók
Windows Vistában az opciók a BCD (Boot Configuration Data) nevű struktúrába kerültek, ahol az adminisztrátorok más lehetőségek mellett a DEP-et, azaz a Vista esetében az "NX-házirendet" is állíthatják a bcdedit.exe parancssori eszközzel. A paraméterek nélkül futtatott bcdedit parancs megmutatja az alapvető beállításokat. A "Boot Loader" szakaszban alapesetben ezt látjuk:
nx OptIn
Ez a 32 bites Vistánál azt jelenti, hogy alapesetben a korábbi platformokhoz hasonlóan csak a futtatható rendszerfájlokra érvényes a védelem. A 64 bites rendszernél minden 64 bites alkalmazás NX-védett, a 64 bites rendszeren futó 32 bites programok védelme pedig megfelel a 32 bites platforménak.
A bcdedit kényelmes lehetőség a BCD paramétereinek állítására is. Az NX-házirend beállítására a következőképpen kell használni:
A bcdedit kényelmes lehetőség a BCD paramétereinek állítására is. Az NX-házirend beállítására a következőképpen kell használni:
bcdedit /set nx szabály_szint
ahol a szabály_szint lehetséges értékei a következők:
- OptIn (alapbeállítás)
A DEP csak a Windows saját (futtatható) rendszerállományaira és alkalmazásaira terjed ki.
- OptOut
Ebben az esetben a DEP minden futó folyamatra érvényes lesz, de a felhasználók a Vezérlőpult / Rendszer appletjének segítségével létrehozhatnak kivétellistákat; az ezekben felsorolt programokra az operációs rendszer nem alkalmazza a memóriavédelmet. A fejlesztők az Application Compatibility Toolkit segítségével ugyancsak kivonhatják a programokat a DEP alól.
- AlwaysOn
A DEP ennél az opciónál is minden folyamatra kiterjed, de a rendszer itt nem enged meg semmilyen felhasználói/fejlesztői kivételezést, azaz semmilyen listával vagy programozói fogással sem lehet kivonni semmilyen folyamatot a DEP védelme alól.
- AlwaysOff
Az operációs rendszer semmilyen programot sem lát el DEP-védelemmel. A DEP ugyanúgy nem érvényesül a futtatható rendszerállományokon, ahogyan a felhasználói programokon sem.
FPO - Function Pointer Obfuscation
Függvénymutató elhomályosítása
Az ismert memóriapozíción található függvénymutatók (long-lived) is támadások célpontjai lehetnek, mivel ismert címen tartózkodnak és olyan függvényekre mutatnak, amelyeket meghívnak a kódban. Windows Vistában számos közismert című függvénymutató kódolva van és csak akkor kerülnek dekódolásra amikor a rendszernek ténylegesen szüksége van rájuk.
A DEP részt Kelemen László írta a Microsoft Technet berkein belül!
