Az SMM memória támadása Intel CPU gyorsítótár-mérgezésen keresztül

 ( trey | 2009. március 22., vasárnap - 17:18 )

Az Invisible Things Lab (ITL) alapítója és vezérigazgatója, Joanna Rutkowska akkor került először a mainstream média szalagcímeibe, amikor bejelentette a (vitatott és soha sem bizonyított) "Blue Pill" névre hallgató, állítólagosan detektálhatatlan rootkit-jét és bemutatta azt a 2006-os Las Vegas-i Black Hat konferencián. A hölgy és csapata a héten ismét egy biztonsággal összefüggő felfedezést jelentette be.

Joanna Rutkowska
Joanna Rutkowska, a Invisible Things Lab alapítója és vezérigazgatója

"Ahogy azt ígértük, a dokumentumot és az elmélet helyességét igazoló (proof-of-concept) kódot kitettük az ITL weboldalra itt.

Ebben a dokumentumban leírjuk a CPU gyorsítótár-mérgezés (cache poisoning) egy gyakorlati kihasználási módját annak érdekében, hogy (az egyébként védett) SMRAM memóriából olvashassunk vagy abba írhassunk. Két működő exploitot készítettünk: egyet a SMRAM tartalmának dump-olására, egy másikat pedig az SMRAM-ban való tetszőleges kódfuttatásra. Ez a harmadik, Intel-alapú rendszereket érintő támadási mód, amelyet a csapatom az SMM memória ellen talált az elmúlt 10 hónapban.

[...]

Az SMM ellen indított támadások lehetséges folyományai lehetnek SMM rootkit-ek, hypervisor kompromittálás vagy operációs rendszer kernel védelmi mechanizmus megkerülése."

A bejelentés itt olvasható.

Az Ars Technica szemügyre vette az ITL felfedezését és közérthető módon leírta a problémát:

"Az exploit (PDF), amelyet Rutkowska tegnap bemutatott a System Management Mode-ot (SMM) érinti; a biztonsági csapat leírása szerint az SMM megegyezik a "Ring -2" szinttel (a példában: Ring 3 = alkalmazás szint, Ring 2 = eszközmeghajtó-program szint, Ring 1 = eszközmeghajtó-program szint, Ring 0 = kernel szint, Ring -1 = Intel Vanderpool virtualizáció szint, Ring -2 = SMM szint - a szerk.). Az ilyen mélységben működő kód gyakorlatilag bármit megtehet, miközben ez már egy olyan alacsony szinten való működés, amely már nem detektálható ésszerűen OS-szintű kereséssel."

Az Intel jelezte, hogy együttműködnek a biztonsági probléma megoldásában a szakemberekkel, minden bejelentést - így ezt is - komolyan vesznek és ahogy tudják, jelenleg nincs ismert, e biztonsági sebezhetőséget kihasználó exploit szabadon.

Az Ars Technica cikke - amelynek a címe "Intel CPU-level exploit could be tempest in a teapot" - felteszi a kérdést, hogy vajon az Intel-nek komolyan kell-e vennie ezt a problémát (azaz, valós fenyegetést hordoz-e) vagy csak egy olyan technikai érdekességről van szó, amely pusztán elméleti szinten kelthet érdeklődést.

Az Ars szerint nem nagyon kell pánikolni, mert az igazság az, hogy a sebezhetőség kihasználásához a támadónak sok időre van szüksége, pontosan és mélységében kell ismernie a megtámadott konfigurációt. Viszont a cikk hangsúlyozza, hogy fontos, hogy az Intel komolyan vegye a problémát - ahogy azt látszólag teszi is.

A teljes cikk elolvasható itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Na most megvallom őszintén, ebből tanultam valami újat. Illetve pontosabban, amikor még csak a slashdoton volt kinn a cikk, akkor kiváncsivá tett, hogy mi is ez az SMRAM, meg SMM szint és utánaolvastam. Csak én voltam ennyire tudatlan, hogy ez idáig elkerülte a figyelmemet, vagy tényleg ennyire nem közismert, hogy ilyen is van?
---
Linux is bad juju.

Elég régóta közismert, csak Joanna és a haverok most úgy adják elő, mintha ők találták volna fel...

Ezen kívül kicsit idegesítő az is, hogy ezekre most felhívják a figyelmet, mert lassan bezárják az összes kiskaput ahhoz, hogy a Trusted Computing által elképzelt DRM védelmet majd hardware hack nélkül törni lehessen.

Most hogy jobban utánanéztem a cuccnak... hát ez az egész SMM egy elég gányul kitalált dolognak néz ki, ami szerintem jobb, ha nem is létezne. QNX-es körökben pl eléggé rinyálnak miatta, mert képes elég csúnyán elrontani a real-time válaszidőket. Ha nagyon ráérnék (persze most is egészen mással kéne foglalkoznom :) ), akkor az exploittal belekukkantanék, hogy pontosan miket is lehet találni ebben a memóriaterületben.

Egyébként én úgy látom, hogy ennek kicsit nagyobb a füstje, mint a lángja. Javíts ki, ha tévedek, de szerintem ez semmivel sem teszi kiszolgáltatottabbá a rendszereket, mint idáig voltak:
1. Az exploit végrehajtásában van olyan rész, amihez ring0 kódfuttatás kell (=sikeresen kivitelezett kernel exploit)
2. Ha sikerült belenyúlni az SMRAM területre, akkor is csak a következő restartig marad kompromittált állapotban
3. Ahhoz, hogy restart után is megmaradjon (még az OS betöltődés előtt), a BIOS megfelelő részét is meg kell patchelni a flashben (ez nem olyan egyszerű, elég modellspecifikus feladat, bár tény, hogy kellő efforttal kivitelezhető)
4. BIOS átflasheléshez amúgy nem is kell az SMRAM exploit, az megy simán Ring0-ból is. QED.

Én csak két potenciális alkalmazást látok ennek egy malware-ben:
1. Az OS fertőzött, de betöltődés után a malware elbújik az SMRAM-ban és az OS-ben eltakarítja a nyomait, így normál rootkit vadászó programok nem találják meg (feltéve, hogy nem néznek be ők is az SMRAM-ba a most ismertetett módon, ha a malware meg tudta csinálni, akkor a malware kereső is meg tudja)
2. Esetleg (bár ezt nem tudom biztosan kijelenteni vagy cáfolni) lehetséges egy guest virtuális gépben futó kernel exploitálásával a host kernele alá kerülni. Sima szoftveres virtualizációnál ez biztosan nem működik, mert Ring1-ben futnak a guest kernelek. Hardveres virtualizációnál függ attól, hogy Ring -1-ből letiltható-e a Ring0-ból történő MTRR módosítás. Ha igen, akkor itt sem játszik. UPDATE: ja persze egy nyilvánvaló dolgot kihagytam, a Ring0 kódnak (guest kernel) tetszőleges fizikai memóriacímre is kell tudnia írni, ami megintcsak elég reménytelen a hypervisor exploitálása nélkül. Akkor ez a 2. eset úgy ahogy van nem is játszik.
---
Linux is bad juju.

Az egész műsor Joanna és csapatának részéről úgy indult, hogy bemutattak néhány technikát arra, hogy hogyan lehet kitörni Xen guestből a hostba (pygrub exploits), aztán hostból a hypervisorba (Xen bof hibák, DMA trükközés, Q35 chipset bug, etc.) és hogyan lehet berootkitezni emellett a rendszert úgy, hogy az "láthatatlan" maradjon (BluePillBoot, XenBP). Joanna idő közben ráadásul váltott oprendszert is és Vistáról OSX-re tért át, de nagyon fájlalta, hogy utóbbira (se Linuxra) nincs egy BitLocker-szintű FDE megoldás. A feature ami hiányzott neki, az nem önmagában a meghajtó titkosítás volt, hanem annak megfejelése a TPM támogatással, méghozzá oly módon, ahogy a Vista csinálja: trusted boot, SRTM (Static Root of Trust Measurement) megvalósítással, azaz úgy, hogy ne lehessen könnyen megszerezni a titkosító kulcsot a TPM-ből. Ennek lényege röviden az, hogy a TPM chip csak akkor adja ki magából a titkosító kulcsot, hogyha a megfelelő értékekkel vannak feltöltve a regiszterei. Az SRTM megvalósításnál a boot folyamat közben ezek a regiszterek folyamatosan kerülnek feltöltésre úgy, hogy mindig egy hash-t képeznek a fontosabb memóriaterületekről (BIOS ROM, PCI ROM, stb.) és ezek lesznek hozzáadva a regiszterekhez, így ha a titkosító kulcs eltárolása "tiszta" környezetben történt, akkor ilyen módon (majdnem ;) garantálható, hogy nincs a kernel vagy a boot loader módosítva úgy, hogy a titkosító kulcsot meglehessen szerezni, amikor az kiolvasásra kerül a TPM chipből. Ennek a megvalósításnak azért persze vannak gyengeségei (többekközt az, hogy nehezen garantálható, hogy minden fontos memóriaterületről készül hash, valamint nem túl rugalmas megoldás, mert sokmindentől változhatnak ezek a területek) és ennek kiküszöbölésére jött létre az Intel TXT (Trusted Execution Technology) támogatás a Q3x chipsetekben és a DRTM (Dynamic Root of Trust Measurement) megoldás. Ennek köszönhetően aztán a Xen kapott is egy trusted boot (tboot) képességet, hogy garantálni lehessen, hogy tiszta környezetben és a valódi hypervisor töltődjön be. Amiről viszont megfeledkeztek az Intelnél az az SMM volt, amelyben ellehetett továbbra is rejteni olyan kódot, amely aztán menet közben a tboot után módosította a Xen hypervisort, miután megtörtént az ellenőrzés, így meglehet kerülni a TXT védelmét. Ez persze nem annyira triviális, mert a 2006-os Loïc Duflot műsora után az Intel nyomására a BIOS gyártók lelockolták az SMM-et, hogy ne lehessen módosítani a BIOS POST után. A Q35 memory remapping bugnak köszönhetően azonban újra volt rá lehetőség, hogy átlehessen írni, illetve jópár SMM bugot is találtak, amelyek erre szintén lehetőséget adtak. Az Intel erre kitalálta az STM-et (SMM Transfer Monitor), amely segít az ilyen jellegű TXT támadások kivédésére és patchelte az eddig talált SMM hibákat is. Ezeknek a hatására találták most ezt a CPU cache poisoning bugot, hogy ismét saját kódot tudjanak futtatni az SMM szintjén.

Nagyjából ennyi. Nem biztos, hogy minden pontosan így van ahogy leírtam, mert csak futólag követtem az eseményeket. Az biztos, hogy ez abszolút nem újkeletű dolog, már a '90-es években is - miután megjelent az SMM - sokan foglalkoztak vele (egy MS-től kivált programozó még oprendszert is írt, amely SMM-ben fut), csak 2006-ban Loïc, meg most Joanna újra előhúzta a kalapból a dolgot és kissé úgy mutatják be, mintha ők találták volna meg...

troll :)

--
.

Látom nagyon zavar a szakmai diskurzus... :)
Szerintem vezessük be, hogy aki gonosz módon ontopic hozzászólásokkal akarja megzavarni a bikeshed threadeket, az jelezze külön, hogy <on> és aztán </on> tagekkel, hogy akit nem érdekel az ontopic discussion, az könnyen át tudja ugorni. Jó? :)
---
Linux is bad juju.

trey nem orulne! :)
--
.

O.o

[/me látta csubakkát]


No rainbow, no sugar

Köszi az összefoglalót, érdekes volt, de most vedd föl a ghettalife-pólódat! ;)))

--
"- The question is: what is a mahna-mahna?
- The question is: who cares?"

elvakult windows funboyoknak nem telik olyanra... ;)

nem értem az összefüggést. nem úgy volt, hogy a prolik linukszot használnak? :S

Nem, mert az elvakult windows funboyokat kizsákmányolja az m"$", míg a linux hackerek búsás fizetést kapnak csak a support után.

Thx. Nem akarsz egy review cikket írni?

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem értek én annyira azért hozzá, csak régebben foglalkoztam kicsit a témával és most futólag követtem az eseményeket. PaXTeam jobban vágja, ő 10+ éve írogatott egy debuggert is SMM-ben. Írt róla egy kis összefoglalót már 2 éve itt és itt.

[off]
vezérigazgató

Szívesen végeznék rajta pentestet két rétegben felhelyezett LaTeX határvédelmi eszközzel, közötte "Steve the Strong(téem)" IDS-sel, nehogy betámadjon a John the tripper
[/off]
[szerk version="1" optional="gyk."]
Ha szakad, jelez (az erőspista - ezért Intrusion detection szisztem)
[/szerk]
ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

az utsó nem ő.

Hat vegulis blokkolnam, na!
Szep, okos geek no... Ilyen nem is letezik! Szerintem fotosopp! :D
--
Bárki aki aritmetikai módszerekkel akar előállítani egy véletlen számot, az a bűn állapotában leledzik

LOL
+1

Egy ilyen nő mellett mondjuk nem tudom milyen biztonsági intézkedések kellenek...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

koton
hüvelykúp
pesszárium

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

es az meg csak a feje volt :)

pontosítanék: ez még csak a bal szemgödre volt ;Đ

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

Jó, de az megvan gondolom, hogy ezeket (kúp, koton, pesszárium) nem magadnak kell felnyomkodni...

--
trey @ gépház

koszi szepen :) akkor ezert volt olyan furcsa erzesem :P

asztán dikk honnét t'od, hogy nem vok leszbi? Vagy hogy a gáré nem nyeles?

És különben is, miért ne csinálhatnék skótdudát a síkosított spermaölősből - hogy annak zajával védekezzek, natürlich... :ĐĐĐ

És ha tudnád, milyen jó a két orrlik között utaztatni a hüvelykúpot - persze csak miután pesszáriumba csomagolva megjárta a traktusaimat - emésztési iránnyal ellentétesen :ĐĐĐ

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne