[ Memóriavédelmi technológiák a Windows Vista-ban ]

Memóriavédelmi technológiák a Windows Vista-ban

  • 2006-05-29 13:50
  • Forrás: Michael Howard's blog
A Windows Vista "minden id?k" legbiztonságosabb operációs rendszerének készül, így egy sor olyan biztonsági újítás található benne, mely nem csak a felhasználó által elkövetett véletlen módosításoktól, de a kívülr?l érkez? veszélyekkel szemben is védi a rendszert. A beépített t?zfalon és spyware-sz?résen kívül, új megoldások születtek az operatív tár, azaz a memória védelmére is.


Address Space Layout Randomization

Az ASLR a buffertúlcsordulásos támadások elleni védekezés jegyében született és a Beta 2-es verzióban már alapértelmezésként engedélyezve van. Az eljárás lényege, hogy a Windows a rendszerkódokat sosem azonos, hanem véletlenszer?en kiválasztott memóriacímekre tölti be. A már jól ismert memóriacím-kiolvasásos támadások ellen ez egy hatásos védelem lehet, bár azt le kell szögezni, hogy ez sem csodafegyver, de az ártalmas kódok munkáját eléggé megnehezíti. Számos vírus képes kiolvasni bizonyos folyamatok memóriacímét, így ezekre a címekre speciálisan megírt kódot juttatva befolyásolhatja a rendszer m?ködését. Az ASLR feladata, hogy a ezeket a memóriacímeket folyamatosan vándoroltassa a fizikai memórián belül, így lényegében "összezavarva" a rosszindulatú programokat. A Windows Vista Beta 2-es verzióban egy DLL vagy EXE betöltése 256 különféle helyre történhet, ami azt jelenti, hogy a támadónak 1/256-od esélye van, hogy eltalálja azt a címet, ahol a megfert?zni kívánt kód éppen tartózkodik. Ez végeredményként meglehet?sen nehézzé teszi egy-egy vírus számára, hogy "helyesen m?ködjön".

Hogy egy példán szemléltessük az ASLR m?ködését, nézzük meg pár kritikus fontosságú Windows komponens betölt?tését:

wsock32.dll  (0x73ad0000)
winhttp.dll  (0x74020000)
user32.dll   (0x779b0000)
kernel32.dll (0x77c10000)
gdi32.dll    (0x77a50000)


A rendszer újraindítását követ?en az alábbi képet kapjuk:

wsock32.dll  (0x73200000)
winhttp.dll  (0x73760000)
user32.dll   (0x770f0000)
kernel32.dll (0x77350000)
gdi32.dll    (0x77190000)


Amint látható, a különféle kernelmodulok minden alkalommal más memóriacímen foglalnak helyet, így az ártalmas kódnak fert?zés el?tt minden alkalommal fel kéne térképeznie a memóriát. Ez ugyan lehetetlenné nem, de nehezebbé teszi m?ködésüket.


Data Execution Protection (más néven NX)

Az NX m?ködésének mind processzor- mind operációs rendszer szinten támogatottnak kell lennie. A legtöbb buffertúlcsordulásos fert?zést kiváltó vírus adatként kerül be a rendszerbe, mely adat kés?bb a memóriába tölt?dve kódként viselkedik, azaz le akar futni. Az NX az adatok megcímkézésével (non-executable - nem futtatható) gondoskodik arról, hogy a memóriába beolvasott adatszegmensek sose válhassanak futtathatóvá, azaz kóddá. Más szavakkal: a memóriában semmilyen adat nem válhat futtathatóvá. A nagy nyilvánosságot kapott WMF-sérülékenység is pontosan err?l szólt, de mivel a mai rendszerek még elenyész? számban támogatják ezt a technológiát, a rosszindulatú kódot hordozó WMF-képek sok számítógépet béníthattak meg. A Windows Vista-ban egy ilyen ártalmas kódot tartalmazó adat (pl. WMF képfájl) már nem lenne képes fert?zésre, mert az NX adatként kezelné a képfájlt, így lehetetlenné téve annak kódként való lefuttatását. Az NX-szel korábban már DEP (Data Execution Prevention) néven találkozhattunk a Windows XP Service Pack 2-ben és a Windows Server 2003-ban is.


Function Pointer Obfuscation (FPO)

A függvénymutatók is a támadások kedvelt célpontjai, mivel a rendszerkód bizonyos fix részeire hivatkoznak, azokat hívják meg, így a vírus könnyedén manipulálhatja a rendszer m?ködését. A Windows Vista ezen változók bekódolásával védekezik azok "eltérítése" ellen, az egyes pointer-ek csak akkor kerülnek visszafejtésre, amikor azokra a rendszernek szüksége van. Mivel így minimális id?t töltenek "felfedve" az ártalmas kódok ezeken a mutatókon keresztül nem lesznek képesek rendszerfüggvényeket meghívni.


Természetesen az imént felsorolt memóriavédelmi technikák - f?leg mivel viszonylag kés?n kerültek implementálásra - okozhatnak némi kompatibilitási és teljesítménybeli zavarokat, de a Vista fejleszt?csapat mindenképpen be akarta vezetni az új eljárásokat még a Beta 2-ben, hogy a visszajelzések alapján id?ben finomhangolhassák az eljárásokat.