Novinky

Mravný úpadok architektúry

Prinajmenšom od roku 1982, keď svetlo sveta uzrel malý zázrak známy ako "Intel 80286", sa začala dodnes trvajúca epocha, v ktorej každé zlepšenie a rozšírenie možností našich (ne)verných (ne)osobných počítačov musí byť vtesnané do stále užšieho priestoru vymedzeného starobylou technológiou. Hovorím, samozrejme, o obávanej "spätnej kompatibilite", ktorú síce azda všetci chápeme z pohľadu všade vedúceho marketingu, prostej pohodlnosti, či niekedy dokonca nevyhnutnosti, ale aj napriek tomu v nás (ako v ľuďoch do veci trošku vidiacich i z tej technickej stránky) často vyvoláva nadbytok neblahých emócii. Je samozrejmé že technický pokrok si vyžiadal radikálne zmeny. A je rovnako samozrejmé že spomínané faktory si vyžiadali práve tú povestnú "spätnú kompatibilitu", teda aby zmeny boli všetko možné, len nie radikálne. Inu, rozpor chceného a nevyhnutného vyžadoval riešenie. A veruže aj vyriešený bol. Pýtate sa že ako? Nuž, tak ako bolo jedine možno... škaredo. Veľmi škaredo.

Vývojári nových technológii ich chudáci museli navrhnúť tak, nech je "vlk sýty i ovca celá". Presnejší opis situácie vlka (veď načo mu krivdiť) skôr je, že neumiera od hladu. A čo ovečky? Stádo našich ovečiek je rado že má takého dobrého vlka, nebúri sa, veď ten vĺčik zas až toľko nežerie... a veď čože by sme ho, však tu odjakživa s nami žije, je pohodlnejšie nechať ho tak. A tak i tie novoty sú len natoľko nové, nakoľko byť musia, nie nakoľko by byť mohli. Takto to skutočne vyzerá azda v každej oblasti IT so spätnou kompatibilitou vs. vylepšeniami... v dobe, keď Windows pri každom štarte musí vyvolať démona emulujúceho bugy starších verzii, aby zle napísaný software naďalej fungoval. Exorcistov nieto, a keď sa aj nejaký zblúdenec ohlási, prvý končí na hranici.

Potom nečudo, že za takýchto okolností sa o niektoré tieto polovičaté "novoty" sotvakto zaujímal. HW dizajnéri ich navrhli tak, že nevyhnutné minimum splnia, zdokumentovali natoľko, že mohli byť implementované, a tam to celé skončilo. Nebolo toho kto by verejne skúmal kvalitu implementácie aspoň za hranicu "ide to". Zvyčajne to bolo tak, že teista ďakoval Bohu, deista Prozreteľnosti a materialista Determinizmu, že sa v tom nemusia vŕtať.

Lenže vieme, že takéto neprebádané technológie vytvárajú dokonalé podmienky aby boli zneužité. Robené sú špinavo, len "nech to ide", nikto o nich nepíše, chyby zostávajú neodhalené. Čo viac môže lawful evil hacker chcieť? Jednou takouto významnou kategóriou, s ktorou sa v bezpečnostnej komunite iba prednedávnom roztrhlo vrece, sú netradičné módy procesora. Poskytovali obrovské možnosti, často bez toho aby sa kvôli tomuto ocitli v príslušnej pozornosti. Keďže sa dnes o tejto téme konečne hovorí, bohužiaľ i mnoho realite vzdialeného balastu, myslím že by bolo vhodné oboznámiť čitateľov aspoň tak všeobecnejšie, že čo sú vlastne tieto nové (a aj nie veľmi nové) módy zač, čo umožňujú, aké predstavujú riziko, a proste prispieť aj troškou vlastného balastu.

Toľko nemiestne literárny úvod, prejdime k veci.

SMM

Už v procesore Intel 80386 (vulgárne "triosemšestka"), mimochodom staršom než autor tohoto článku, sa nachádzal málo známy System Management Mód, zvyčajne titulovaný iniciálmi SMM. Je nepochopiteľné, že len skutočne nedávno sa začalo hovoriť o možnostiach jeho zneužitia. U tých paranoidnejších (o ktorých medzi čitateľmi isto nebude núdza) to môže oprávnene vyvolávať aj určité pochybnosti.

O čo ide? 8086 bol ešte stroj kde "každý mohol všetko", žiadna ochrana ani nič podobné. Potom prišla "186ka" o ktorej síce kdekto čítal, že vraj existovala, ale nikto ju nikdy nevidel. Ďalší prírastok do rodiny, 80286, už priniesla zásadné zmeny. Nás z nich zaujíma hlavne možnosť bežať v rôzne privilegovaných módoch, možnosť zamedziť userom usierať si z jadra, teda tzv. "chránený mód". Tu už si nemohol ktorýkoľvek program zmyslieť že prevezme úplnú kontrolu nad strojom (teda aspoň teoreticky nie, v praxi zvyčajne ešte mohol). Ako som písal už v tom nepodarenom úvode, nebolo to vôbec elegantné, ale fungovalo to. V nastúpenom trende verne pokračoval aj ďalší potomok, procesor 80386. Ten priniesol skutočne zásadné zmeny v podobe vylepšeného chráneného módu, plne 32-bitového procesora, stránkovania pamäte, a tak ďalej. Z množstva fičúr sa ale lepšia polovica vôbec neuplatnila. Úrovne ochrany neboli dve ako by sa dnes zdalo logické, ale štyri, pričom tie stredné dve (ktoré mali slúžiť pre drivery a "privilegované programy") sa nikdy nevyužili, s výnimkou pár exotických vecí. Pribudlo elegantné hardwarové prepínanie procesov, majúce jedinú nevýhodu: bolo pomalšie než ručne spravené softwarové. Dodnes ešte musíme napĺňať registre pre toto hardwarové prepínanie procesov aj na architektúre AMD64 (kapitola sama o sebe) napriek tomu, že tam ho už ani len teoreticky nie je možné použiť. Nesmieme tiež opomenúť že stále bolo treba ďalšie režimy: pre spätnú kompatibilitu s 16-bitovým chráneným módom na 286, a s nechráneným "real" módom 8086, ktorý tu samozrejme už ale musel byť chránený, ale bez toho aby o tom vedel. To len tak na dokreslenie celkovej situácie. Keby som mal menovať všetky dobre mienené špeciality, ktoré nenašli využitie, asi by som článok zdvojnásobil. Bola to jednoducho nádhera.

Čitateľa asi neprekvapí, že za danej výrazne skomplikovanej situácie už nepostačovali niektoré technológie, ktoré ešte na 8086 stačili. Na 8086 sme totiž ešte dôverovali všetkému čo na stroji beží, že sa to nebude biť s ničím iným (bezpečnosť asi vtedy ešte ani nebola otázkou). Na 80386 už prišlo do módy neumožniť mu to. A to vyžaduje technologicky v tom zabrániť.

Konkrétne ide o potreby BIOSu. On BIOS vôbec nie je taká zázračná vecička za akú býva niekedy pokladaný. Je to obyčajný kus kódu, ktorý je špecifický snáď len tým že jeho autori detailne poznajú hardware počítača (resp. dosky, chipsetu) a je na nich správne ho pripraviť a nastaviť do formy v ktorej s ním už dokáže pracovať aj operačný systém. Ak by sme my mali tieto údaje (a veľa z nich je predsa len prístupných), spokojne by sme mohli tento kód nahradiť našim vlastným. Lenže tým že sa inicializuje HW a riadenie odovzdá operačnému systému to pre BIOS zďaleka nekončí, ako by sa mohlo laikovi javiť. Je síce pravda, že (známejšia) časť jeho agendy postupne prechádzala na operačné systémy (typicky grafika, užívateľský vstup, prístupy k disku, ...), ale veľa mu zostalo (grafika keď nemáme ovládač, power management, emulácia moderného HW pre staré štandardy, monitoring HW...). Na toto BIOS potrebuje schopnosť kedykoľvek prerušiť beh programu alebo aj kernelu a vykonať nejaký svoj kód. Pri 8086 na to slúžil systém prerušení, ktorý sa (ako všetko) zachoval v značne skomplikovanej forme aj v procesoroch 80386. Veľká časť agendy BIOSu na nich aj zostala. Lenže nemohlo všetko. Niektoré veci potrebovali nutne bežať i vtedy, keď sa operačný systém práve neuráčil správne nastaviť a povoliť prerušenia. Čo iné mohlo byť za spomenutej situácie samozrejmejším riešením, než spraviť ďalší zvláštny mód procesora?

Týmto módom je System Management Mód. Pre tento mód je vyhradený kus RAMky, nazývaný SMRAM, kam BIOS veľmi skoro pri štarte počítača nahrá svoj kód. Akonáhle sa stane nejaká udalosť, ktorá vyžaduje takéto zvláštne spracovanie, vyvolá sa tzv. System Management Interrupt (SMI). Toto spôsobí že procesor preruší svoju momentálnu činnosť, uloží svoj stav do SMRAM, prepne sa do SMM režimu, vykoná kód uložený v SMRAM, a nakoniec obnoví uložený stav a pokračuje v pôvodnej činnosti. Od bežných prerušení sa ale odlišuje tým, že toto všetko sa deje úplne neviditeľne pre operačný systém, ktorý ani netuší že sa niečo stalo. Táto priehľadnosť je príkladom toho o čom som písal v úvode. Operačnému systému to plne vyhovuje že z jeho pohľadu sa nič nemení, o nič sa nemusí starať, a BIOS má možnosť spraviť si čo potrebuje bez toho že by musel brať ohľad na operačný systém. Pochopiteľne že samotný SMM kód má úplnú kontrolu nad strojom.

To je všetko fajn, a aj keď je to trochu nesystematický ojeb, účel to plní pekne. Potiaľ v poriadku. Ale keď si uvedomíme, že sa jedná o režim pre systém úplne neviditeľný, s totálnymi právami robiť si s mašinou čo sa mu zachce, o ktorom sa vie veľmi málo a je dosť náročné vôbec zistiť čo ten SMM kód "na mojej mašine" robí, tak paranoikom opadne eufória a naopak zlí škaredí nadopovaní hackeri začnú nekontrolovateľne vylučovať telesné tekutiny.

Aby sa nedal tento mód tak ľahko zneužívať, po tom ako BIOS zapíše svoj bordel do SMRAM, hardvér mu umožňuje zakázať procesoru akýkoľvek ďalší prístup do SMRAM (okrem SMM samozrejme). To má zabezpečiť absolútnu následnú izoláciu SMM kódu od bežného kódu, ochrániť ho pred akoukoľvek ďalšou manipuláciou. Lenže to môže byť aj dvojsečná zbraň. Hlavne v situácii (reálnej), keď sa žiadny z tvorcov firmwaru neunúval toto zamknutie aj skutočne vykonať. Veď nakoniec, načo. Tajné to síce nebolo, ale nikto sa im v tom nevŕtal. A ak sa niekto vŕtal, tak s tým na verejnosť nešiel.

Verejne hovoriť sa o možnosti zneužitia SMM začalo až v roku 2006. To spôsobilo že výrobcovia firmwaru začali konečne SMRAM zamykať. Ale to stále problém neriešilo. Nebudem tu zachádzať do detailov, ale kto videl ako vyzerá programovanie chipsetu, ten vie že nastaviť všetky možné registre tak, aby prístup do určitého regiónu RAMky nebol možný, je dosť kumšt. Nebolo teda prekvapením, keď sa čoskoro objavilo niekoľko trikov ktoré umožnili SMRAM prepisovať aj napriek tomu, že bola zamknutá. Alebo stačilo nájsť chybu v málo preskúmanom SMM kóde, ktorý SMRAMku (teda sám seba) samozrejme môže prepisovať a pekne po starom ju exploitnúť. Objavené chyby boli síce na nových doskách opravené, ale potom niekto prišiel na to, že SMRAM ani prepisovať netreba. Stačí podvrhnúť vlastný kód do CPU L1 cache na adresu, kde normálne býva SMRAM. Potom pri SMI sa CPU poteší že pamäť z ktorej ide SMM kód vykonávať už má v cache, nemusí ju zdĺhavo čítať z fyzickej RAMky. Že v tej ozajstnej SMRAM je niečo iné ako v cache, to procesor netuší. A skutočný obsah SMRAM vo fyzickej RAMke zostáva zamknutý, neprístupný, nikto sa ju nesnaží prepisovať. Idyla.

Nakoniec situácia vyzerá tak, že celý tento 25 rokov starý systém je od základu zle navrhnutý, a napriek viacerým pokusom ho nie je možné poriadne zaplátať. Že sme si to všimli až teraz, zostáva témou na zamyslenie. Ja časť viny pripisujem tej žumpe, ktorú musí každý zvedavec preplávať aby vôbec pochopil tento mechanizmus a mohol ho začať skúmať z bezpečnostného hľadiska. A ako to Intel rieši? Čuduj sa svete, navrhuje *ďalšiu* paralelnú technológiu (SMM Transfer Monitor, STM), ktorá sa bude starať o bezpečnosť SMM kódu. Podľa niektorých správ by sa malo jednať o spúšťanie SMM kódu v nejakom virtualizovanom prostredí. Presne netuším, zodpovedné špecifikácie ešte neboli vydané a patent sa mi čítať nechce (aj tak to budú len vzletne opísané všeobecnosti úrovne dvojkliku myšou, natoľko obfuskované aby sa úradníkom na patentovom úrade zdali ako nejaký nový výmysel). Každopádne ja osobne by som nedal ľavé vajco do ohňa za to, že nedopadne podobne ako všetky predchádzajúce "riešenia".

Hardwarová virtualizácia

Ďalšou zaujímavou technológiou s podobnými schopnosťami je hardwarová virtualizácia. O čo ide?

V IT sa stále viac rozmáhalo použitie "virtuálnych strojov", teda programov ako VMWare, Xen, atď, ktoré umožňujú na jednom počítači spustiť viacero "virtuálnych" počítačov. Vysvetľovať to tu dúfam nemusím, prax asi väčšina čitateľov pozná omnoho lepšie než ja. Zo začiatku to bolo samozrejme ešte riešené plne softwarovo. Výkon týchto programov nebol vždy uspokojivý, a vytvorenie takéhoto programu na 80x86 bolo značne netriviálne (keby som nepísal seriózny článok, tak poviem, že je s tým strašná jebačka), takže sa zrodila myšlienka spraviť podporu pre túto virtualizáciu priamo v hardwari (najmä v procesore). Táto by mala byť jednak výrazne zjednodošiť vývoj podobného softwaru, a tiež zvýšiť jeho výkon.

Ako prvý na poli x86 takúto technológiu predstavil AMD, pod názvom "Secure Virtual Machine" ("SVM", taktiež "AMD-V", "Pacifica"). Intel čoskoro nasledoval s dosť podobnou, ale nekompatibilnou technológiou, nazvanou "Virtual Machine Extensions" ("VMX", tiež "VT-x", "Vanderpool"). Treba však podotknúť že prvé verzie od Intelu boli čo do schopností o poznanie chudobnejšie než tie od AMD a len postupne boli doplnené niektoré dosť podstatné prvky (technológie EPT, VT-x2, ...). Ďalšou zaujímavosťou je že pôvodne bola hardwarová virtualizácia s využitím týchto technológii často pomalšia než dobre spravená softwarová virtualizácia, ale teória je, že HW implementácia sa bude postupne zrýchľovať.

Toľko pohľad "zhora", ktorý nás až tak nezaujíma. Teraz skúsim stručne popísať ako táto technológia pracuje "naozaj" na procesore. Akonáhle sa procesor rozhodne že chce virtualizovať, musí sa najprv prepnúť do zvláštneho módu, v ktorom bude "pánom veci" počas celého behu virtualizácie. Tento software budem ďalej nazývať v podľa Inteláckej hantýrky "Virtual Machine Monitor" (VMM). VMM si pre každý virtuálny stroj (VM) ktorý chce spravovať vytvorí štruktúru, v ktorej je popísaný úplný stav tohoto virtuálneho stroja (hodnoty všetkých registrov procesora, nastavenie právomocí VM, a podobne). Keď sa rozhodne, niektorý takýto VM spustí, a nechá ho bežať priamo na procesore. VM beží v režime len málo odlišnom od normálneho behu bez virtualizácie. Rozdiel je len v tom že pri behu je VM obmedzená v určitých veciach: môže pristupovať len k zdrojom (pamäti, HW zariadeniam) ktoré sú jej povolené, nemôže robiť niektoré činnosti ktoré by mohli zasiahnuť do VMM, a podobne. Akonáhle sa VM pokúsi spraviť niečo čo sa vymyká normálnemu behu, jeho beh sa preruší, a riadenie sa odovzdá naspäť do VMM. Ten zistí čo sa stalo a rozhodne sa čo spraví. Zvyčajne pre VM emuluje správanie očakávané pri bežnom behu mimo virtualizácie. Keď sa napríklad VM pokúsi pristúpiť do pamäte ktorá mu nepatrí, VMM mu emuluje správanie ako keby taká pamäť neexistovala. Keď sa VM pokúsi čítať zo svojho virtuálneho disku, riadenie dostane VMM, ten prečíta dáta z ozajstného fyzického disku a preloží ich do formátu v akom ich očakáva VM. A tak podobne.

VMM si okrem toho môže nadefinovať niektoré ďalšie udalosti pri ktorých sa beh VM preruší, a riadenie sa odovzdá jemu. Typickým príkladom je časovač. Ak VMM má pod sebou viacero VM, ktoré chce bežať pseudo-naraz, tak musí v pravidelných intervaloch beh VM prerušovať a odovzdať riadenie inej VM. Množina týchto udalostí pri ktorých VMM vie beh VM prerušiť je však vcelku obmedzená na tie, ktoré sú užitočné pri bežnej virtualizácii typu VMWare alebo XEN.

Táto technológia umožňuje spraviť taký VMM, ktorý bude zaberať minimum pamäte (zopár KB), a tiež spomalenie ním spôsobené (oproti behu bez virtualizácie) bude prakticky nepostrehnuteľné. Myslím že z tohoto opisu je jasné, že aj táto technológia sa dá veľmi pekne či škaredo zneužiť na malware. Malware (samozrejme, až keď už má roota) spraví zo seba VMM, a vytvorí VM ktorá bude identická s normálnym systémom predtým než bol napadnutý. Takpovediac, "zavrie" operačný systém do VM a on zostane "pánom" (VMM). Toto všetko ide urobiť bez nutnosti reštartu, alebo bez akýchkoľvek viditeľných príznakov. Malware tým pádom zostane mimo dosahu pôvodného operačného systému bežiaceho vo VM.

Skutočne je to pre malware veľmi lákavá predstava. Lenže, ako všetko, má to pár chytákov:

Za prvé, metóda je obmedzená len na počítače podporujúce virtualizáciu. Je síce pravda že podiel týchto sa neustále zväčšuje, ale stále sa ani zďaleka nejedná o pravidlo. Navyše, samotná virtualizácia musí byť v BIOSe povolená (zvyčajne býva by-default zakázaná). Toto je vec, ktorá sa síce dá obísť, lenže iba dosť pracne a výhody virtualizácie sa tým z časti strácajú.

Za druhé, malware najprv nejako musí "tradičným spôsobom" dostať stroj pod kontrolu, a až potom môže začať robiť spomenuté. Virtualizácia teda neznamená nejakú novú možnosť obísť bežné ochrany, tie treba stále prekonať. Virtualizácia tu len poskytuje omnoho lepšie podmienky následne sa skryť a zostať neodhalený. Treba ešte povedať že je pre malware vcelku náročne "zahľadiť po sebe stopy", ktoré nutne zanechal pred tým než sa dostal do pozície VMM.

Za tretie, virtualizačná technológia nie je stavaná pre takéto účely, mnoho funkcionality ktorú by malware potreboval jednoducho nemá a teda ju musí komplikovane nahrádzať (alebo to nedokáže vôbec).

Za štvrté, akonáhle je malware (ako VMM) "nad" operačným systémom (ktorý beží vo VM), nemôže už služby operačného systému využívať. To znamená že nemá žiadne ovládače, nemá prístup na disk, k sieti a podobne. Ako to po vysvetlení zhodnotil jeden známy: "je úplným pánom nad vecou, ktorý ale reálne nič nemôže spraviť". Prísne vzaté, malware ako VMM sa môže rozhodnúť využiť operačný systém vnútri ním ovládaného VM, tým sa ale (aspoň zčasti) dobrovoľne zbavuje výhod ktoré virtualizáciou získal. A tiež sú s tým spojené nejaké technické problémy, aj keď prekonateľné.

Druhou veľkou témou je ne/možnosť detekcie takéhoto malwaru. Keď sa začalo hovoriť o možnostiach využitia virtualizácie pre malware, väčšina médii v duchu sebe vlastnej zodpovednosti rozširovala riadne nadsadené tvrdenie o "100% nedetekovateľnosti" takéhoto malwaru. Toto bolo následne presunuté do roviny "100% nedetekovateľné bežnými metódami", a debata sa potom presunula k ne/možnosti automatizovane odlíšiť beh pod "normálnym" hypervízorom (napr. Xen) od behu pod malwarom. Vcelku možno povedať že zistiť či systém beží ako VM alebo nie sa určite dá, aj keď nie práve triviálne (ale zase ani nijako extra zložito). Je to spôsobené tým, že virtualizácia je stavaná na to, aby VM bežala čo najefektívnejšie, nie aby bola emulácia dokonalá a fakt, že beží virtualizovane, utajený.

Virtualizácia na CPU ale nie je všetko. Aj keď sú veci čo bežia na CPU plne pod kontrolou VMM, ešte stále je to, čo sa vykoná, závislé od pamäte. A do pamäte nezapisuje len CPU. Predstavme si, že napríklad pri čítaní z disku do pamäte by musel každý byte ísť cez CPU - asi by to nebolo bohviečo (kto neverí môže to skúsiť, pokiaľ viem ovládače dodnes umožnujú takýto režim použiť - volá sa to "PIO mód"). Preto Pé Cé architekti stvorili technológiu, ktorú pokrstili Direct Memory Access, DMA. Táto umožnuje rôznym zariadeniam zapisovať priamo do pamäte, bez toho že by sa o to procesor staral.

Týmto spôsobom je možné obíjsť VMM. Ak sa niektoré zariadenie na doske rozhodne zapísať do pamäte cez DMA, môže to urobiť bez toho, že by sa o tom VMM dozvedel. A čo keď sa rozhodne prepísať kód VMM v pamäti? Prúser. Toto je jeden zo spôsobov ako sa može VM "prebiť" von z VMM - ak vie kde v pamäti sa VMM nachádza, môže ho cez DMA prepísať. VMM dokáže zabrániť VM takto zneužiť DMA, ale to už spadá do kategórie tej funkcionality, ktorá sa implementuje náročnejšie. A navyše, ktorékoľvek zariadenie napojené na DMA sa môže rozhodnúť toto spraviť aj samo. Ibaže tomuto zabrániť treba. Nielen pri malwari, ale aj pri bežnej virtualizácii. Nemôžeme predsa dovoliť ktorejkoľvek VM zhodiť celý stroj.

Ako to riešiť? Tušíte správne: Ďalšia technológia. Stačí posadiť ďalšie železo medzi pamäť, DMA, a ostatné zariadenia, ktoré sa bude starať o to aby nikto nepristupoval kam nemá. Nazýva sa to "Input/Output Memory Management Unit" (IOMMU), Intel to u seba zahŕňa do technológie "Virtualization Technology for Directed I/O" (VT-d). Toto opäť zväčšuje chaos, robí celý ten komplex menej zrozumiteľným, a rozširuje priestor pre čiernoklobúčnych hackerov na ich diabolské plány ovládnutia našich počítačov.

Technológie súvisiace s Trusted Computing

Veľa sa kričalo o tom, ako IT buržoázia pomocou rôznych vlád (ktoré sú objektívne iba nástrojom na presadzovanie jej triednych záujmov maskovaným za formálnu parlamentnú, čiže protiľudovú demokraciu) túži naplniť svoje imperialistické chúťky zavedením počítačov, ktoré "budú poslúchať ju a nie svojich vlastníkov". A nie že by na tom nebol kus pravdy, lenže je treba prihliadnuť aj na to, čo je skutočne možné. Druhá strana zase naopak tvrdí že im ide len o nesebecké uplatnenie odvekých ideálov slobody zabezpečením primeranej odmeny pre tvorcov intelektuálnych hodnôt, ktorá motivuje iniciatívu nevyhnutnú pre ďalší pokojný postupný evolučný rozvoj. A nie že by na tom tiež nebol kus pravdy, ale tu zase treba prihliadnuť na to, či toto je skutočne hlavným cieľom a či naozaj smerujú k tomu, čo deklarujú. Nebudem tu ďalej rozoberať túto "politickú" stránku, ale popíšem ako vyzerá to, čo sa zatiaľ v tomto smere vykonalo.

Najznámejšia "naozajstná" vec zo všetkého toho sci-fi publikovaného na túto tému je "Trusted Platform Module" (TPM) čip. Keď sa hovorilo že je to nejaky čip ktorý ovláda celý počítač, ku ktorému má plný prístup iba Microsoft alebo kto, tak je to v podstate kravina. TPM Je len taký malý čípok, čípičok, či ako sa to správne zdrobňuje, v ktorom je uložený nejaký ten tajný kľúč (ten si nastaví vlastník počítača a potom ho nikto iný nevie zmeniť) a ktorý vie hashovat + de/šifrovať dáta. TPM je pasívny čip, sám od seba nerobí nič, a keď nechceme vôbec ho nemusíme používať. Teda nie je to tak že na počítač s TPM nebudeme môcť nainštalovať linux, alebo podobne. Nové dosky TPM majú a ani o tom nevieme.

Ako teda môže Takáto Primitívna Mašinka slúžiť či už na navodenie "čipovej totality", resp. zabezpečiť dodržiavanie "digitálnych práv"? V skratke je princíp ten, že pomocou TPM robíme hash kódu, ktorý sa bude vykonávať a potom tento hash používame na šifrovanie a dešifrovanie dát. Veľmi dôležité je, že tento hash, uložený v TPM, nevieme nijako cielene nastaviť ani prečítať, jediná operácia, ktorú máme, je tzv. "rozšírenie", čo znamená že sa spraví hash z predchádzajucej hodnoty hashu plus ďalších dát. Inak tým hashom môžeme už len šifrovať a dešifrovať. Akonáhle sa nejako zmení kód, ktorý sa ide vykonávať, tak sa zmení aj jeho hash a tým pádom dáta zašifrované iným hashom už nevieme dešifrovať. A nevieme ani obnoviť hodnotu registra v ktorom je hash na tú pôvodnú. Navyše ani nevieme aká bola pôvodná hodnota, pretože do tohoto hashu vstupuje aj tajný kľúč uložený iba v TPM. Teda ani keď poznáme dáta ktoré sú hashované, nevieme hash zreplikovať a teda nepoznáme správny kľúč na dešifrovanie. Čo sme raz zašifrovali pomocou TPM, to dokážeme dešifrovať zase len pomocou TPM s tým istým tajným kľúčom, keď mu dáme zahashovať presne tie isté dáta v tom istom poradí.

Ako funguje to hashovanie v praxi, čo sú dáta ktoré sa hashujú? Využitie môže byť rôzne, pre lepšie pochopenie uvediem zjednodušený praktický scenár:

BIOS veľmi skoro pri spúšťaní urobí TPM hash celého BIOS kódu. S týmto hashom zatiaľ nerobí nič. Keď BIOS skončí so svojimi vecami a ide odovzdať riadenie boot loaderu operačného systému, rozšíri hash v TPM hashom boot loaderu, a až potom mu odovzdá riadenie. Boot loader zase rozšíru hashom operačného systému, operačný systém rozšíri hashom driverov, atď, atď. Výsledným hashom potom operačný systém zašifruje nejaké dáta. Ak sa znovu spustí nezmenený operačný systém, TPM po reboote hashuje tie isté dáta, a teda má rovnaký výsledný hash, ktorým dáta dešifruje. Ak však niekto nejaký kód zmení (patchnutý BIOS, MBR rootkit, zmenený kernel, atď.), tak hashované dáta budú iné, a výsledný hash už nebude sedieť - čo znamená že dáta už nedokážeme dešifrovať.

Celý tento proces sa volá "Static Root of Trust Measurement" (SRTM, "measurement" tu je len všeobecným výrazom pre hashovanie). V tomto zmysle TPM skutočne umožňuje niečo čo môžeme spokojne nazvať "Trusted Computing". Užívateľ si môže zašifrovať svoje... citlivé dáta, a keď sa niečo na jeho počítači zmení (napríklad NBÚ mu na žiadosť FBI nainštaluje sledovací rootkit), tak dáta sa stanú neprístupné.

Priamo teda tento systém neslúži na nejaké ovládnutie našich počítačov korporáciami, ani nám nemôže zabrániť používať naše počítače na čo chceme. Naopak, rozširuje naše možnosti detekovať zásah do počítača niekým iným. Čo ale dokáže "smerom" k DRM je "zapečatenie" dát tak že keď niečo zmeníme tak sa po ne nedostaneme, a taktiež umožnuje tretej strane overiť či sme konfiguráciu menili. Toto umožňuje vytvoriť DRM, a preto to ľudia typu Stallmana tak vehementne odmietajú. Vyzeralo by to asi tak že tajný klúč v TPM nám nastaví už dodávateľ počítača, a predinštaluje "trusted" systém (teda verí mu on, nie my). Potom rôzne tretie strany pomocou challenge-response schémy môžu pri komunikácii cez sieť overovať či je systém nezmenený. Poprípade sa operačný systém celkom odmietne nabootovať ak zistí že bol nejako menený. Človek by samozrejme stále mohol komplet starý systém zahodiť, vykašľať sa na celý TPM, a nainštalovať si svoj OS. Tomu by v úplnom extréme išlo zabrániť tak že by BIOS odmietol odovzdať riadenie boot loaderu ak by v ňom zistil zmenu, ale to pri bežných domácich počítačoch nevidím reálne (museli by to spraviť výrobcovia firmwaru, a otázka je či by potom od nich niekto také počítače kupoval).

Humorné na tom všetkom je, že z určitého pohľadu sa situácia veľkou okľukou za pribudnutia množstva nových technológii vrátila tam, kde bola na 8086ke keď veci ešte fungovali "primitívne jednoducho": teda že všetok software ktorý na mašine beží musí byť "trusted", že neurobí niečo čo nemá. Pribudlo len overovanie tohoto predpokladu. Navyše aby toto overovanie malo zmysel, overiť sa musí vlastne úplne všetok kód čo na stroji pobeží. Pri takomto obrovskom množstve kódu ktorý je overovaný, fakt že mu nejaký vendor (RIAA alebo kto) "verí" je úplne zanedbateľný. Milióny riadkov "trusted" kódu nevyhnutne obsahujú bugy, a na tých potom celá ochrana padá. Ako DRM systém je teda SRTM okrem riadnej orwellovskosti (čo je pri prehýčkanosti konzumentov dosť závažné) aj pramálo spoľahlivé. A samozrejme že sa našli aj chyby priamo v technólogii, napr. že TPM bolo možné resetnúť (teda aj TPM registre v ktorých je uložený hash) aj bez resetu počítača, a potom už nebol problém dať mu zahashovať kód aký by hashoval za normálneho štartu, len ho nevykonať. Alebo šlo použiť mechanizmus ktorý bežne slúži na flashovanie BIOSu, pri ktorom sa počítač (vrátane TPM) resetne, lenže sa nezačne vykonávať BIOS kód, ale kód uložený na inom mieste v pamäti, ktorý do hashu nevstupuje. Alebo jednoducho patchnúť kód BIOSu ktorý úplne na začiatku robí prvý TPM hash (v predvedenom útoku to vyžadovalo zmenu až jedného bytu). Alebo pri overovaní cez net klasicky man-in-the-middle nechať overenie vykonať na stroji s ktorým nebolo haprované, ale zvyšok komunikácie viesť z iného stroja. A to ešte nespomínam tú nie príliš teoreticky doriešenú srandu, keď užívateľ potrebuje legitímne niečo z hashovaného kódu zmeniť (BIOS update, update OS, nová grafická karta...).

SRTM teda (jemne povedané) zlyhalo, aspoň na bežné používanie (na špecializované použitie stále môže byť užitočné). Dizajnéri si asi povedali "Ná, totok nevyšlo, čo fčul"? A samozrejme, riešenie sa rýchlo objavilo. Každému kto článok prečítal až potiaľto musí byť jasné aké: ĎALŠÍ, ešte bezpečnejší, ešte izolovanejší mód, do ktorého "tentokrát už naozaj" nepôjde zasiahnuť zvonku. U Intelu sa nový mód volá "Safer Mode Extensions" (SMX) vrámci technológie "Trusted Execution Technology" (TXT), u AMD neviem že by ten mód mal nejaký zvláštny názov, používa sa názov príslušnej inštrukcie SKINIT, a je to vrámci tej istej technológie ako virtualizácia, "Secure Virtual Machine" (SVM).

Tento umožňuje, stručne povedané, v ľubovolnom momente v behu untrusted systému pomocou špeciálnej inštrukcie a kódu previesť ho to trusted stavu. Ako argument inštrukcie dáme rozsah pamäte v ktorom sa nachádza tzv. AC (authentificated code) modul. Okrem samotného kódu AC modulu nič z predchádzajúceho stavu počítača do tohoto módu nevstupuje, je to takmer ako keby sme počítač resetli. V tomto móde by sme mali byť úplne izolovaní a mať istotu že nikto a nič až do ukončenia AC modulu nebude môcť nejako ovplyvniť jeho beh. Spomínaná inštrukcia preto vypne ostatné procesory, kód umiestni do inštrukčnej cache CPU, zakáže akékoľvek prerušenia, atď. Okrem toho ešte predtým než AC modul spustí, zahashuje ho do TPM registra. AC modul by mal hash rozšíriť všetkým podstatným čo z predchádzajúceho stavu počítača "prežije" do nového stavu a môže byť vykonané alebo nejako nejako ovplyvniť budúci beh počítača (napríklad SMM kód, BIOSove tabuľky ktorými odovzdáva informácie operačnému systému, atď). Až keď toto všetko spraví, odovzdá riadenie Boot Loaderu a ďalej. Všetko čo prežilo zo stavu pred spustením AC modulu je v TPM hashi. Veľmi stručne sa dá povedať že prevedieme počítač z "untrusted" do "trusted" stavu bez toho že by sme ho museli resetnúť (i keď to má k tomu dosť blízko). Ďalej sa už pokračuje rovnako ako pri klasickom SRTM. Celý tento proces sa nazýva Dynamic Root of Trust Measurement (DRTM).

Účelom tohoto je že nemusíme pomocou TPM overovať úplne všetko od začiatku behu počítača, ale stačí od momentu keď spustíme AC modul. Tento úkon sa zvyčajne robí po tom ako BIOS dokončí svoj bordel a predtým než odovzdá riadenie boot loaderu. Tým nám odpadajú útoky napadnutím BIOSu (či už priamym patchovaním, spomenutým trikom s update mechanizmom, útok cez Option ROM, a iné). Aj ak bol BIOS napadnutý, stačí mať dobre napísaný AC modul, ktorý nič z predchádzajúceho stavu "neprepusti" (a to čo prepustí zahashuje, takže ak sa to zmení na to prídeme).

Práve kvôli tomuto musí AC modul bežať v takto dokonale izolovanom režime. Útočník ktorý napadol počítač ešte pred spúšťaním AC modulu by samozrejme chcel aby niečo z jeho kódu prežilo natiahnutie AC modulu. Lenže AC modul je napísaný tak, že všetko odstaví, a to čo necháva overuje hashom (čiže ak to útočník zmenil, hash nebude sedieť). Útočník síce môže zmeniť kód AC modulu aby niečo netestoval, ale kód AC modulu je tiež hashovaný. Čo teraz?

Keby AC modul nebežal v tak izolovanom móde, útočník by napríklad mohol na viacprocesorovom počítači nechať na jednom procesore vykonať inštrukciu ktorá spúšťa AC modul, a potom ako sa tento zahashuje a jeho hash sa uloží do TPM, ale ešte predtým ako sa začne vykonávať, pomocou druhého procesoru prepísať jeho kód. Teda zahashovaný by bol pôvodný kód, ale vykonal by sa už ten nový. Samozrejme, existuje mnoho ďalších spôsobov okrem použitia iného procesoru, napríklad použiť DMA, vyvolať prerušenie, pustiť to pod virtualizáciou, atď. Presne takýmto srandičkám má tá totálna izolácia zabrániť.

Ďalším fígľom je že inštrukcia ktorá spúšťa AC modul resetne TPM registre (v ktorých sú uložené hashe) na trochu iné hodnoty než normálny reset, takže ju nedokážeme ani pomocou bežného TPM resetu emulovať.

Samozrejme ale, že aj takýto postup má svoje problémy. Jedným z nich je, že AC modul musí skutočne do hashu zahrnúť úplne všetko čo z predchádzajúceho "untrusted" stavu "prežije" do "trusted" stavu. A toho nie je málo. Napríklad už spomínaný SMM kód v ukážkovej implementácii DRTM od Intelu hashovaný nebol, vďaka čomu dokázala Janka Rutkovská v známej prezentácii ich DRTM obíjsť. Nie je takých vecí na ktoré "sa zabudlo" viacej? Ktovie. Napríklad teória hovorí, že vrámci DRTM po zbehnutí AC modulu by BIOS nemal byť vôbec volaný, ale to je nereálne (jeden príklad čo ma napadá je práca s NVRAM premennými na EFI systémoch, je to treba a ide to len cez volanie BIOSu).

No a samozrejme, od momentu ako sa AC modul ukončí už pokračujeme ďalej rovnako ako pri SRTM, s obrovským množstvom kódu ktorý nevyhnutne obsahuje obrovské množstvo chýb nech je "trusted" koľko chce. V podstate sme "attack vector" zmenšili len o ten BIOS.

Ešte spomeniem že TPM okrem toho čo som napísal vie ešte rôzny bordel navyše, napríklad ochraňovať hodnoty uložené v pamäti tak aby ich nebolo možno prečítať ani po resete, apod. Keďže sa ale ani sám sa v tejto oblasti poriadne neorientujem, nechávam túto tému otvorenú.

Na záver

Takže dúfam že som na príklade týchto troch technológii objasnil a doložil všetky tie invektívy z úvodu. Dnešná x86 architektúra je skutočne jeden strašný chaos zle zaplátaných záplat a hackov ktoré absolútne nesystematicky riešia jeden konkrétny problém a pritom zákonite vzniká niekoľko ďalších. Koho prekvapí že SMM sa dalo zneužiť na obídenie TXT alebo virtualizácie? Čo keď kód bežiaci v SMX móde z nejakého dôvodu chce byť zároveň byť virtualizačným monitorom - VMM? (Áno, existuje na to zvláštny mód) A ako sa zachovať keď kód v jemu patriacej VM spraví niečo čo vyžaduje spracovanie SMM handlerom? Neviem a nechcem vedieť.

A to tie 3 veci čo som tu spomenul sú len špičkou ľadovca. V x86 architektúre existujú doslova desiatky podobne zahnusených vecí, ktoré všetky navzájom musia nejako fungovať. Lenže najpodstatnejšia je spätná kompatibilita so všetkým až do Veľkého tresku. Tá sa lepšie predáva, ľuďom je pohodlnejšia, my čo s tými vecami robíme sa môžeme zblázniť a rôzne "inštitúcie" majú bohovský priestor zasahovať ľuďom do súkromia vďaka tomu že v technológii je taký bordel, ktorý sa ustrážiť jednoducho nedá. Nie, na bežné "drahoušek zákazník" účely sa tieto veci asi nebudú dať rozumne zneužiť. Ale na cielený útok od niekoho kto má dosť prostriedkov sú priam ideálne, ešte o to viac že ich "komerčná sféra" nemá dôvod riešiť.

Celkom na záver len toľko, že ak pracujete pre vládu, proti vláde, alebo niečo podobné, tak si dobre rozmyslite od koho si kúpite grafickú kartu. Ja osobne som zabezpečovanie IT súkromia vzdal.

zdroj prielom25 2010