Védőgyűrűk

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2019. január 31-én felülvizsgált verziótól ; az ellenőrzések 5 szerkesztést igényelnek .

A védőgyűrűk egy információbiztonsági és funkcionális hibatűrő  architektúra , amely a rendszer- és a felhasználói jogosultsági szintek hardveres elkülönítését valósítja meg. A kiváltságok szerkezete több koncentrikus körként ábrázolható. Ebben az esetben az erőforrásokhoz maximális hozzáférést biztosító rendszermód ( supervisor mode vagy ring zero, ún. "gyűrű 0") a belső kör, míg a korlátozott felhasználói mód a külső. Hagyományosan az x86 mikroprocesszorcsalád négy védőgyűrűt biztosít.

A védőgyűrűk architektúrája általában szemben áll a kötelező címzésen alapuló rendszerekkel, amelyek a leírása szerint biztosítanak hozzáférést egy objektumhoz ( képesség  alapú biztonság ).

Megvalósítás

A több védőgyűrű támogatása a Multics operációs rendszer egyik forradalmi koncepciója volt , amely a mai UNIX-szerű operációs rendszerek előfutára. A legtöbb UNIX rendszer azonban csak 2 csengetést használ, még akkor is, ha a hardver több CPU módot támogat .

Sok modern CPU -architektúra (beleértve a népszerű x86 architektúrát is) tartalmaz valamilyen védelmet. Ennek ellenére a Windows NT operációs rendszer és a UNIX nem használja teljes mértékben ezeket a funkciókat. A Windows NT elődje, az OS/2 három gyűrűt használt: a 0-ás gyűrűt a kernelkódhoz és az eszközillesztő-programokhoz, a 2-es gyűrűt a privilegizált kódokhoz (I/O hozzáféréssel rendelkező programok) és a 3-ast a nem jogosult kódokhoz (majdnem minden felhasználói program).

Az eredeti Multics rendszer nyolc védőgyűrűvel rendelkezett, de sok modern rendszerben általában kevesebb van. A processzor a speciális gépi regisztereknek köszönhetően mindig tudja, hogy melyik gyűrűben fut a kód. Egyes rendszereken a virtuális memória területei gyűrűszámokhoz is hozzá vannak rendelve, és a kiváltságosabb gyűrű speciális jogokat kap (például valós memória címzése, a virtuális memória mechanizmusának megkerülése).

A gyűrűs mechanizmus erősen korlátozza azokat az útvonalakat, amelyeken keresztül a vezérlés átvihető egyik gyűrűről a másikra, és korlátozza a gyűrűn belül végrehajtható memóriaelérési műveleteket is. Általában van valamilyen utasítás (átjáró), amely átadja az irányítást egy kevésbé biztonságos gyűrűről egy biztonságosabb (alacsonyabb számozású) gyűrűre; ezt sok gyűrűs architektúrát használó operációs rendszerben felügyelői kérésnek nevezik. Ezt a mechanizmust úgy alakították ki, hogy korlátozza a véletlen vagy szándékos biztonsági megsértések lehetőségét.

A gyűrűvédelem egyes rendszereken kombinálható processzormódokkal (master/kernel/privileged mode versus slave/user/privileged mode). Az ezeket a módokat támogató hardveren futó operációs rendszerek mindkét védelmi módszert vagy csak az egyiket használhatják.

A védőgyűrű architektúra hatékony használatához szoros együttműködésre van szükség a hardver és az operációs rendszer között. Azok az operációs rendszerek, amelyeket úgy terveztek, hogy nagyszámú platformon futjanak, minden platformon eltérő módon implementálhatják a gyűrűs mechanizmust. A biztonsági modell gyakran két hozzáférési szintre egyszerűsödik: a "kernel" és a "felhasználói" szintre, bár a hardver részletesebb végrehajtási szinteket biztosít.

Felügyelő mód

A felügyelő mód ( Supervisor mode ) kifejezés a processzorok fejlesztői és gyártói általában a processzor legelőnyösebb működési módjára utalnak. Leggyakrabban ezt a módot az operációs rendszer kernelkódjának végrehajtására használják. Ez az üzemmód jellemzően az x86-os processzorok 0. védelmi gyűrűjének (Ring 0) felel meg, azaz korlátlan hozzáférést biztosít a processzor összes képességéhez, a perifériákkal való munkavégzéshez stb. Az ebben a módban működő kód főszabály szerint kezeli a rendelkezésre álló hardver erőforrásokat, megosztva azok használatát külön feladatok (folyamatok) között, és így tovább, ami ehhez a módnévhez vezetett.

A processzorok egyes fejlesztői és gyártói, például az ARM, nem használják a processzorok működési módjának osztályozását védőgyűrűk formájában. Ennek ellenére a legtöbb modern processzor (a legegyszerűbbek kivételével) általában több működési móddal rendelkezik, amelyek az ebben a módban elérhető jogosultságokban különböznek egymástól.

Hipervizor mód

Egyes modern processzorok további működési módot is biztosíthatnak, amelyet Hypervisor módnak neveznek . Általában ezt a módot a virtualizációs technológiák hardverszintű támogatására valósítják meg. Ez lehetővé teszi nemcsak több feladat egyidejű végrehajtását, hanem több operációs rendszer egyidejű futtatását is egyetlen processzoron jelentős teljesítményveszteség nélkül, maguk az operációs rendszerek megváltoztatása nélkül. Általános szabály, hogy ennek a módnak a használatakor az összes erőforrás teljes hozzáférése lehetséges a hypervisor módból. Ilyen esetben a felügyelő mód már nem a legkiváltságosabb, és számos kiemelt műveletet korlátoz. Amikor az operációs rendszerek privilegizált műveleteket hajtanak végre felügyelő módban, a vezérlés egy speciális programra – a hypervisorra – kerül át . A hypervisor ugyanúgy dönt a rendelkezésre álló hardvererőforrások több operációs rendszer általi használatáról, ahogy az operációs rendszerek maguk döntenek az erőforrásokról több feladat között. Lényegében a hipervizor általában egy kis kernel, amely több operációs rendszeren keresztül kezeli az erőforrások elosztását, és maguk az operációs rendszerek alatti rétegen fut. Emiatt az x86 terminológiában ezt a módot gyakran feltételesen ring −1-nek (Ring −1) nevezik.

Rendszerfelügyeleti mód (SMM)

A rendszerfelügyeleti mód a legkiváltságosabb végrehajtási mód az x86 / x86-64 [1] architektúrájú processzorokon (először a 386SL -ben jelent meg ). Az SMM mód (feltételesen "Ring -2"-nek) kiváltságosabb, mint a "Ring 0" és a hardveres hipervizor ( VT/AMD-v ) "Ring -1". Ez a mód felfüggeszti a normál kódvégrehajtást, és olyan speciális kódot kezd végrehajtani a rendszer RAM-ból (SMRAM), amely más módokban nem érhető el. Ez a kód hozzáfér az összes rendszermemóriához, beleértve a kernelt és a hypervisor memóriát is.

Joanna Rutkowska információkat tett közzé a Blue Pill sebezhetőségéről , amely lehetővé teszi tetszőleges kód futtatását SMM módban.

Interakciós modell a CPU és az operációs rendszer absztrakciós rétegei között

Az SMM módot először a 80386SL és i486SL MP-ekben valósították meg. Az Intel-486-tól kezdve ez a mód az IA-32 architektúra kötelező elemévé vált. Az SMM módot bizonyos műveletek végrehajtására tervezték, azzal a lehetőséggel, hogy teljesen elszigeteljék őket az operációs rendszertől. A processzor ebbe az üzemmódba csak az SMI# jel hardverével lép be. Nincs szoftveres mód erre az üzemmódra váltani. SMI megszakítás esetén a kezelő SMI kódja egy külön címtérben (SMRAM) fut le. Az SMI módba való áttérés idejére a megszakított folyamat kontextusa megmarad. Az SMM-kezelő végrehajtása során minden megszakítás le van tiltva. Az SMI-kezelő kódja csak SMRAM-ban futhat.

2006-ban Loïc Duflot egy nagyon furcsa támadást vezetett be az OpenBSD biztonsági rétegek mechanizmusa ellen, amely az SMM módot használta. Abban az időben az SMM mód nem volt védett, és tetszőleges kódot lehetett írni az SMRAM-ba. De aztán a rendszergyártók elkezdték védeni az SMM rendszert. Az SMM-ben végrehajtható kód tárolására egy speciális memóriaterületet osztottak ki, az SMRAM-ot, amely speciális védelmet kapott a chipkészlettől (pontosabban Memory Controller Hub). A legtöbb modern rendszeren már nem triviális az SMM jogosultságokkal rendelkező kód futtatása. Ehhez meg kell találni egy "lyukat" a chipkészletben vagy a BIOS-ban (még akkor is, ha kernel szinten van hozzáférésünk). Valójában a Black Hat 2008-on Las Vegasban Sherri Sparks és Shawn Embleton prezentációt tartott az SMM rootkitekről , de világossá tették, hogy rootkitjeik csak az év régebbi (2006 előtti) rendszereire tölthetők be. A konferencián szóba került az Intel BIOS-ban lévő "lyuk", amely lehetővé tette tetszőleges kód végrehajtását SMM módban. Aztán további két módot fedeztek fel az SMM módba való betörésre különböző rendszereken. Egy másik támadás, amelyet 2008 végén fedeztek fel, számos Intel rendszeren (és potenciálisan régebbi BIOS-szal rendelkező gépeken) működött.

Az SMM rootkitek (vagy ring-2 rootkitek) hozzáférést igényelnek a rendkívül biztonságos SMM memóriához, és a legtöbb modern rendszeren a támadónak ki kell használnia a "lyukakat" (amit nem triviális megtalálni).

Az SMM-támadásokat egy adott BIOS-verzióhoz (vagy BIOS-vonalhoz) és lapkakészlet-családhoz tervezték, például az Intel-lapkakészletek 3. vagy 4. sorozatához (azaz a Q35 és Q45, illetve az AMI és az AWARD BIOS elleni támadások eltérőek).

Intel vPro / Active Management Technology

Az Invisible Things Lab azt javasolta, hogy az Intel vPro/ Intel AMT technológia funkcionalitását hívják -3 gyűrűnek. [2] E technológia keretein belül a vPro technológiát támogató lapkakészletek független mikroprocesszort tartalmaznak ( ARC 4 architektúra), külön interfésszel rendelkeznek a hálózati kártyához, exkluzív hozzáféréssel egy dedikált RAM területhez (16 MB), DMA hozzáféréssel a főhöz. RAM. A rajta lévő programok a központi processzortól függetlenül futnak le, a firmware a BIOS kódokkal együtt, vagy egy hasonló SPI flash memórián kerül tárolásra (a kód kriptográfiai aláírással rendelkezik). A firmware része egy beágyazott webszerver. Az AMT alapértelmezés szerint le van tiltva, de a kód egy része még akkor is működik ebben a módban, ha az AMT le van tiltva. A -3 csengetési kód S3 alvó üzemmódban is aktív.

Lásd még

Jegyzetek

  1. Intel® 64 és IA-32 architektúrák szoftverfejlesztői kézikönyve. 3B. kötet: Rendszerprogramozási útmutató. 26. fejezet . PDF  (3,93 MB)
  2. Introducing Ring -3 Rootkits Archivált : 2019. január 6. a Wayback Machine -nál // Alexander Tereshkin, Rafal Wojtczuk ; BH 2009.07.29

Linkek