::::::::::. :::::::.. :::.,:::::: ::: ... . :
`;;;```.;;;;;;;``;;;; ;;;;;;;'''' ;;; .;;;;;;;. ;;,. ;;;
`]]nnn]]' [[[,/[[[' [[[ [[cccc [[[ ,[[ \[[,[[[[, ,[[[[,
$$$"" $$$$$$c $$$ $$"""" $$' $$$, $$$$$$$$$$$"$$$
888o 888b "88bo,888 888oo,__ o88oo,.__"888,_ _,88P888 Y88" 888o
YMMMb MMMM "W" MMM """"YUMMM""""YUMMM "YMMMMMP" MMM M' "MMM
prielom #25, 08.06.2010, prielom*hysteria*sk, http://hysteria.sk/prielom/
intro
Zúfalý výkrik po slobode
O kradnutí identity v slovenských podmienkach
EGEE - Enabling Grids for E-science-E
Ochrana pred zhabaním
Obfuskace strojového x86 kódu
Mravný úpadok architektúry
diskusia
Tak predsa :)
Dvadsiatepiate číslo je konečne tu. Od posledného čísla ubehli štyri roky. Stalo sa mnoho vecí. V krátkosti spomeniem tie, ktoré rezonujú najviac.
Množstvo ľudí zbystrí pozornosť pri každej novej iterácii medializovanej kauzy prieniku do verejnej zóny nbu.
Mali sme zase letnú session (za tie 4 roky ich vlastne bolo viac). Prvý deň bol prakticky bez notebookov a všetci sa socializovali. Druhý deň klasicky prednášky a po nich ešte intenzívnejšia socializácia.
Zaujímavý bol kyberia hacking contest, vďaka ktorému sa popri zábave počas súťaže opravilo niekoľko dier.
Igigi zamútil vody a ukázal Slovensku niekoľko dier zrejúceho slovenského webu. Názory na to, čo spáchal svojej karme, sa líšia.
Google (a nie len on) bol terčom úspešných útokov z Číny, následne sa google na Čínu celkom naštval. Na svetle sa v tej súvislosti jasnejšie ukázali mnohé zaujímavé fakty o realite vo svete bezpečnosti. Čierny trh s exploitami a exploit packmi (ku ktorým dostanete SLA, support aj aktualizácie), trh s botnetmi (s používateľsky prívetivými ovládacími panelmi), trh s odcudzenými dátami (automatické boty, ktoré cez SQLi dumpujú dáta a ponúkajú ich komukoľvek na predaj), prepracované prípady elektronickej špionáže a rôzne iné chuťovky. V dohľadnej budúcnosti to zrejme bude iba horšie.
Zúčastnili sme sa na fantastickej otváracej párty budapeštianskeho hackerspacu (hspbp.org). Popri Maďaroch tam boli geeci zo Slovenska (hysteria.sk), Česka (hysteria.cz), Rakúska (metalab.at) aj Rumunska. Priestory sa nachádzajú v schátralom trojposchodovom dome, ktorý bude o rok zbúraný. Prostredie pripomínajúce squat parádne dotváralo atmosféru. V najväčšom peaku sa v priestore mlelo cez 100 ľudí. Na konci sme sa viacerí zhodli, že priestor po párty vyzerá ako "nuclear wasteland" a že to bola najlepšia párty, akú sme kedy zažili.
Leakol návrh ACTA a vyzerá to veľmi zle.
Od vianoc 2009 znovu beží komunitný server s recyklovaným menom c0re. Niekoľko ľudí sa pýtalo na shell. Pod spoločnú digitálnu strechu by sme ale radi prijímali iba ľudí, ktorí majú predstavu o tom, ako budú prispievať v komunite. Na aliase posadka si o vašich projektoch radi niečo prečítame. Nehanbite sa ozvať s vašimi nápadmi, projektami, alebo článkami do ďalšieho prielomu. Ozvite sa!
Ďakujem autorom článkov za to, že ich zásluhou mohol tento diel výsť.
WooDy, woody (ryba) hysteria (.bodka.) sk, 3.4.2010, Bingen am Rhein, Breakpoint 2010
návrat na obsah
Žijeme v "bezpečnej" dobe - naša spoločnosť najlepšie vie, čo je pre nás dobré a čo nie, pred čím nás má chrániť a ako na to. Všetko samozrejme pre naše spoločné kolektívne blaho a spokojnosť.
Už je to pár rokov, čo platí "data retention" EU smernica [1], podľa ktorej všetci telekomunikační operátori musia informácie o všetkých svojich klientoch (ich hovoroch ako aj o ich Internetovej prevádzke) ukladať po dobu 6-tich mesiacov až 2 rokov. Pre boj proti terorizmu, organizovanému zločinu, pedofilom, či iným deviantom, je to predsa úplne nevyhnutné.
Aby to tí teroristi nemali také jednoduché, rovno ich odpočúvajme. Nevieme síce odlíšiť teroristov od slušných ľudí, takže musíme mať možnosť odpočúvať všetkých - to ale nevadí, slušní ľudia predsa žiadne trestné činy nepáchajú. A naša SIS a neskorumpovateľný právny systém na čele s pánom Harabínom to všetko dobre vie!
A zakážme rovno všetkých mobilných operátorov, ktorí by chceli teroristov podporovať v šifrovaní hovorov - aká drzosť! Teroristi a pedofili sú predsa totiž hlúpi a určite ich nenapadne šifrovane komunikovať (pomocou šifrovaného VoIP, SMIME, či PGP).
Alebo to najlepšie, čo môžeme spraviť - podporme inovatívnych intelektuálov z SNS a zakážme používanie anonymizérov a šifrovaných spojení. [2]
Konečne zlikvidujme všetkých teroristov, ktorí nás dennodenne ohrozujú, zničme organizovaných zločincov, ktorí nám nedajú spávať, vykastrujme pedofilov a iných deviantov (v prípade KDH homosexuálov), ktorí na rohu ulici striehnu, kedy ublížia našim deťom alebo rovno nám.
Ešteže máme veľké šťastie, že Internetoví operátori vypočuli naše prosby a ukázali nám, ktoré webové stránky sú pre nás tie vhodné a ktoré by sme za žiadnych okolností nemali otvoriť. [3] [4] Lebo nikdy neviete, kde na Vás môže číhať nejaký terorista alebo prinajmenšom nejaký perverzný pedofil!
O živnú pôdu na presadenie EU zákona, ktorý bude nariaďovať dlhodobé uchovávanie údajov všetkých klientov telekomunikačných operátorov (tam patria aj ISP) sa postaral strach z terorizmu, ktorý sa ako "mém" [5] úspešne šíri od 11. septembra 2001. Okrem toho, že tento strach výrazne podporil financovanie všetkého, čo súvisí s bojom proti terorizmu a celosvetovo navýšil moc a kontrolu štátnej sféry nad jej obyvateľmi, postaral sa tiež o vznik zákonov, ktoré výrazne potláčajú individuálne práva ako na súkromie, tak anonymitu všetko v snahe spoločenského boja proti nepriateľovi - ničivému terorizmu (v USA majú na to krásny príklad v podobe "Patriot Act" [6] presadeným a schváleným G.W.Bushom).
Bohužiaľ málokto si uvedomuje, že teroristický útok predstavuje v prvom rade masívny útok vo forme strachu voči bežným ľuďom mediálne masírovaných všadeprítomnými teroristickými hrozbami. Veľa z nich stráca schopnosť spätnej racionálnej analýzy napríklad pomocou štatistiky. Inak by samozrejme vedeli, že je mnohonásobne pravdepodobnejšie, že umrú pri páde zo schodov, či uštipnutím včely, než ako obeť nejakého teroristického útoku.
Vedenie USA si to zrejme uvedomuje, ale majú podstatne "rozumnejšie" dôvody prečo do "boja proti terorizmu" investujú niekoľko násobne viac ako do akejkoľvek ochrany voči podstatne pravdepodobnejším spôsobom nášho úmrtia (napríklad do výskumu rakoviny). Je to totiž veľmi slušný biznis pre veľa zainteresovaných strán políciou začínajúc a armádou končiac. Nehovoriac o tom, že v USA vás pre prípad teroristického útoku už v pohode ktorákoľvek poisťovňa v pohode poistí.
Terorizmus (ako veľmi strašná, ale štatisticky veľmi málo pravdepodobná hrozba) vstupuje ako hlavný činiteľ pri tvorbe nových zákonov, ktoré výrazne obmedzujú naše súkromie.
Informácie zbierané o vašich hovoroch, či Internetovej komunikácie sú podstatne citlivejšie ako si myslíte - je ich totiž veľa a útočník ich môže agregovať a odhaliť z nich také informácie, ktoré by vás ani vo sne nenapadli. Na základe vašich "google žiadostí", ktoré ste zadali do vyhľadávača za posledných 5 rokov (a google si ich samozrejme spároval s vašou perzistentou cookie, ktorá vyexpiruje v roku 2020) dokáže útočník o Vás získať podstatne lepší osobnostný profil ako keby s vami strávil niekoľkohodinové osobné interview. Alebo ste nebodaj presvedčení, že do googla nič také citlivé nezadávate?
Málokto si uvedomuje, že pravdepodobnosť zneužitia týchto citlivých údajov (ktoré o Vás telekomunikační operátori starostlivo archivujú) je podstatne vyššia ako pravdepodobnosť akéhokoľvek teroristického útoku. Určite si ešte spomínate na kompletný hack Slovenského telekomu spred pár rokov, či nedávny hack Orange (ktorý sa našťastie netýkal osobných údajov klientov, alebo len o tom nevieme...)
Samozrejme zneužitie týchto údajov nemusí prísť len zo strany anonymných hackerov - veľká pravdepodobnosť zneužitia je samozrejme aj z vnútra, teda zo strany tých, ktorí k nim majú legitímny prístup. A to, že je pravdepodobnosť prípadnej korupcie v našom štáte neporovnateľne vyššia ako pravdepodobnosť teroristického útoku, je myslím každému jasné.
Na záver jednoduché zamyslenie - skutočné má zmysel, aj napriek hore uvedeným reálnym rizikám zneužitia, archivovať niekoľko rokov všetky naše citlivé dáta ako súčasť "účinného" boja proti tak málo pravdepodobnej hrozbe ako terorizmus?
Na to, aby mohol mobilný operátor (nielen na Slovensku) získať licenciu, musí technicky zabezpečiť, aby štátne orgány (na čele SIS) mali možnosť ľubovoľný hovor odpočúvať a nahrávať.
Ak by sa ktokoľvek rozhodol verejne ponúkať službu kompletne šifrovaných hovorov - bez možnosti odpočúvania, tak v našom legislatívnom systéme neuspeje - je to totiž zakázané.
Otázne, do akej miery je toto nariadenie účinné. Akýkoľvek zločinec, deviant, či nebodaj organizovaný terorista s IQ vyšším ako hojdací koník, verejné siete ako GSM, či pevné linky zásadne na výmenu veľmi citlivých údajov nepoužíva.
V prípade citlivých hovorov sa môže rozhodnúť napríklad pre šifrovaný VoIP, či zakúpiť si jedno z množstva komerčných riešení, ktoré jeho inteligentný telefón rýchlo premenia na zariadenie, ktoré hovory dokáže skutočne bezpečne šifrovať (napríklad použitím AES/256). Menej inteligentný útočník môže použiť Skype, ktoré je síce centralizovaný a odpočúvateľný, ale verím, že mimo dosahu slovenskej tajnej služby a právneho systému. O mailovej šifrovanej komunikácii (PGP/SMIME) ani nemusím hovoriť. Technológie, ktoré sú už veľmi ľahko dostupné a okamžite použiteľné s minimom potrebných znalostí.
Podvodníci, kriminálnici, či iní devianti svoje súkromne hovory už dávno šifrujú.
Nemožnosť používať verejné bezpečne šifrované komunikačné siete v konečnom dôsledku okráda o súkromie nás - slušných ľudí.
Ďalší významný faktor je zneužiteľnosť štátnej moci - máte pocit, že pri súčasnom slovenskom súdnom systéme na čele s pánom Harabínom, informácie získané vašim odpočúvaním nebudú nikdy zneužité a budú použité len v prospech spoločensky akceptovaného "vyššieho dobra"? Možno len tí najväčší optimisti (alebo zúfalci) odpovedia, že áno.
Ak by som si mal vybrať medzi súčasným systémom s možnosťou potenciálneho zneužitia našich hovorov štátnou mocou, našim "súdnym" systémom, či tajnými službami, ktoré ma "chránia" pred terorizmom, kriminálnymi živlami, či deviantami a systémom s jasne definovanými etickými zásadami pre jednotlivcov, možnosťou otvorene chrániť svoje súkromie a právom byť anonymný, i keď asi s trochu vyšším podielom kriminality, tak odpoviem:
"Ďakujem, diktatúru s nulovou kriminalitou si už neprosím, uprednostním slobodu a možnosť individuálnej voľby."
To, že sa odpočúvanie hovorov momentálne zneužíva ako zákerná politická zbraň ani nemusím zdôrazňovať.
Množstvo kriminalistov z rukáva vysype kopec racionálnych argumentov, prečo má odpočúvanie hovorov zmysel. Možno nejaký aj má - to vyslovene nepopieram. Myslím si ale, že používať verejnú službu bezpečnej šifrovanej komunikáciu u komerčného verejného operátora, kedy nebude dochádzať k žiadnemu monitorovaniu, či archivovaniu našich hovorov, je naše právo. Predsa ten citlivý rozhovor môže byt realizovaný naživo pri osobnom stretnutí ľudí - a uznáte, že by sa Vám dosť nepáčilo, keby Vás pri každom osobnom stretnutí sledovala kamera nejakej tajnej služby. A už vonkoncom by ste nerozumeli, prečo tí, ktoré sa snažia túto "kameru" odbúrať, sú v našom štáte teraz kriminalizovaní. Naša spoločnosť musí mať za každých okolností "právo" na naše odpočúvanie. Na potenciálny terorizmus treba totiž neustále dohliadať - nikdy neviete, kde a kedy sa nejaký objaví a zo dňa na deň Vás zničí!
Mať právo na súkromie a anonymitu by malo byť základne právo v každej demokratickej spoločnosti a žiadna tajná služba, či demokraticky štát by ho občanom nemal upierať. Už len preto, lebo môže byť zmanipulovaný a skorumpovaný - o čom je v našom prípade ťažšie pochybovať ako neveriť.
Bohužial realita je úplne iná.
Správa o zákaze anonymizérov na mňa zapôsobila ako nepodarený prvoaprílový žart. O to šokujúcejšie zistenie bolo, keď som sa dozvedel, že to niekto mysli úplne vážne. Okrem toho, že som zostal zarazený z nezmyselnosti samotného zákazu, zaujal ma spôsob "štátnej" kontroly, ktorý by overoval, či klienti skutočne používajú anonymizéry alebo nie a teda porušujú zákon. Napadol mi totiž len jeden účinný spôsob overovania hodný Severokórejského režimu - v prípade "potreby" do môjho bytu vtrhne komando tajnej služby, zhabe mi moj počítač, vykoná forenznú analýzu a zistí, či mám alebo nemám nainštalovaný tor, či iné anonymizéry. Ak som nebol dostatočne prezieravý a nič nešifroval, tak mám smolu - pôjdem do väzenia.
Navrhovateľov tohto zákona asi nikdy nenapadlo, že anonymizéry sa dajú použiť a aj sa používajú na množstvo dobrých a prospešných vecí (napríklad na bezpečný prístup k Internetu v diktátorských krajinách, či zverejňovanie citlivých dokumentov o zneužívaní štátnej moci, korupcii napríklad na stránku wikileaks.org ). Nakoľko je anonymizácia na slušnej úrovni, je zrejmé, že túto sieť automaticky začali využívať aj hackeri, či pedofili. To ale stále neznamená, že snaha byť anonymný a používať anonymizér je neetická, či nebodaj nelegálna činnosť.
Internet je preplnený fašizmom, satanizmom, či iných extrémistických hnutí. Je to tiež miesto, kde sa robia najväčšie platobné podvody a pridružená kriminálna činnosť - nikoho so zdravým úsudkom ale nenapadne kvôli tomu zakazovať Internet!
Ak ale nepácham žiadne trestné činy, prečo by som mal mať možnosť byť anonymný?
Napríklad preto, lebo nežijeme v dokonalom súdnom systéme, či nebodaj v krajine s dokonalou vládou. V tomto prípade je bohužiaľ vždy možné, že moje neanonymné zverejnenie (akýchkoľvek vecí hodných zverejnenia) môže vážne ohroziť ako moju osobnú identitu, rodinu, či blízkych. A nemusím pri tom spáchať nič neetické, ani nelegálne.
V diktátorských a v skorumpovaných režimoch o tom vedia svoje. A skutočne si nemôžete byť nikdy istý, že ten váš nie je akurát jeden z nich.
Blokovanie nelegálneho obsahu je určite veľmi záslužná aktivistická činnosť. Váš operátor Vás chráni proti extrémistickým, pedofilným, či inak deviantným stránkam. Samozrejme, že vie, čo je pre Vás úplne najlepšie a čo nie. Problém, o ktorom Vám určite nepovie, je netransparentnosť blokovania a nemožnosť uvedené vynútené blokovanie vypnúť.
Tušíte k akým stránkam Vám Váš operátor znemožnil prístup? Neviete? Obávam sa, že sa to ani nikdy nedozviete. Tento zoznam (alebo "blacklist") je totiž veľakrát neverejný a len úzky okruh ľudí rozhoduje o tom, čo sa na tom zozname ocitne alebo nie. Oni ale "určite" vedia, čo je pre vaše blaho to najlepšie. Ak sa na ňom jedného dňa začnú objavovať stránky, ku ktorým ste predtým pristupovali dennodenne - nedivte sa - centrálny systém len vyhodnotil, že Vám to škodilo a teraz je pre Vás dobré niečo úplne iné...
Nie všetci operátori umožňujú toto blokovanie vypnúť, vaša "ochrana" má totiž skutočne zmysel len vtedy, keď sa skutočne nedá nijako vypnúť...
Sťahovanie, či vlastnenie extrémistických videí, či pedofilného porna je zakázané zákonom. Automaticky totiž implikuje, že na výrobu je niekto zneužívaný, obvykle deti. Ak sa ale tento materiál začne generovať, teda umelo renderovať profesionálnymi videoštúdiami (po vzhliadnutí Avatara o tom už asi nikto nepochybuje), zostane tento perverzný vyrenderovaný materiál naďalej zakázaný? K žiadnemu priamemu páchaniu trestného činu totiž už nedochádza! Moralisti môžu namietať - "Jasne, že áno - stále je to navádzanie k trestnej a kriminálnej aktivite!" Liberáli na to - "A čo všetky tie krvilačné, agresívne a psychopatické filmy? Tie očividné tiež navádzajú k tejto aktivite - prečo potom nie sú zakázané v našej spoločnosti aj tie?"
Dostávame sa do situácie, kedy definujeme, ktoré vizuálne a akustické symboly (zložené z bitov) sú zakázané a ktoré nie, za ktorých vlastnenie a prehrávanie budeme stíhaní a za ktoré zase nie.
Je to veľmi klzká plocha, ktorá veľa ľudí dokáže dostať na tú "šikmú", lebo rozdiely medzi tými "zakázanými" a "povolenými" sú niekedy skutočne ťažko-uchopiteľné a podliehajú subjektívnemu rozhodovaniu napríklad toho skorumpovaného súdu.
V každom prípade, sa máme v 21. storočí na čo tešiť - stíhanie za nedovolené prehrávanie vizualizácie, či akustického záznamu. A čo je najhoršie - aj vtedy, keď si to budeme prehrávať len sami sebe...
Stále sme zvyknutí na kolektivistickú spoločnosť - štát, či väčšinu, ktorá najlepšie vie, čo je pre jednotlivca najlepšie, aké webové stránky mu škodia, akú identitu má presne pri vystupovaní na Internete používať. Jednotlivec má síce možnosť voľby, ale štát presne vie, aká voľba je preňho tá "správna" alebo aspoň "správnejšia". Keď sa rozhodne náhodou úplne inak, tak pre jeho "vlastné dobro" ho pre istotu penalizuje.
Pre "vyššie spoločenské dobro" a strach z terorizmu, či iných štatisticky málo pravdepodobných hrozieb, strácame slobodu.
Individualistická spoločnosť je totiž energeticky podstatne náročnejšia. A čo je najhoršie - núti jednotlivcov rozmýšľať a byť zodpovední. Ponecháva totiž plne na nich, či sa rozhodnú byť anonymní alebo nie, či svoje informácie a komunikáciu budú alebo nebudú verejne šifrovať, či budú konzumovať látky, ktoré uznajú za vhodné alebo sa pripravia o vlastný život, keď budú mať na to vlastný dôvod. Možno táto spoločnosť nedosiahne "vyššie" spoločenské dobro a nikdy nevyhrá nad terorizmom (čo sa podľa mňa aj tak žiadnej nepodarí), ponechá nám ale základné rozhodovacie práva - ako naložiť so svojou identitou a svojim telom.
Kvôli virtuálnym hrozbám obetúvame svoje súkromie za našu "vyššiu bezpečnosť". Zabúdajúc na možnosť centrálnej kontroly a zneužitia.
Je najvyšší čas sa zamyslieť nad svojimi individuálnymi právami, právom na súkromie a anonymitu. [7]
Pre ktorú spoločnosť sa rozhodnete Vy?
(autor využíva svoje právo na anonymitu)
Odkazy:
návrat na obsah
čo ty na to ? diskusia
Varovanie: Neprešlo podrobnou právnickou analýzou
Varovanie2: Pri písaní tohto článku autor nepoužíval žiadne servítky, ktoré by si mohol klásť pred ústa
Varovanie3: Tento text nie je navádzanie, autor si úprimne myslí, že ktokoľvek, kto tento postup zneužije, by mal zvyšok života stráviť opakovaným čítaním diela Zločin a Trest v niektorej z našich luxusných nápravnovýchovných inštitúcií. Kto tento postup realizuje, dopúšťa sa trestného činu podvodu, za čo autor nenesie žiadnu zodpovednosť. Napísanie tohto článku je jediný možný spôsob, ako súčasný neželaný stav zmeniť a tak dopomôcť k tomu, aby takéto útoky v budúcnosti neboli vôbec možné. Najprv ale o nich treba vedieť...
Tento článok vychádza v dobe, kedy sú médiá plné predpubertálnych snáh o publikovanie výsledkov z používania klikacích hackovacích nástrojov a následných snahách o získanie zákazok na penetračné testovanie. Aj keď tento útok, ktorý článok popisuje neodhalí vtipné heslo šéfa azetu, ani neukradne toľko potrebné údaje na zmenu profilu na nejakom chatovacom serveri, dúfam, že zaujme tých čitateľov, ktorí už z puberty vyrástli.
Skúsme teraz na chvíľu predpokladať, že morálny rozklad právneho štátu spôsobený obžalovaným Štefanom H. za tichej, ale o to smutnejšej spoluúčasti Róberta F. nedosiahol fatálnych rozmerov, akých dosiahol a že misky na váhe spravodlivosti sa nedajú nakláňať na ľubovoľnú stranu našou inak veľmi obľúbenou novou menou euro.
V takomto článku by som si za iných okolností na politikov nezanadával, aj napriek tomu, že niektorí z nich sú socani, čo mi je krajne nesympatické, ale hranatá tvár Róberta F., ktorá je v médiách zvraštená sociálnou nespravodlivosťou, má aj inú stránku, o ktorej by mohli rozprávať jeho voličskou základňou toľko nenávidení podnikatelia, ktorí sa dennodenne stretávajú s korupciou všade - štátnu zákazku bez úplatku v dnešnej dobe nie je možné vyhrať, súdy a úrady (ako napr. kataster) sú skorumpované a teda v súčasnom stave je útok, ktorý tu popisujem krajne zbytočný, pretože je jednoducho príliš zložitý. Napriek tomu je žiaľ nadčasový. Predpokladajme teda, že obrať niekoho o majetok chce trochu viac úsilia ako podmáznuť správneho úradníka na katastri alebo inom relevantnom úrade.
Na tomto mieste, hneď v úvode by som rád upozornil prípadných novinárov na jednu veľmi podstatnú vec. Prosím, prečítajte si tento článok poriadne predtým, než sa budete (dúfam) predbiehať v informovaní občanov. Človek by si povedal, že je to bežná vec, ale keď vidím spôsob, akým sa hovorí o kauze NBÚ, kde každý spomína akési nepodstatné heslo nbusr123 a jeho súvis s útokom, nedá mi nezneužiť tento priestor na drobné vysvetlenie, ktoré by ste našli, keby ste si poriadne prečítali pôvodný článok na serveri blackhole.sk.
Ak mu nerozumiete, mohli by ste si ho dať prípadne vysvetliť niekomu, kto tým cudzím slovám rozumie. Príde mi dôležité začať tým, že vysvetlím tento bežný omyl a tým vás snáď presvedčím, aby ste si prečítali celý článok, vrátane častí, kde píšem o odporúčaných riešeniach. Ak ste nebodaj niekto, kto môže súčasný stav ovplyvniť k lepšiemu, platí to pre vás dvojnásobne, existuje množstvo spôsobov, ktoré tento stav zdanlivo opravia, ale reálne nedôjde k žiadnej podstatnej zmene znemožňujúcej popisovaný útok.
Poďme teda k NBÚ a ilustračnému príkladu. Predstavte si, že máte pred sebou malú pevnosť. Tá má zamrežované okná, ale vchodové dvere ktosi vyhodil a namiesto nich dal jemný ryžový papier. Na prvý pohľad nevidno dnu, ale keď skúsite vojsť, kúzlo zafunguje: ryžový papier magicky obíde vaše telo a pred vami sa objaví chodba pevnosti s množstvom odomknutých dverí. V jedných dverách nájdete archív so všetkou prichádzajúcou a odchádzajúcou korenšpondenciou, množstvo ďalších dverí do iných častí pevnosti. Kdesi na konci chodby sú maličké dvere s nápisom "čistiace prostriedky", kde ktosi umiestnil zámok s číselným kódom, lebo čistiace prostriedky sú dnes drahé. Kód hravo uhádnete: 123. Vyberiete z miestnosti Savo a cestou von za sebou umývate dlážku, aby vás niekto neodhalil pomocou stôp, ktoré zanechávajú vaše topánky. Týmto svojím zistením o magickej pevnosti sa pochválite na mieste, kde sa ľudia vstupujúci do pevností podobnými zážitkami chvália (hekerské IRC) a na druhý deň sú médiá plné informácie "Škandál! V pevnosti NBÚ boli čistiace prostriedky chránené kódom 123!". Tieto články si prečítajú aj ľudia, ktorí normálne na fóra o pevnostiach nechodia. Správca pevnosti hrdo zmení číselný kód na ťažko uhádnuteľný a ešte pred obedom sa po pevnosti prechádzajú davy ľudí, ktoré prišli cez ryžovopapierové dvere. Maľujú na steny grafitti, vŕtajú do stien, keby náhodou niekoho napadlo dať namiesto papiera naozajstné dvere, aby sa do krásnej pevnosti dostali aj inak. A keď už sa na chodbe stretnú, tak sa tam porozprávajú, čo nové medzi hackermi pevností.
Verte tomu alebo nie, presne toto sa stalo, aspoň podľa článku na serveri blackhole.sk. Hackeri zneužili brutálnu dieru vo webmailovom klientovi Horde/IMP, cez ktorú by sa dostal dnu aj spomínaný dnes populárny „hacker“, pretože existoval exploit, ktorý stačilo spustiť a dať mu adresu a človek bol dnu.
Heslo nbusr123 bolo dobré akurát tak na to, aby mohli autori po sebe zahladiť stopy. Keby ho nemali, dostanú sa k mailom iným spôsobom (ukladaním si hesiel z webmail rozhrania). Po vyjdení článku v sme.sk sa na serveri odohrávalo skutočne niečo ako grafitti - rôzne hackerské skupiny menili webmailový web, dávali tam vtipné vyhlásenia, pričom správca sa tešil, že zmenil heslo nbusr123. Tú naozaj dôležitú dieru nezaplátal, hlavne, že podal trestné oznámenie a zmenil nepodstatné heslo, nech je verejnosť spokojná. Polícia so zlými hekermi predsa zatočí.
Nakoniec pevnosť oplotili a zaplatili strážnu službu, ktorá web v pracovnej dobe strážila a mimo pracovnej doby sa naň (na web!) nemohol nikto dostať, lebo to bol prvý web na svete, ktorý mal otváracie (stránkové) hodiny.
Dúfam, že predchádzajúci popis bol dostatočne jasný na to, aby každý novinár pochopil, že tento článok je dobré dočítať naozaj dokonca predtým, než budete dávať fantastické vyhlásenia.
K veci.
V našej krásnej krajine máme bežný úrad notárov, ktorí (okrem iného) zaručujú autenticitu podpisov. Podpisom vyjadrujeme svoj súhlas s textom, ktorý podpisujeme. Je to akt, ktorým môžeme napríklad splnomocniť nejakú inú osobu, aby mohla využiť naše práva. Toto je celkom užitočné, nechceme predsa nútiť našich starých rodičov, aby strávili dlhé hodiny na úrade, keď si chcú vybaviť dopravnú značku, ale radšej ich vezmeme k notárovi, kde si necháme overiť splnomocnenie.
Zostavme teraz nasledovný scenár:
Alica: babka
Branislav: Alicin vnuk
notár
Eva: útočník
Alica s Branislavom idú spolu k notárovi overiť pripravené splnomocnenie. Alica splnomocňuje Branislava na to, aby mohol za ňu vybaviť na dopravnom inšpektoráte značky k novému autu. Notár skontroluje Alicin občiansky preukaz. Na druhú stranu splnomocnenia vytlačí text s nadpisom "Osvedčenie o pravosti podpisu", ktorý hovorí, že notár osvedčil podpis Alici Chrústalovej, ktorá sa preukázala občianskym preukazom s číslom EA121992 a bola narodená 13. 3. 1930. Centrálny register (Notársky centrálny register osvedčených podpisov NcrOP) tomuto osvedčeniu pridelil číslo 92743/2010.
Branislav úspešne vybaví značky na dopravnom inšpektoráte, pretože splnomocnenie vydal notár, resp. u neho zamestnaný povinný pracovník (napr. koncipient) a osvedčenie sa nacháza v centrálnom registri podpisov presne pod tým číslom, aké je uvedené. Toto policajt na dopravnom inšpektoráte overí (ha, ha) tak, že napíše do centrálneho registra osvedčených podpisov, ktorý sa nachádza na stránke www.notar.sk nasledovné údaje: Priezvisko (Chrústalová), Krstné meno (Alica), rodné číslo (vrámci zákona o ochrane osobných údajov si nejaké vymyslite sami) a číslo osvedčenia (92743/2010).
Alica môže šoférovať nové auto a všetci sú spokojní, až kým...
Eva zhodnotí, že Alica má pekný starý byt v exkluzívnej lokalite hneď vedľa domu, v ktorom býva Ladislav Melíško. Čo keby ho tak mohla predať niekomu za veľa peňazí? Má to len jeden malý háčik: byt nie je jej.
To ale nie je žiadny problém, pretože Eva sa naučila používať hackerský nástroj "wget", ktorým všetko vybaví. Všimla si totiž, že na osvedčeniach, ktoré vydávajú notári je číslo osvedčenia sekvenčné.
Spraví teda nasledovné:
Skript využívajúci spomínaný hackerský nástroj wget sa opýta, či Chrústalová Alica s rodným číslom, ktoré ste si vymysleli pre potreby tohto príbehu náhodou nemala osvedčený podpis s číslom 1/2010. Stránka notar.sk vyhodí informáciu "nie".
Skript je ale vytrvalý a nevzdá to, opýta sa, či náhodou Chrústalovej Alici s tým istým rodným číslom nejaký notár neosvedčil podpis s číslom 2/2010.
O cca 2 hodinky neskôr sa týmto postupom skript dopracuje k číslu 92743/2010, na ktorý mu stránka odpovie: áno, tento podpis overil notár JUDr. Jozef Slama, Melíškov rad 43, Prievidza.
Eva, potešená svojim zistením ide navštíviť JUDr. Jozefa Slamu, predsa aj jej babka Gvendolína si zaslúži nové auto s novými dopravnými značkami: zvlášť, keď jej ho bude mať za čo kúpiť, lebo predá Alicin byt. Gvendolína nechá vystaviť splnomocnenie pre Evu (podotýkam, že na webe notárskeho úradu nevidno, že dokument s osvedčeným podpisom bolo splnomocnenie, pre koho bolo splnomocnenie vydané, len fakt, že Gvendolína pred notárom podpísala nejaký papier, ale to je vlastne aj tak jedno – notár si pre seba do svojich záznamov bežne tieto údaje poznačí a tie sa dajú použiť pri prípadnom súdnom spore).
Eva má notársky osvedčený papier a využije druhý hackerský nástroj: skener. Naskenuje guľatú pečiatku notára a jeho podpis. V hackerskom nástroji OpenOffice.org (prípadne ak sa buchla po vrecku a ukradla si MS Office, tak aj ten - možno používa Alicinu licenciu) napíše text Osvedčenie s údajmi Alici Chrústalovej, číslom overenia 92743/2010 a pripojí naskenovanú pečiatku a podpis. Vytlačí ho na laserovej farebnej tlačiarni.
Navštívi notára JUDr. Pavla O. Hviezdoslava v Dolnom Kubíne, kde si dá vyhotoviť notársky overenú fotokópiu. Originál, obsahujúci dôkaz o tom, že pečiatka bola vytlačená na tlačiarni skartuje.
S notársky overeným splnomocnením na predaj bytu, ktoré si samozrejme kataster a všetky ostatné inštitúcie (haha) overia na stránke notar.sk a toto overenie _PREJDE_ predá byt nič netušiacej Alici.
Časť zisku (10%) venuje na dobročinné účely (chudobným sudcom, ktorí riešia ekonomickú kriminalitu).
Teraz dôležitá informácia – pokiaľ by sa Eve toto všetko podarilo a Alici by jedného dňa niekto zabúchal na dvere, že sa má vysťahovať a ona by sa zmohla na to, aby sa v tom začala vŕtať, má tieto možnosti: obrátiť sa na občianskoprávny súd, aby vyslovil neplatnosť právneho úkonu, a to takto: pokiaľ teda je na katastri už byt zapísaný na nového vlastníka, Alica podá podľa § 80 Občianskeho súdneho poriadku (OSP) žalobu na určenie vlastníctva. Vrámci konania sa bude dokazovať aj pravosť kúpnej zmluvy a plnomocenstva. JUDr. Slama má isto niekde vo svojom počítači dôkaz, že také nič nevyhotovil, resp. nič také nemá, preto bude tvrdiť, že on nikdy také plnomocenstvo neoveril.
Súd taktiež zrejme vydá predbežné rozhodnutie podľa § 74 OSP, aby sa s nehnuteľnosťou nijak nedalo ďalej disponovať a aby uchoval status quo. Ostáva otázka dokazovania, či súd dokáže, že predmetné dokumenty boli sfalšované. S tým by problém byť nemal.
Podstatné problémy sú dva. Dokazovanie súdom môže trvať roky. A Eva môže byt predať ďalšiemu majiteľovi za peniaze a zmiznúť. Tento článok hovorí o tom, že proces osvedčovania podpisov má vážne nedostatky a nie je dostatočne silný na to, aby dokázal podvodom predchádzať. To, že sa to dá (v našom súdnictve rádovo za 2-5 a viac rokov) súdnou cestou doriešiť je síce pekné, ale stojí to nervy a podvodník môže byť dávno pod panamskými palmami s miešaným drinkom v ruke. Proces overovania by mal stáť na pevných základoch tak, aby niečo takéto nebolo možné
Pripomíname, že poškodený má taktiež právo podať trestné oznámenie za trestný čin podvodu podľa § 221 TZ.
Poďme si vysvetliť kde sú problémy:
Prvý fatálny problém je, že centrálny register listín prideľuje čísla overenia sekvenčne (nie je pravda, že inak prideľované čísla je ľahké zistiť, ako si povieme neskôr). Teraz k tomu, čo som hovoril na začiatku a toto si prečítajte prosím všetci:
NESPRÁVNE RIEŠENIA PROBLÉMU SÚ:
SPRÁVNE RIEŠENIA:
Stránka notar.sk funguje čo najrýchlejšie, vybaví kohokoľvek bez blbých obmedzení a hneď. Centrálny register prideľuje identifikátor listiny, ktorým je napríklad 64 znakový alfanumerický reťazec nerozlišujúci veľké a malé písmená. Napríklad takýto:
BDGI84ZH7XHMJ75IETGY5D3LEYBLYXJ8OZDDIP1NOFR7DXJ1T7BXFHJN7E3LAGCL
Skúsme zistiť zložitosť odhalenia postupom, aký sme si ukázali. Predpokladajme, že overenie je rýchle tak ako jedna inštrukcia procesora (napríklad pričítanie čísla). V skutočnosti je jedno overenie určite pomalšie a to výrazne (treba niečo poslať po sieti, na druhej strane overiť, spracovať, poslať odpoveď, spracovať odpoveď, to zaváňa tisíckami inštrukcií a spomaľovanie bude robiť hlavne pamäť, disky a sieť). Predpokladaním, že overovanie je rýchlejšie nič nepokazíme.
Na to, aby sme si tipli správny reťazec musíme v priemere vyskúšať (36^64)/2 možností, čo je
2005995957273815240032526693851221906345201243870906112977865811327727861629428624271080611127492608
Majme jedno jadro procesora Intel i7 Extreme 965EE s 3.2GHz taktovacou frekvenciou, ktoré dokáže spracovať 76383 miliónov inštrukcií za sekundu. Teda pri našich predpokladoch by potreboval
((36^64)/2)/(76383000000)sekúnd, čo je
((36^64)/2)/(76383000000)/(3600*24*365) = 832773189393260208041628277593154954893393277593721294373967035904483086339708984rokov.
Počítajme, že za najbližších pár rokov budú počítače stomiliónkrát rýchlejšie, útočník ich bude mať k dispozícii sto miliónov kusov a teda bude potrebovať iba:
((3664)/2)/(76383000000)/(3600*24*365*100000000*100000000) = 83277318939326020804162827759315495489339327759372129437396703590rokov.
Myslím, že vtedy už Melíško nebude in a cena Alicinho bytu v rádioaktívnom pekle zvanom Zem bude popri byte s výhľadom, ktorý sa bude ľudstvu ponúkať v blízkosti Alfa Centauri celkom podpriemerný.
Praktické problémy s takýmito dlhými identifikátormi vyriešia QR kódy, ktoré môže notársky systém automaticky k osvedčeniu tlačiť (budú sa dať načítať strojovo a tak úrady a súkromné osoby, ktoré spracúvajú veľké množstvo splnomocnení nebudú musieť nič takéto prepisovať. QR kódy dokážu čítať už aj mobilné telefóny alebo počítače s web kamerou).
Toto riešenie ale nie je z istého dôvodu dostatočné - stále nerieši problém, keď si to číslo skopíruje ten neskorumpovateľný policajt alebo iný úradník.
Správne riešenie sa v niečom podobá zaručenému elektronickému podpisu. Osvedčenie obsahuje aj informáciu o tom, _čo_ daný človek podpísal, nie len fakt, že to bol on. Aby sme sa vyhli nutnosti uploadovať naše dokumenty na centrálny register (čo by nebolo určite dobré, žiadúce a ani zďaleka bezpečné), mohol by notár napríklad dokument v čiernobielej primeranej kvalite naskenovať, podpísať svojim elektronickým podpisom a dokument aj s podpisom priložiť k osvedčeniu (napríklad ako spomínaný QR kód, ak by bol dokument dostatočne skomprimovaný, prípadne ako iný podobný vytlačiteľný kód: High Capacity Color Barcode použiteľný s bežnými tlačiarňami a skenermi dokáže uložiť cca 542 bajtov na centimeter štvorcový, teda na A4 papier dokážeme vytlačiť cca 318KB, čo stačí na naskenovanie opačnej strany, jej digitálne podpísanie notárom s informáciou, koho podpis overuje).
Takto notár overí podpis na konkrétny dokument a dá sa overiť, ku ktorému dokumentu sa daný podpis viaže.
Keby sa toto podarilo presadiť (keby...), tak by bolo všetko výrazne lepšie, ale stále to nerieši jeden problém, okrajový, ale podstatný. Napríklad také splnomocnenie sa nedá efektívne zobrať naspäť. Dá sa zobrať späť v konkrétnom prípade (napríklad oznamom katastru, daňovému úradu, ... – ak vieme, že je nejaké splnomocnenie, ktoré treba vziať späť). Ale aj napriek tomu môžeme za danú osobu kúpiť niečo na leasing, prípadne to splnomocnenie zneužiť inak. Rozumní ľudia splnomocnenie obmedzia časovo. Ale to sa nie vždy podarí. Predstavte si malú firmu, 5 ľudí, konateľ splnomocní sekretárku. Firma narastie, predá sa veľkej korporácii, konateľ ostane a sekretárka, ktorá v danej firme už dávno nepracuje sa rozhodne, že svoje 8 rokov staré splnomocnenie využije. Nič jej v tom nebráni a to splnomocnenie sa nedá zrušiť. Konateľa možno zrušiť vymazaním z obchodného registra, ale sekretárku nezruší nikto. Dá sa jej oznámiť, že sa plnomocenstvo ruší, ale reálne ten papier nikto nezoberie späť a nestratí platnosť.
Alebo inak – som firma, ktorá predáva niečo na leasing, nemám ako zistiť, že či splnomocnenie, ktoré mi niekto dáva pôvodný splnomocniteľ nezrušil. Neexistuje centrálny register zrušených splnomocnení, kde by sa to dalo overiť. Pri prípadnom súdnom spore, ktorý skončí zase o 5 rokov sa to samozrejme dorieši, ale prečo podvodom nepredchádzať?
Bolo by dobré sa znova inšpirovať z elektronického podpisu a spraviť (notármi kontrolovanú) autoritu zrušených splnomocnení. Pri každom splnomocnení sa jeho hash jednoducho overí cez stránky notar.sk. Ak chcem splnomocnenie zrušiť, prídem k notárovi, na základe mojej identity (občiansky preukaz) a mena osoby, ktorú som splnomocnil môžem splnomocnenie kedykoľvek zrušiť. Nezruší to platnosť úkonov, ktoré boli vykonané do tohto času, ale žiadny nový úkon s daným splnomocnením sa vykonať nedá.
Poviete si -- prečo by sme mali riešiť sprostých ľudí, ktorí dávajú časovo neobmedzené splnomocnenia?
Možno sa budete čudovať, ale ani náš zákon vám nedovolí sa paušálne do budúcnosti zbaviť svojich práv. Môžete sa vzdať práva jednotlivo (napr. tak, že ho nevyužijete), ale nemôžete sa dobrovoľne vzdať niektorých svojich základných práv do budúcnosti.
Prečo by potom malo byť možné umožniť niekomu využívať všetky vaše práva neobmedzene dlho bez toho, aby ste toto mohli kedykoľvek vziať späť? (pripomínam len, že vziať - akýmkoľvek spôsobom - ten pôvodný papier o splnomocnení je nanič: sekretárka Eva si mohla spraviť 20 overených fotokópií, ktoré majú rovnakú právnu platnosť). Odvolanie sa dá spraviť buď tak, že podpíše zrušenie plnomocenstva alebo sa jej doručí oznam o zrušení plnomocenstva s doručenkou. Toto ale tomu, kto to chce zneužiť nezoberie ten papier a ktokoľvek, kto to plnomocenstvo chce overiť, nemá kde (pošta nemá web, kde sa dá overiť, či niekto niekomu zrušil plnomocenstvo, ani na to nie je centrálny register). Samozrejme, zase na súde sa to dá doriešiť.
Záverom: Prosím, žiadna CAPTCHA, žiadne obmedzenie počtu lookupov, žiadne otravovanie užívateľov, nielenže je to nesystémové, ale nepomôže to. Ani trochu.
Systémové riešenia sú tri a bolo by dobré ich spraviť v takomto poradí:
Záver 2: Systémové nedostatky, ktoré tu boli popísané možno znejú technicky jednoducho, treba si ale uvedomiť, že jedným notársky overeným papierom je reálne možné jednoducho a rýchlo človeku zničiť život: pripraviť ho o majetok a tak zaútočiť na jeho najzákladnejšie ľudské práva. Ide o kvalitatívne väčší prúser ako Igigiho heslá a treba ho riešiť akútne a hneď. Neverím, že pod vedením Štefana H. sa s tým niečo stane (aj keď v tomto by som mu rád krivdil), prosím ale poslancov, aby sa zamysleli nad reformou, ktorá by toto opravila. Taktiež je dosť pravdepodobné, že bod 1 dokáže vyriešiť notárska komora bez akejkoľvek legislatívnej zmeny. Smutné je len to, že so starými podpismi to nič nespraví a teda tento útok bude dlhé roky použiteľný aj ďalej (môžem si teraz vytlačiť splnomocnenie s dátumom a osvedčením z roku 2002 a bude platiť rovnako ako vtedy). Je to o dôvod viac, začať to riešiť hneď.
Záverom znova pripomínam, že tento systémový nedostatok je v osvedčovaní podpisov. Akékoľvek zneužitie tohto postupu je stále trestným činom a náprava je súdne vymáhateľná. Jediný problém je v tom, že je to bezpečnostná slabina v systéme, ktorý má podvodom predchádzať, čo podľa nás nerobí dostatočne kvalitne a existuje spôsob, ako to spraviť lepšie (niektoré spôsoby sme popísali v tomto článku).
Továreň na paradajky, tovarennaparadajky (ryba) hysteria (.bodka.) sk
návrat na obsah
čo ty na to ? diskusia
EGEE - Enabling Grids for E-science-E
V tomto článku by som rád uviedol čo to je GRID (predstava podľa projektu EGEE), ako je realizovaný (t.j. gLite middleware), na čo je vhodný - ergo čo sa sním robí a pod. Celý výklad bude voľnejší z dôvodu relatívne veľkého množstva služieb, ktoré navzájom spolupracujú a už tá schéma je relatívne komplikovaná. Dúfam preto, že výpovedná hodnota celého dielka neutrpí a že si v ňom nájdete nejakú novú informáciu a niečím Vás obohatí. S výnimkou niektorých technických detailov, možno nájsť podrobnejší a lepšie spracovaný opis GRIDu v príručke pre používateľa [1]. Na záver ešte podumám o tom, čo si myslím o koncepcii bezpečnosti tohoto projektu a o (ne)výhodách v praxi. Nakoniec si neodpustím krátky komentár o tom ako to vyzerá na Slovensku.
"The EGEE project has a main goal of providing researchers with access to a geographically distributed computing Grid infrastructure, available 24 hours a day. It focuses on maintaining and developing the gLite middleware and an operating a large computing infrastructure for the benefit of a vast and diverse research community"
-- gLite 3.1 user Guide [1]
"WLCG/EGEE operates a production Grid distributed over more than 200 sites
aroung the world, with more then 30 000 CPUs and 20 PB of data storage"
-- gLite 3.1 User Guide [1] (dnešné čísla : 150 000 CPU, 70 PB - celková
kapacita [5])
Na úvod treba uviesť pár pojmov :
atribút = parameter + aritmetika v rámci parametrov) opísané čo sa má spustiť, s akými vstupnými parametrami, kde možno nájsť vstupné dáta potrebné k vykonaniu, kam sa majú ukladať výsledky, požiadavka na architektúru (32/64 bit), požiadavka na veľkosť RAM, požiadavka na rýchlosť procesora a mnohé iné. Zoznam možných atribútov aj s ich významom je fixne daný [2].Nie všetky tieto parametre sú povinné. Príklad takej úlohy môže byť:
Executable = "mojskript.sh";
Arguments = "-Wall `pkg-config --cflags --libs libsysf` zoznam.txt";
StdOutput = "std.out";
StdError = "std.err";
InputSandbox = { "/home/k0fein/mojskript.sh", "/home/k0fein/zoznam.txt" };
OutputSandbox = { "std.out", "std.err" };
týmto hovoríme GRIDu, že chceme vykonať skript mojskript.sh a to konkrétne spôsobom mojskript.sh -Wall `pkg-config --cflags --libs libsysf` zoznam.txt a od GRIDu očakávame, že po vykonaní vráti štandardný prúd pre výstup a chyby. To akým spôsobom poslať túto úlohu bude vysvetlené o chvíľu.
Ako už bolo spomenuté GRID je sieťou centier. Tie sa od seba líšia množstvom výpočtových a úložných zdrojov. Sú organizované do regiónov a v rámci nich je ich činnosť koordinovaná regionálnym operačným centrom ROC (Regional Operation Center). Ľudia, ktorí GRID používajú, sú grupovaní do tzv. virtuálnych organizácií (VO). Každý kto chce používať prostriedky GRIDu dostane svoj osobný certifikát (x509) u certifikačnej autority pre danú krajinu/inštitúciu. Následne sa registruje do VO do ktorej chce patriť. Členom VO nemusí byť len človek, môže ním byť aj počítač/proces - čokoľvek, čo sa môže prezentovať platným certifikátom. Administrátori danej VO zodpovedajú za svoj software (ktorý majú kúpený, alebo si ho aj sami programujú). Tento software sa týka zamerania danej VO - čiže napríklad VO pre medicínu má software pre medicínu, VO pre experimenty v CERNe má software pre rekonštrukciu a analýzu dát zo zrážok v LHC a pod. Je na centrách, ktoré VO sa rozhodnú podporovať a teda ktorým VO poskytnú svoje prostriedky (CPU/miesto). Administrátori VO potom nainštalujú na server zdieľaný všetkými počítačmi, ktoré môžu vykonávať úlohu, svoj software, čím ho sprístupnia pre každú úlohu ktorá sa bude v rámci daného centra spracovávať. Všetko je založené na Linuxe a všetky centrá poskytujú viac menej to isté prostredie (čo sa týka operačného systému, verzie jadra a systémových knižníc). Linuxová distribúcia je Scientific Linux (CERN) odvodená od RedHat Enterprise Linux.
Neodpustím si malú úvahu : Scientific Linux je distribúcia ktorú spravuje CERN a Fermilab (centrum časticovej fyziky v USA): Je založená na RedHat Enterprise Linux-e a tieto dve inštitúcie majú s RedHatom zmluvu na takmer všetko načo sa zmluva dá spraviť. Otázka znie, načo je im vlastná distribúcia ? Prečo nemôžu jednoducho zobrať nejakú už existujúcu a pracovať len na adaptácii svojho software-u pre ňu ? (to je filozofická otázka, odpoveď je zrejme jasná, t.j. môžu odôvodniť pumpovanie financií do IT oddelenia)
Ak ponúknutý software danej VO nevyhovuje požiadavkám úlohy, je možné skompilovať si svoje vlastné nástroje (toto má samozrejme svoje obmedzenia - počítač na ktorom sa úloha vykonáva má obmedzené prostriedky, tak isto čas ktorý môže úloha stráviť na danom počítači je obmedzený). Predpokladá sa, že používatelia budú posielať veľa úloh, ktoré by mali byť zrátané podľa možnosti naraz. Nerád by som použil slovo paralelne, keďže tá sieť nie je primárne stavaná na to, aby to bolo paralelné, aj keď je možné špecifikovať v rámci úlohy túto požiadavku - tzv. MPI úlohy.
Oficiálne tkvie model virtuálnych organizácií v spôsobe akým vedci pracujú (evidentne nehľadali inšpiráciu v SR). Vedci sa tiež grupujú do skupín, ktoré spolupracujú na tom istom probléme, používajú ten istý software a zdieľajú tie isté dáta.
EGEE projekt, ako aj Európska Únia predpokladajú, že sa do používania siete GRID zapojí aj súkromný sektor a to v takej miere, že ho bude môcť financovať. Keďže pre každú úlohu sa zaznamenáva koľko minula prostriedkov, môžu sa nahodiť ceny a môže sa na tom začať zarábať. V tomto bode nastáva malá kolízia. Ako so už spomenul, na to, aby to-ktoré centrum prijalo a spracovalo úlohu danej VO, musí túto VO podporovať (t.j. služby centra o nej musia vedieť a musia autentifikovať ľudí z danej VO). Preto mi nie je celkom jasné ako chcú zabezpečiť férové poskytovanie prostriedkov, keďže veľké koncerny si môžu dovoliť platiť viac a teda si môžu dovoliť "kúpiť dané centrum". Čo je koniec koncov aj prípad 2 zo 4och centier v SR, ktoré sú plne financované z CERNu (čo sa počítačového vybavenia týka) a teda podporujú len VO z CERNu. Obávam sa preto, že tento model môže v krajinách ako je SR viesť k stavu: čo centrum, to vlastná VO a nikto nikoho nikam nepustí, nieto ešte zdieľať CPU/HDD. (ale to je môj subjektívny názor).
Cena celého projektu EGEE (aj so železom, aj keď teda to priamo EGEE neposkytlo) je momentálne ~47 150 000 € [5]. gLite používa Apache licenciu a časť jeho zdrojových kódov možno nájsť v [7]. Dokumentácia je v [13]. gLite je zmes mnohých produktov a mnohých technológií. Bolo adaptované množstvo softvéru, ktorý už bol napísaný a použitý v iných projektoch (Open Science Grid, NorduGrid, TORQUE/PBS, LCG). V súčasnosti sú v produkcii verzie 3.1 a 3.2. 3.2 je čisto 64 bitová. Okrem samotnej siete centier, existuje sieť takzvaných PPS - Pre Production Sites (podľa posledného diania sa premenujú na "Early Adopters"), čo sú centrá, kde sa testuje a ladí gLite ktorí sa práve vyvíja a nie je vhodný pre produkčné prostredie.
Projekt EGEE je momentálne vo svojej tretej fáze (projekt sa oficiálne volá EGEE III). 1. Mája 2010 končí a nastane prechodné obdobie. Nahradiť by ho mal projekt EGI - European Grid Initiative. Medzi zmenami, ktoré prinesie je napríklad odbremenenie ľudí sledujúcich stav v regiónoch (pre nás je to federácia strednej Európy) tým, že rozseká zodpovednosť za stav centier na jednotlivé štáty a ich národné gridové iniciatívý (NGI - National Grid Initiatives). Ako to už v takýchto veľkých projektoch býva, zatiaľ sa nevie, čo všetko sa bude meniť a zmeny budú aj tak prebiehať skôr kontinuálne - ako reakcia na požiadavky a skúsenosti používateľov a VO.
Teraz trošku k technickým detailom a realizácii tejto siete. Základom je centrum, ktorého jednotlivé (typické) časti možno schematicky znázorniť nasledovne:
Internet
|
+--------+-------------+---+----+-------+--------+---------+ =======================
| | | | | | |
+----+ +------+ +------+ +----+ +----+ +-----+ +-------+ Vonkajšia sieť
| IS | | CE | +---| CE | | CE | | SE | | MON | | VOBOX | - host certifikáty
+----+ | LRMS | | +------+ +----+ +----+ +-----+ +-------+ - GOC DB
+------+ | | | | |
| | +------+ | | | =======================
| H| | LRMS |---+ | H |
HBA | B| +------+ | B |
| A| | | A |
| | HBA| | |
+----+ | +----+ | |
+----+| | +----+|-------+ | Vnutorná
+----+|+ | +----+|+ | sieť
+- | WN |+ +-| WN |+ |
| +----+ +----+ |
| | |
+-----+ +-----+ |
| NFS | | NFS |----------------------------------+ =======================
+-----+ +-----+
Je to schematické znázornenie vzťahov jednotlivých služieb a komponentov. Delenie na časti (vonkajšia/vnútorná) je z pohľadu vonkajšieho prístupu (t.j. do vnútornej siete sa nedostanete, no z nej sa dostanete von). Časť označená ako "vonkajšia sieť" musí byť viditeľná z internetu. Zvyšok je už na administrátoroch, ktorí si musia uvedomiť, že medzi službami sú vzťahy (napr hostbased autentifikácia), ktoré musia byť dodržané, inak to nebude fungovať.
IS - Informačný systém : Poskytuje statické (počet a typ služieb CE/SE/MON/VOBOX/WN, tagy pre software VO a iné) ako aj dynamické (počet úloh ktoré sa rátajú, počet zostávajúceho voľného miesta a pod.) informácie. Tento typ IS používa BDII - Berkeley Database Information Index, čo je v podstate LDAP. Informácie sa z jednotlivých počítačov "vonkajšej siete" (na každom beží proces resource BDII) zbierajú na jeden počítač (site BDII) a sú k dispozícii pre top-level BDII ktorá je v rámci regiónu databázou všetkých centier a ich stavov (top-level BDII sa nenachádza v centre). BDII používa tzv. GLUE schému [3] - strom informácií o každej službe a poskytovaných prostriedkoch (ako aj ďalšie atribúty). Tieto informácie nie sú nijako chránené a sú čitateľné kýmkoľvek (bez nutnosti mať osobný certifikát). Služba, ktorá ich v peknej forme prezentuje, je GStat [4]. Všetky počítače poskytujúce služby na vonkajšej sieti musia mať svoj host certifikát a musia byť zapísané v Grid Operation Center Databáze - kde sú okrem týchto informácií uvedené aj kontakty na administrátorov/bezpečnostných technikov ako aj informácie o plánovaných odstávkach (scheduled downtime).
CE - Computing Element : Skupina počítačových zdrojov (farma/klaster) zabezpečujúcich spustenie úlohy. CE obsahuje Grid Gate - všeobecné rozhranie medzi internetom a klastrom, ktoré mapuje požiadavku používateľa na lokálne konto, LRMS - Local Resource Management System (tiež občas nazývaný batch system) zabezpečujúci správu úloh ktoré sa vykonávajú (úlohy sú vo frontách, na vykonanie sa pošle tá čo je navrchu) a samotný klaster pozostávajúci z počítačov - Worker Nodes, kde s úloha spustí (presnejšie príkaz v nej určený). Úloha beží vždy na jednom počítači (t.j. jedna konkrétna úloha nemôže bežať naraz na 2 rôznych počítačoch, no môže používať dve (a viac) jadrá procesora). Z obrázka je vidno, že je službu LRMS možné nainšťalovať zvlášť. Medzi WN a LRMS/CE musí byť hostbased autentifikácia pre ssh, pretože na skopírovanie výstupu úlohy sa používa scp (áno dalo by sa to spraviť aj inak, no WLCG/EGEE to vyžaduje takto). Z obrázka tiež vidno, že WN zdieľajú NFS server, kde si VO inštalujú svoj software (napr. tak, že pošlú úlohu, ktorá ho nainštaluje). Je niekoľko rôznych LRMS systémov a niekoľko rôznych CE ktoré môžu byť vzájomne použité. Každé sa vyznačuje inými prednosťami a je na centre, ktoré sa rozhodne použiť (zväčša je to dané požiadavkami VO ktoré sú podporované). Striktne vzaté CE zodpovedá jednej fronte v rámci LRMS a je určené ako:
CE ID = <grid gate hostname>:<port>/<typ Grid Gate-u>-<typ LRMS>-<meno fronty>napríklad
oberon.hep.kbfi.ee:2119/jobmanager-lcgpbs-long sbgce2.in2p3.fr:8443/cream-pbs-cms
SE - Storage Element : Poskytuje jednotný prístup k zdrojom na ukladanie dát. Väčšina SE je manažovaných cez SRM, Storage Resource Manager - služba, ktorá poskytuje veci ako transparentnú migráciu dát z diskov na pásky, rezervácia miesta, jednotné rozhranie pre prístup k dátam, podporuje rôzne protokoly pre prístup k dátam a pod. Najčastejšie používané SE sú DPM (len disky), dCache (disky a pásky) a CASTOR (hlavne pásky s cachovaním na disky).
MON - Ďalší typ informačného systému sa volá R-GMA (Relational Grid Monitoring Architecture) a je zahrnutý v službe MON. Na rozdiel od, na LDAP založenej BDII, poskytuje SQL-u podobné príkazy umožňujúce lepšiu manipuláciu s dátami v databáze. Je sprostredkovaný servletmi (tomcat). Používa sa napríklad na uchovávanie histórie a súčasného stavu spracovaných úloh zo všetkých CE v rámci centra. Existencia dvoch rôznych informačných systémov v rámci GRIDu je historická. Vo verzii gLite 3.2 už tento typ informačného systému nefiguruje a spolu s ním ani tie CE ktoré ho vyžadujú.
VOBOX - V prípade, že by danej VO nestačili štandardné služby ktoré centrum poskytuje, môže použiť počítač vyhradený len pre ňu a využiť ho na špecializované účely s ňou spojené.
Okrem uvedených treba spomenúť aj službu WMS - Workload Management System. Nenachádza sa nutne v centre, no musí niekde existovať (aspoň jedna). Jej úlohou je prijímať úlohy od používateľov, priradiť im najvhodnejšie CE, zaznamenávať stavy týchto úloh a vrátiť používateľom výstup z úloh. Najvhodnejšie CE sa hľadá na základe požiadaviek udaných v úlohe a identifikovaním vhodných zdrojov z top-level BDII. V prípade, že sú v úlohe špecifikované aj vstupné súbory, hľadá sa CE tak, aby bolo podľa možnosti čo najbližšie (geograficky) Storage Element-u, ktorý tieto súbory poskytuje. Úloha je potom poslaná na spracovanie do centra kde sa dané CE nachádza. Bližšie o WMS v [8].
Poslednou technickou záležitosťou, ktorú by som chcel opísať je životný cyklus úlohy. Tá pri bezproblémovej prevádzke prechádza stavmi SUBMITTED, WAITING, READY, SCHEDULED, RUNNING (REALY RUNNIG), DONE, CLEARED [1] :
~/.globus/usercert.pem, ~/.globus/userkey.pem). Na to, aby sa mohol autentifikovať voči sieti si vytvorí tzv proxy certifikát. Pri ďalšom použití sa už pracuje pomocou proxy certifikátu. Jeho platnosť je zväčša 24 hodín. Vytvoriť proxy certifikát je možné aj s pomocou služby VOMS (Virtual Organisation Membership Service), ktorá do proxy certifikátu pridá rozšírenie obsahujúce informácie o VO samotnej, skupiny do ktorej v rámci VO používateľ patrí a úlohy ktoré vo VO zastupuje (napr. že je administrátor).
https://WMShost:port/hash. Používateľ si ho v princípe nemusí pamätať, pretože sa na UI nachádzajú nástroje, ktoré mu vrátia zoznam identifikátorov pre všetky jeho úlohy. Toto "poslanie úlohy na spracovanie" je zaznamenané službou Logging nad Bookkeeping (LB). Stav úlohy je v rámci GRIDu nastavený na SUBMITTED.
uuidgen) až po niečo tipu srm://se_hostname/dpm/home/dteam/mojedata.tar.gz. Súbor môže byť replikou existujúceho). V prípade, že sa začali vyberať prostriedky, t.j. WMS pracuje na tom aby našla CE pre úlohu, zmení (a zapíše do LB) sa stav na WAITING.
Stav úlohy sa dá po celú dobu z UI sledovať pomocou služby LB. Vykonávanie úlohy a celá réžia okolo toho je autonómna vzhľadom na pripojenie používateľa (t.j. používateľ nemusí ostať nalogovaný na UI po celú dobu vykonávania úlohy).
Komunikácia medzi službami je šifrovaná a autentifikácia sa deje s použitím proxy certifikátu používateľa. Proxy certifikát má v sebe dočasne vygenerovaný privátny kľúč, dočasne vygenerovaný certifikát podpísaný používateľom a certifikát používateľa. Proxy certifikát má krátke trvanie (12 - 24 hodín). Dôvod prečo sa nepoužíva priamo certifikát používateľa a jeho kľúč je ten, že niektoré služby musia občas vystupovať v úlohe používateľa a na to aby sa mohli autentifikovať potrebujú privátny kľúč no a privátny kľúč používateľa nemôže ísť len tak do sveta. Krátke trvanie proxy certifikátu môže byť nevýhodou pre úlohy s dlhším trvaním než je doba jeho vypršania. Toto sa obchádza pomocou MyProxy server-a, ktorý periodicky predlžuje platnosť proxy certifikátov. Ak by niekto nepovolaný odcudzil tento certifikát, tak by mohol (na dobu trvania) vystupovať ako daný používateľ (v podstate credential theft) a mal by teda prístup k adekvátny zdrojom (a čo je ešte horšie - používateľ má v rámci VO rôzne úlohy (Roles) a ak je náhodou administrátor VO, mohol by niekto s týmto odcudzeným certifikátom narobiť pekný bordel). O tomto riziku sa vie a toleruje sa s vedomím, že útočník má maximálne "24" hodín (doba platnosti proxy certifikátu) na to aby vykonal to čo chcel.
Ako som už uviedol, informačný systém je nešifrovaný a prístupný každému napr. cez GStat [4]. Napríklad také centrum LIP-Lisabon, podľa GStatu (http://goc.grid.sinica.edu.tw/gstat/LIP-Lisbon/) má 4 CEčka, 2xSE, 1 proxy server a WMS. Dokonca sú tam hostname-y serverov a ich služby. Takže len na základe tohoto nástroja možno získať slušnú predstavu o centre. No a keďže reverzné DNS je povinné pre všetky stroje v GRIDe, tak môžeme spraviť rýchly scan (na priamu otázku musí dať DNS odpoveď) :
k0fein@macgyver:~$ host srm01.lip.pt srm01.lip.pt A 193.136.90.58 k0fein@macgyver:~$ whois 193.136.60.58 ... inetnum: 193.136.90.0 - 193.136.91.255 netname: LIP-PT-1 descr: Laboratorio de Instrumentacao e Particulas ... k0fein@macgyver:~$ for i in `seq 2 253`; do host 193.136.90.$i | grep -v "NX"; done 22.90.136.193.in-addr.arpa domain name pointer ce02.lip.pt. 23.90.136.193.in-addr.arpa domain name pointer ce01-atlas.lip.pt. 24.90.136.193.in-addr.arpa domain name pointer ce01-cms.lip.pt. 25.90.136.193.in-addr.arpa domain name pointer ce01-ibergrid.lip.pt. 26.90.136.193.in-addr.arpa domain name pointer ce02-atlas.lip.pt. 27.90.136.193.in-addr.arpa domain name pointer ce02-cms.lip.pt. 28.90.136.193.in-addr.arpa domain name pointer ce01.lip.pt. 31.90.136.193.in-addr.arpa domain name pointer sitebdii01-ibergrid.lip.pt. 32.90.136.193.in-addr.arpa domain name pointer se02.lip.pt. 34.90.136.193.in-addr.arpa domain name pointer crab01.lip.pt. 35.90.136.193.in-addr.arpa domain name pointer i2g-ui02.lip.pt. 37.90.136.193.in-addr.arpa domain name pointer mon01.lip.pt. 42.90.136.193.in-addr.arpa domain name pointer phedex.lip.pt. 43.90.136.193.in-addr.arpa domain name pointer se05.lip.pt. 45.90.136.193.in-addr.arpa domain name pointer squid-cms.lip.pt. 46.90.136.193.in-addr.arpa domain name pointer site-bdii.lip.pt. 56.90.136.193.in-addr.arpa domain name pointer ui01.lip.pt. 57.90.136.193.in-addr.arpa domain name pointer squid01.lip.pt. 58.90.136.193.in-addr.arpa domain name pointer srm01.lip.pt. 59.90.136.193.in-addr.arpa domain name pointer gftp02.lip.pt. 60.90.136.193.in-addr.arpa domain name pointer gftp03.lip.pt. 61.90.136.193.in-addr.arpa domain name pointer gftp04.lip.pt. 62.90.136.193.in-addr.arpa domain name pointer jeep.lip.pt. 63.90.136.193.in-addr.arpa domain name pointer ui-atlas.lip.pt. 64.90.136.193.in-addr.arpa domain name pointer ui-cms.lip.pt. 65.90.136.193.in-addr.arpa domain name pointer lfc01.lip.pt. 77.90.136.193.in-addr.arpa domain name pointer lfc02.lip.pt. 86.90.136.193.in-addr.arpa domain name pointer ui02.lip.pt. 87.90.136.193.in-addr.arpa domain name pointer ii03.lip.pt. 89.90.136.193.in-addr.arpa domain name pointer ce04.lip.pt. 91.90.136.193.in-addr.arpa domain name pointer wms01.lip.pt. 92.90.136.193.in-addr.arpa domain name pointer ce03.lip.pt. 93.90.136.193.in-addr.arpa domain name pointer ui04.lip.pt. 94.90.136.193.in-addr.arpa domain name pointer i2g-site-bdii. 100.90.136.193.in-addr.arpa domain name pointer vclip01.lip.pt. 103.90.136.193.in-addr.arpa domain name pointer i2g-voms.lip.pt. 104.90.136.193.in-addr.arpa domain name pointer voms.lip.pt. 108.90.136.193.in-addr.arpa domain name pointer i2g-ce01.lip.pt. 109.90.136.193.in-addr.arpa domain name pointer i2g-mon01.lip.pt. 110.90.136.193.in-addr.arpa domain name pointer i2g-ui01.lip.pt. 111.90.136.193.in-addr.arpa domain name pointer i2g-ras01.lip.pt. 112.90.136.193.in-addr.arpa domain name pointer i2g-ras02.lip.pt. 120.90.136.193.in-addr.arpa domain name pointer pps-ui01.lip.pt. 121.90.136.193.in-addr.arpa domain name pointer pps-sbdii.lip.pt. 122.90.136.193.in-addr.arpa domain name pointer pps-tbdii.lip.pt. 123.90.136.193.in-addr.arpa domain name pointer pps-mon.lip.pt. 124.90.136.193.in-addr.arpa domain name pointer pps-px01.lip.pt. 125.90.136.193.in-addr.arpa domain name pointer pps-lfc01.lip.pt. 126.90.136.193.in-addr.arpa domain name pointer pps-voms01.lip.pt. 127.90.136.193.in-addr.arpa domain name pointer pps-ce01.lip.pt. 128.90.136.193.in-addr.arpa domain name pointer pps-wms01.lip.pt. 129.90.136.193.in-addr.arpa domain name pointer pps-srm01.lip.pt. 130.90.136.193.in-addr.arpa domain name pointer pps-ce02.lip.pt. 131.90.136.193.in-addr.arpa domain name pointer pps-dpm.lip.pt. 156.90.136.193.in-addr.arpa domain name pointer px01.lip.pt.
Zrazu zbadáme, že je tam niekoľko User Interface-ov (napr. ui-atlas.lip.pt, ui-cms.lip.pt), alebo že tam majú v skutočnosti 2 centrá, jedno normálne a jedno PPS (Pre Production Site) o ktorom vieme, že sa tam testujú nové verzie gLite-u, ktoré ešte len majú prísť do produkcie, takže celá tá pps časť je "z definície" nestabilná. S takto oťukaným rozsahom (a to sme reálne nepingli ani jeden stroj len sme sa slušne a legálne spýtali DNSka na celý rozsah) sa dajú robiť ďalšie zaujímavé veci - obzvlášť s UIčkami, tie sú také obľúbené, prípadne nejaký ten DDoS na CEčka (na hocičo kde beží tomcat a nechať ho vyžrať celú pamäť) a podobne. Zaujímavá je taktiež myšlienka nájsť si maličkú farmičku, ktorá sa ledva drží na nohách (zväčša mimo EU/USA/Rusko) a kde je vidieť, že jej admini sú radi, že sú radi, nieto ešte aby uvažovali o nejakej bezpečnosti. Dalo by sa oťukať si ju, chvíľu z vnútra očuchávať a po ukradnutí osobných certifikátov používateľov sa rozliezť po celej sieti.
Ako vidno GRID a jeho časti sú dosť friendly a natŕčajú riť. Nie že by bezpečnosť jednotlivých služieb (česť výnimkám) nebola na dostatočnej úrovni, no platí, že silu reťaze určuje najslabšie ohnivko a v GRIDe je veľa vecí ktoré pokrivkávajú. Netvrdím, že je táto forma realizácie mohutného pomalého "paralelného/distribuovaného stroja" dobrá, ani že je zlá. Z hľadiska administrácie je to rozhodne jednoduchšie ako nejaká komplikovaná topológia firewallov, routerov, demilitarizovanej zóny a ja neviem ešte čoho všetkého. To samozrejme neznamená, že keď tie mašiny necháme len tak napospas osudu, že sa do nich skôr či neskôr niekto nezahryzne. Taktiež, vedecká obec bola, je a bude plná pacifistov a open-minded ľudí, ktorí chápu (predpokladajú), že spoločné úsilie a jeho výsledky sú tu pre všetkých a preto očakávajú, že sa neukojení teenageri budú zabávať pri niečom inom a nie pri obmedzovaní prevádzky tejto siete (aj keď teda konšpiračných teórií by sa dalo vymyslieť mnoho, od zneužitia CPU na lámanie hesiel až po úmyselné blokovanie výskumu a priemyselnú špionáž).
Celý projekt EGEE - aj keď už končí - sa podľa mňa ešte nerozdýchal a neukázal svoj plný potenciál. Bude to beh na dlhú trať a GRID sa ešte veľa krát rozkašle kým začne podávať solídne výkony (a fakticky pôjde k hraniciam svojich možností). Chýba mi v tom poriadok a celková snaha o stabilný beh a tunning. Zatiaľ mi to príde ako kopa kódu zlátaného na nohe, ktorá sa zo všetkou božou, pozemskou a pekelnou mocou ako tak drží nad vodou. Bez nejakej jasnej koncepcie alebo návrhu ktorého by sa vývojarí držali. A pri tom by GRID mohol dokázať oveľa viac.
Na záver by som ešte povedal pár myšlienok ohľadom bezpečnosti a stavu EGEE projektu v SR. Momentálne asi najhoršia vec, čo sa môže stať, je odcudzenie certifikátu (Rakúsko malo v tomto svoje skúsenosti). Kedže gLite beží na Scientific Linux-e čo je RHEL vec, tak všetky neduhy RedHatu Scientific Linux dedí a pridáva nejaké svoje navyše. Napríklad v septembri 2009 bežala veľká časť GRIDu na neopatchovanom jadre 2 tyždne (problém s niektorými modulmi a ešte niečim). Síce boli moduly vypnuté no vraj tam bol ešte jeden nezávislý problém, ktorý umožňoval eskaláciu práv. No a RedHat nebol schopný vydať nové jadro (Debian ho pre stable/testing vydal na druhy deň a pre unstable ho mal do týždňa). V prípade, že je centrum kompromitované, tak existuje postup ktorý musia admini/bezpečnostní technici urobiť, ktorý (ak ho poznajú a dodržujú), do 4 hodín od objavenia incidentu zmrazí centrum a do 24 ho vylúči z GRIDu. Zatiaľ boli ohlásené incidenty hlavne z Francúzka a Nemecka (veľké centrá).
No a v neposlednom rade (určite v SR, neviem ako inde) sa stane, že je administrátorom človek ktorý tomu nerozumie do hĺbky, prípadne si neuvedomuje závažnosť prieniku, alebo je mu to jedno. Keby nebolo first line support-u, tak si dovolím tvrdiť, že nechodí ani jedno centrum. (Touto formou ich zdravím a ďakujem za vynikajúcu pomoc) V každom prípade minimálne do novembra minulého roku za administráciu a budovanie niektorých centier ľudia platení neboli (takže to bolo také hranie sa popri práci ktorú mali robiť oficiálne a realita bola taká, že im administrácia, ktorá bola novou vecou bez dobrého manuálu zabrala podstatnú časť dňa). Napriek tomu vládne priateľská kolegialita medzi centrami a je snaha držať kvalitu služieb na vysokej úrovni. Pokiaľ však bude gLite a jeho konfiguračné nástroje také aké sú (človek musel ručne aplikovať aj 7 zmien na to aby mohol vôbec použiť nástroj na konfiguráciu služieb a aj to si nebol istý že to naozaj funguje), tak sa z toho nikto nikdy nevysomári.
V ČR je situácia o poznanie lepšia. Aj tie centrá vyzerajú trochu inak (kapacitne). Minimálne v Prahe majú veľké centrum, relatívne početnú skupinu ľudí, čo o tom aj niečo vedia (čiže nie že fyzik - študent, čo je rád, že si vie "naprogramovať" Hello World vo FORTRANe, alebo C++ sa ide starať o administráciu a bezpečnosť celého centra bez dokumentácie a bez pomoci) a sú dobre platení (v porovnaní so SR). Sú tuším zakladatelia VOCE - Virtual Organization for Central Europe, ktorú podporujú centrá celého regiónu strednej Európy. Vyvíjajú vlastný software na manažovanie a používanie programov z VOCE - Charon.
Ja neviem, ale na Slovensku sa to vždy spraví "inak" a potom to tak vyzerá.
Čakal som, že sa po GRIDe univerzity v SR vrhnú ako v Somálsku na chlieb, no nestalo sa. Čosi sa rieši (v rámci VOCE), ale pokiaľ je mi známe je to na úrovni diplomových prác , ale nie skutočná využiteľná veda (česť výnimkám), určite nie v množstve v akom by som to čakal (veď máme >10 univerzít. Ak má každá 5 fakúlt a každá fakulta 2 katedry, to by hneď mohlo byť 100 projektov ročne, no nie je) - takýto bol stav okolo roku 2006. Od vtedy sa ľady moc nepohli. Trávim administráciou centra už nejaký ten rok a vidím, že GRID naozaj potenciál má. Zatiaľ mi to však príde skôr ako pokus, než projekt s konkrétnymi cieľmi. Ako keby sa toho ľudia stále báli a neverili tomu. Aspoň na Slovensku. Uvidíme, čo prinesie budúcnosť.
Niektoré úlohy, riešené v rámci VOCE - 2nd Internation Workshop on Grid Computing for Complex Problems (ďalšie príklady možno nájsť v [10,11]):
Ako ochrániť svoje dáta pred neautorizovaným prístupom zo strany...vyššej moci? Vezmime si vzorový prípad: Mame niekde v datacentre uložený priemerný server. Chceme aby naše dáta v prípade zhabania neboli ohrozené, ale nemáme prostriedky na nepriestrelnú ochranu. Teda v ľubovoľný moment môže prísť vyššia moc, a server si fyzicky odniesť.
Základom je pochopiteľne šifrovanie disku, o tom sa asi baviť netreba, a každý ho už zvláda. Trochu menej bežné je šifrovanie celého disku, ktoré rozhodne odporúčam. Za predpokladu že nechceme k serveru pri každom probléme behať s usb kľúčom, alebo bootovať cez PXE, pravdepodobne necháme nešifrovaný iba /boot a FS budeme odomykať na diaľku cez dropbear.
Pár rokov dozadu by to bolo dostatočné riešenie. Ak by sa vyššia moc naozaj unúvala, server by bol ako prvé vypojený z elektriny a následne zbalený a odnesený. V dnešnej dobe sú ale v móde sexi krokodílky, napojené na UPSKU, ktoré sa pripichnú na napájací kábel. Server sa následne naloží na pojazdný vozík, a hybaj s ním do externej firmy. Vyššia moc si typicky nemôže dovoliť platiť drahých špecialistov, ale ak pracujú v externej spriaznenej firme, nie je s financiami problém. A chlapci majú potom dostatok času, aby nejak získali a následne analyzovali dump celej RAMky.
Dump je možné získať napr. pomocou firewire(ktoré ale asi na serveri nenájdeme), špeciálnej PCI karty (PCI/PCIE porty sú pomerne časté), hotbootom, alebo na istotu coldbootom [1].
Analýza získaného dumpu je tiež riešiteľný problém. Ak ideme po šifrovacích kľúčoch, k dispozícii sú napr. aes-keyfind a rsa-keyfind utilitky, ktoré dokážu nájsť v dumpe AES resp. RSA kľúče od prakticky ľubovolného programu. (pomocou rekonštrukcie tzv. key-schedule štruktúry) [1] Samotný kľúč by sa síce teoreticky dal schovať mimo RAM, napr. do CPU cache [viz. frozencache [2], prípadne TPM, ale citlivé dáta môžu byť často krát už v samotnom dumpe. V momente keď sa vyššej moci podarí získať dump RAMky, viac menej vyhrala.
Ak sa chceme brániť, musíme na to teda ísť proaktívne. V momente keď zdetekujeme narušiteľa, musíme RAMku čo najrýchlejšie vymazať. Prvý nápad je pravdepodobne vypnutie stroja. To ale nemusí stačiť, pretože v momente keď zabavujúci spozoruje vypnutie stroja, mohol by duchaprítomne vytasiť dusíkový sprej a prebehnúť nim RAM moduly. Ak náhodou nie duchaprítomne, mohol by na to byt školený, podobne ako na krokodílky.
To čo potrebujeme spraviť je: 1. Odmontovať čo ide, alebo to aspoň premontovať read-only. Zbytočne ale neblikať diskom, aby sme nedostali dusíkom:) 2. Natiahnuť čistiaci modul, ktorý vyčistí všetko čo môže a mašinu nechá v zombie stave.
Čo všetko by taký modul mal spraviť, aby si pod sebou neodrezal konár príliš skoro, a nenechal dáta v RAMke?
Najprv musí zistiť, na ktorých (fyzických) adresách je namapovaná samotná RAM. Keby sme začali zapisovať do namapovaných zariadení, mohli by sme dopadnúť nedobre.
V Linuxe to vieme elegantne zistiť z /proc/iomem
Napr.
[niekt0@server ~]$ cat /proc/iomem 00000000-00000fff : System RAM 00001000-00005fff : reserved 00006000-0009cfff : System RAM 0009d000-0009ffff : RAM buffer 00100000-bf698fff : System RAM 01000000-0133ceca : Kernel code 0133cecb-014f46af : Kernel data 01574000-0169f897 : Kernel bss bf699000-bf6aefff : reserved bf6af000-bf6cdfff : ACPI Tables bf6ce000-bfffffff : reserved d9800000-d9ffffff : PCI Bus 0000:03 d9800000-d9ffffff : 0000:03:03.0 ... fe000000-ffffffff : reserved fec00000-fec00fff : IOAPIC 0 fed00000-fed003ff : HPET 0 fed50000-fed53fff : pnp 00:0a fee00000-fee00fff : Local APIC 100000000-23fffffff : System RAMNás zaujímajú riadky s "System RAM" (resp. RAM buffer). V tomto konkrétnom prípade teda dostávame 4 rozsahy na zmazanie:
00000000-00000fff 00006000-0009cfff 00100000-bf698fff 100000000-23fffffff
Pri samotnom mazaní sa nemôžeme spoliehať na jadro, pretože jeho časti si môžeme odstreliť pod rukami. Dokonca sa nemôžeme spoľahnúť ani na prekladové tabuľky (virtual page table) ktoré potrebujeme na preklad z lineárnej na fyzickú adresu.
Preto si spravíme malý asmeblerový kód, ktorý vykoná samotné zmazanie, a bude pri tom používať vlastné minimalistické tabuľky. Namapovanie potrebnej stránky zabezpečíme ručnou úpravou našich tabuliek.
Moju implementáciu je možné nájsť na [3]. Úprava tabuliek za behu je tak trochu prasačina, ale funguje to v podstate podla popisu vyššie.
Zostáva nám ešte vyriešiť, na čo by sme mohli náš skript napichnúť. Celkom určite je dobrým nápadom event "cover opened", to aj spravíme, ale nie je to dostatočné. Ak by to dumpujúci predpokladal, senzor sa dá jednoducho oklamať. Dôležitejšie je napichnúť sa na stratu konektivity. Samozrejme, môžeme si napísať vlastný skript, s ľubovolnými timeotmi, ľubovolným spôsobom kontroly X serverov, aby sme predišli falošným poplachom. Zároveň, takú kontrolu pomocou ssh/ssl pripojení by nemalo byť možné emulovať. (za predpokladu že nebudeme používať štandardne certifikačné "autority":)
Technik ješterkov je teda postavený pred dve voľby: Nechať server zapojený, a riskovať že bude na diaľku vypnutý, resp. jeho dáta upravené. Alebo server okamžite odpojiť, a riskovať že na odpojenie je napichnutý skript, ktorý zmaže RAMku.
Alternatívne môže preventívne zmraziť RAMku, čo ale predstavuje väčšie nároky na jeho technickú zručnosť, a vyžaduje prítomnosť mobilného zariadenia na skopírovanie RAMky.
Pri súčasnom hw 100 percentné obranné riešenie neexistuje, jedine snáď podložiť si server EMP mínou;) Ale je možné forenznú analýzu značne skomplikovať.
Zaujímavá je otázka trvanlivosti dát v RAMke, po tom čo boli prepísané. Čerpajúc z [4], vyzerá to že istá možnosť rekonštrukcie tu je. Viacnásobné prepísanie nám pri mazaní ale pravdepodobne nepomôže. Našou snahou by malo byť nechať nové dáta uležať čo najdlhšie, teda stroj nereštartovať, ale niekde sa bezpečne zacykliť.
Popísaný modul je možné stiahnuť si z [3].
niekt0 (ryba) hysteria (bodka) sk
[1] http://citp.princeton.edu/memory/code/
Obfuskace kódu je oblíbenou technikou pro ztížení jeho analýzy nebo jeho rozpoznání na základě vzorů, což dnes hojně využívá například malware nebo softwarové protektory spustitelných souborů.
Obfuskací kódu (angl. code obfuscation) se obecně označuje technika pro přetvoření kódu (i zdrojového) do formy těžko pochopitelné člověkem, ale i nějakým programem. V tomto kontextu ale půjde jenom o "rozbití" existujícího strojového x86 kódu, i když obfuskátory asemblerovských zdrojáků (za účelem obfuskovaného výsledného strojáku) existují taky (třeba PELock obfuscator). Anglicky se tomu občas říká i code morphing. Nebudeme se tedy zabývat generací úplně nového kódu např. na základě nějakých abstraktních vzorů.
Napsat i jednoduchý obfuskátor strojáku není úplně triviální záležitost, protože na začátku vyžaduje pokročilejší, alespoň statický disassembler, který nějak popíše vstupní instrukce, a na konci reasembler, který celý kód opraví a znovu sestaví do funkční podoby. K tomu, aby bylo možné kód bezpečně automaticky obfuskovat, musí být splněna řada podmínek (např. je potřeba najít všechna návěští v kódu, které musí být možné nakonec opravit). Už to je problém sám pro sebe, který navíc nemusí být řešitelný (viz Halting problem). Řeší se tak, že kód, který má být obfuskovaný, musí být už předem připraven, třeba tak, že obsahuje zvláštní nápovědu pro obfuskátor. To je ale téma na zvláštní článek.
K pochopení celého procesu a jednotlivých metod, jak kód "zamlžit", pomůže pohled do historie vývoje obfuskátorů, který prudce probíhal a dal se sledovat u vývoje klasických virů, napadajících spustitelné soubory. V tomto smyslu se často mluví o metamorfismu (angl. metamorphism), protože virus vlastně obfuskuje sama sebe.
Jedním z nejznámějších průkopníků metamorfních virů byl Z0MBiE. Popsal třeba podmínky, za kterých je možné bezpečně prohazovat instrukce, což je jedna z důležitých metod, jak se zbavit jak konstantních vzorů v kódu, tak ztížit pochopení algoritmu. Zmiňuje tuto posloupnost instrukcí:
[A] add eax, ecx [B] adc eax, edx [C] add ebx, ecx [D] adc ebx, edx
Instrukce B závisí na A
(ADC testuje příznak CF nastavený instrukcí
ADD) a instrukce
D závisí na C. Současně
C nezávisí na A ani na
B, proto je lze prohodit (níž jsou další příklady):
[C] add ebx, ecx [D] adc ebx, edx [A] add eax, ecx [B] adc eax, edx
Aby mohl s kódem manipulovat, vytvořil XDE, eXtended Disassembler Engine, který je založen na ADE, který umožňuje počáteční disasembling a konečný zpětný asembling, což je jedna z nutností popsáných výše.
Metamorfismus později pěkně popsal Mental Driller.
Zmiňuje celý
proces, kterým musí kód projít, aby ho šlo modifikovat a aby
byl na konci stále funkční. Zmiňuje další důležitou techniku, rozložení
instrukce na více jiných, ale se stejným výsledkem, konkrétně
PUSH REG na (níž jsou další ukázky):
push reg ; původní instrukce, např. push eax -> mov [mem], reg ; předem připravená dočasná paměť push [mem]
Do (automatické) analýzy takového kódu je potom navíc potřeba zahrnout nový odkaz do paměti, což ji zpomaluje a komplikuje.
Zatím byly zmíněny dvě metody obfuskace: Prohazování instrukcí (to zahrnuje i celé bloky instrukcí) a jejich rozklad. Dá se říct, že tyto jsou ty nejdůležitější, protože využívají pouze původních instrukcí a kvůli jejich komplikovanosti není lehké navrátit kód do původního stavu.
Další metoda, jejíž podstatou není přidávání nových
instrukcí, je změna toku řízení (angl. control-flow-graph
mutation). Jde prostě o "vytržení" kusu kódu, jeho přemístění
a slinkování s původním kódem pomocí instrukcí JMP:
; původní kód mov al, [ebx] inc ebx ; tato instrukce bude přesunuta sub al, 32 ; obfuskovaný kód mov al, [ebx] jmp get_over get_back: sub al, 32 jmp skip ; přeskoč přesunutou instrukci get_over: inc ebx jmp get_back ; vrať se na původní místo skip:
Za splnění dalších podmínek lze využít i instrukce
CALL-RET a tím vlastně vytvořit falešnou proceduru:
mov al, [ebx] call get_over sub al, 32 jmp skip get_over: inc ebx ret skip:
Další metody už přidávají nové instrukce:
Jde o přidávání nadbytečných skoků:
; původní kód mov al, [ebx] inc ebx sub al, 32 ; obfuskovaný kód mov al, [ebx] jc bebacksoon ; falešný skok, který se možná neprovede, nezáleží na tom get_back: inc ebx sub al, 32 jmp skip ; přeskoč přidaný skok zpět bebacksoon: jmp get_back ; pouze návrat na původní místo skip:
Nebo "zřetězení" existujícího skoku za účelem zakrytí skutečné cílové adresy:
; původní kód get_null: mov al, [ebx] inc ebx cmp al, 0 jne get_null ; obfuskovaný kód get_null: mov al, [ebx] jmp skip ; přeskoč přidaný skok na get_null xget_null: jmp get_null skip: inc ebx cmp al, 0 jne xget_null ; zřetězení s meziskokem
Nebo vytvoření skoku do instrukce, což dokáže zmást ty
disasemblery, které nedokáží disasemblovat na návěští
skoku, které je uvnitř už dříve disasemblované instrukce. Přidáme
např. operační kód B8, který vytvoří instrukci
MOV EAX, původní_4_bajty. Dál přidáme instrukci
skoku, která zajistí, že se spustí skutečná původní instrukce (ve
sloupci vlevo je strojový kód instrukcí):
; původní kód 8A83 00010000 mov al, [ebx+100] ; obfuskovaný kód EB 01 jmp $+3 ; přeskoč přidaný bajt 0xB8 B8 8A830001 mov eax, 100838A ; 8A, 83, 00, 01 = 4 bajty z původního kódu 0000 add [eax], al ; 0000 = zbývající 2 bajty ; jinak zapsáno EB 01 jmp skip B8 db 0B8 skip: 8A83 00010000 mov al, [ebx+100]
Takže jsme vlastně přidali jenom 3 bajty EB,
01, B8 před původní instrukci.
Pro zpomalení jak automatické analýzy (emulátoru), tak ručního prohledávání kódu obfuskátory vkládají kód, jenž ve výsledku nemá žádný význam. Třeba Z0MBiE proto vytvořil Executable Trash Generator, který měl za úkol zpomalit antivirové emulátory vytvořením spousty nicnedělajícího kódu, vloženého mezi dekryptor a samotný kód viru.
Takovým nicnedělajícím kódem může být třeba následující funkce, volaná z náhodně vybraných míst původního kódu:
do_nothing: push ebp mov ebp, esp ; simuluj vytvoření stack frame push ecx mov ecx, 0 ; nastav na nula, takže repe cmpsw ; REPE se neprovede ani jednou pop ecx pop ebp ; uvolni stack retn
Dál se dá uvažovat například o vkládání méně známých NOP
instrukcí jako FNENI nebo FNDISI a dalších
metodách.
Pro ilustraci všech uvedených metod budeme krok za krokem obfuskovat jednoduchou implementaci funkce strcpy ze standardní knihovny:
strcpy: push ebp mov ebp, esp ; parametry adresuj přes EBP mov edx, [ebp+08] ; zapamatuj si parametr r pro výstup mov esi, [ebp+0C] ; zdrojový řetězec cs mov edi, [ebp+08] ; cílový řetězec r copy: mov al, [esi] mov [edi], al ; kopíruj bajt po bajtu inc esi inc edi ; posuň ukazatele cmp al, 0 ; konec řetězce? jne copy mov eax, edx ; vrať r pop ebp ; obnov EBP ret
Začneme rozkladem instrukcí, který nám zvýší počet instrukcí pro aplikaci ostatních metod.
push ebp - interně jde o dvě operace: snížení
ESP o 4 bajty a vložení EBP na
[ESP]. Toho využijeme, ale celou operaci ještě víc
zamotáme. Nejdřív provedeme push náhodně vybrané
konstanty, kterou potom přepíšeme registrem EBP:
push ebp -> push 0F4DCE10 mov [esp], ebp
mov ebp, esp - použijeme rozklad, který nejprve
dočasně modifikuje zdrojový registr ESP náhodně vybraným
registrem, vloží ho do EBP a potom opraví oba registry na
správné hodnoty. Poznámka: předpokládáme, že kód běží v user mode, kde
můžeme dočasně narušit hodnotu ESP.
mov ebp, esp -> sub esp, ebx mov ebp, esp add ebp, ebx add esp, ebx
mov edx, [ebp+08] a následující podobné
instrukce: pokud nemá obfuskátor informaci o tom, že zdrojová paměť je
zapisovatelná (jde o stack), nemůže použít řadu rozkladů, které
nejprve nějak modifikují zdrojovou paměť. Pořád ale existuje několik
možností, konkrétně využijeme možnosti postupného plnění registru
EDX:
mov edx, [ebp+08] -> mov dx, [ebp+0A] ; vyšší WORD shl edx, 10 ; do vyššího WORD EDX mov dh, [ebp+09] mov dl, [ebp+08]
Instrukce SHL na rozdíl od původního MOV,
který rozkládáme, sice přepíše příznaky (jako CF,
ZF atd.), ale obfuskátor dokáže analýzou zjistit, že
příznaky lze přepsat, protože na nich žádná z následujících instrukcí
nezávisí (nenásleduje např. instrukce ADC nebo
JZ).
mov esi, [ebp+0C] - použijeme třeba jednoduchý
push-pop rozklad:
mov esi, [ebp+0C] -> push dword [ebp+0C] pop esi
mov edi, [ebp+08] - můžeme použít např. načtení
adresy do náhodně vybraného registru (který si nejprve uložíme
a potom zase obnovíme):
mov edi, [ebp+08] -> push edx lea edx, [ebp+08] mov edi, [edx] pop edx
mov al, [esi] - obfuskátor může využít faktu,
že nakonec je celý EAX přepsán, takže nezáleží na původní
hodnotě v AH:
mov al, [esi] -> mov ah, [esi] xchg ah, al
mov [edi], al - pro vytvoření iluze závislosti
na předchozí hodnotě [EDI] ji nejdřív nastavíme na
konkrétní hodnotu:
mov [edi], al -> mov byte [edi], 5F xor [edi], al xor byte [edi], 5F
inc esi - pro ztížení analýzy použijeme konstantu ze
systémového registru, konkrétně CR0, jehož spodních 16
bitů (registr MSW) můžeme na libovolné úrovni oprávnění
číst instrukcí SMSW. Využijeme faktu, že bit 0 (Protection
Enable) je v chráněném módu vždy nastaven (MSW načteme do
náhodně vybraného registru, který napřed uložíme):
inc esi -> push ebp smsw bp and ebp, 1 add esi, ebp pop ebp
inc edi - operaci zakryjeme odečtením náhodně
vybraného registru a jeho opětovným přičtením pomocí ADC
s nastaveným CF:
inc edi -> sub edi, eax stc adc edi, eax
cmp al, 0 - nevýhoda instrukce CMP
je, že nezapisuje do cílového operandu, na rozdíl od
SUB, takže není tolik možností, jak rozkládat. V tomto
případě ale dokáže obfuskátor zjistit, že hodnota AL je ve
všech možných větvých kódu nakonec přepsána (na návěští
copy je instrukce MOV AL a dál v kódu
zase MOV EAX), takže AL může být před
testováním nějak upraven, aby konstanta (0) nebyla tak
viditelná. Zase využijeme náhodně vybraný registr:
cmp al, 0 -> add al, ch cmp al, ch
jne copy - JNE skočí na návěští, pokud
není nastaven ZF. Protože ale předchází aritmetická
instrukce CMP, můžeme výsledek testovat na
vyšší nebo nižší pomocí dvou instrukcí JA
a JB. A ještě to vylepšíme inverzí na JNB
a pomocným skokem:
jne copy -> ja copy jnb finished jmp copy finished:
mov eax, edx - budeme předpokládat, že
obfuskátor ví (např. díky tomu, že zná volací konvenci této funkce),
že může přepsat příznaky i registr EDX (jde o volatile
registr). Potom jde tato instrukce rozložit třeba na:
mov eax, edx -> xor eax, edx xor edx, eax xor eax, edx
pop ebp - POP nejdřív vloží hodnotu do
EBP a potom přičte k ESP 4 bajty. Samotné
přičtení provedeme malým trikem pro pobavení.
pop ebp -> mov ebp, [esp] pop dword [esp+4]
ret - znovu předpokládáme, že obfuskátor zná volací
konvenci a tudíž ví, že registry EAX, ECX
a EDX může přepsat, a proto jde RET nahradit
následující sekvencí.
ret -> pop ecx jmp ecx
Celá funkce vypadá v tuto chvíli takto:
strcpy: push 0F4DCE10 ; push ebp mov [esp], ebp sub esp, ebx ; mov ebp, esp mov ebp, esp add ebp, ebx add esp, ebx mov dx, [ebp+0A] ; mov edx, [ebp+08] shl edx, 10 mov dh, [ebp+09] mov dl, [ebp+08] push dword [ebp+0C]; mov esi, [ebp+0C] pop esi push edx ; mov edi, [ebp+08] lea edx, [ebp+08] mov edi, [edx] pop edx copy: mov ah, [esi] ; mov al, [esi] xchg ah, al mov byte [edi], 5F ; mov [edi], al xor [edi], al xor byte [edi], 5F push ebp ; inc esi smsw bp and ebp, 1 add esi, ebp pop ebp sub edi, eax ; inc edi stc adc edi, eax add al, ch ; cmp al, 0 cmp al, ch ja copy ; jne copy jnb finished jmp copy finished: xor eax, edx ; mov eax, edx xor edx, eax xor eax, edx mov ebp, [esp] ; pop ebp pop dword [esp+4] pop ecx ; ret jmp ecx
Pro zjednodušení se pokusíme prohazovat pouze sousedící instrukce, ne celé bloky instrukcí:
strcpy: push 0F4DCE10 A) mov [esp], ebp B) sub esp, ebx mov ebp, esp add ebp, ebx add esp, ebx
Tyto nejde prohodit, protože A zapisuje na paměť
adresovanou ESP a současně B mění
ESP.
B) sub esp, ebx mov ebp, esp add ebp, ebx C) add esp, ebx D) mov dx, [ebp+0A] D) shl edx, 10 mov dh, [ebp+09] mov dl, [ebp+08]
Tyto (C a D) prohodit jde, protože žádný z operandů instrukcí se nepřekrývá:
sub esp, ebx mov ebp, esp add ebp, ebx D) mov dx, [ebp+0A] D) shl edx, 10 C) add esp, ebx mov dh, [ebp+09] E) mov dl, [ebp+08] F) push dword [ebp+0C] ; původně mov esi, [ebp+0C] pop esi
Protože předpokládáme, že vrchol zásobníku (ESP)
nekoliduje s ebp+08 ani s ebp+0C (jinak
bysme nemohli rozložit původní MOV
z [ebp+OC] na PUSH), instrukce můžeme
prohodit:
mov dh, [ebp+09] F) push dword [ebp+0C] E) mov dl, [ebp+08] G) pop esi H) push edx lea edx, [ebp+08] mov edi, [edx] pop edx
Instrukce G a H prohodit nejde, protože obě manipulují se zásobníkem.
push edx lea edx, [ebp+08] mov edi, [edx] I) pop edx copy: J) mov ah, [esi] xchg ah, al
Instrukce I a J zase prohodit nejde, protože je mezi nimi návěští
skoku. Jinými slovy, POP EDX se nemůže stát součástí
copy smyčky, nebo MOV AH z ní nemůže
vypadnout.
mov ah, [esi] K) xchg ah, al L) mov byte [edi], 5F xor [edi], al xor byte [edi], 5F
Přehodit K a L je možné, žádné z operandů instrukcí spolu nekolidují:
mov ah, [esi] L) mov byte [edi], 5F K) xchg ah, al xor [edi], al M) xor byte [edi], 5F N) push ebp N) smsw bp and ebp, 1 add esi, ebp pop ebp
Přehodit M a N je zase možné. XOR sice na rozdíl od
PUSH a SMSW přepisuje příznaky, ale žádná
z následujících instrukcí na nich nezávisí.
xor [edi], al N) push ebp N) smsw bp M) xor byte [edi], 5F and ebp, 1 add esi, ebp O) pop ebp P) sub edi, eax P) stc adc edi, eax
Instrukce O a P spolu prohodit
můžeme, protože POP nemění příznaky (ADC
závisí na příznaku CF):
M) xor byte [edi], 5F and ebp, 1 add esi, ebp P) sub edi, eax P) stc O) pop ebp Q) adc edi, eax R) add al, ch cmp al, ch
Naopak instrukce Q a R nejde
prohodit, protože ADD by změnila CF.
add al, ch S) cmp al, ch T) ja copy T) jnb finished T) jmp copy finished: U) xor eax, edx xor edx, eax xor eax, edx
Žádnou z instrukcí S, T a U přehodit nejde, protože instrukce T mění řízení a navíc mezi T a U je návěští, přes které nelze nikdy instrukce přehazovat.
xor eax, edx xor edx, eax V) xor eax, edx W) mov ebp, [esp] W) pop dword [esp+4]
Instrukce V a W žádné z operandů nesdílejí, takže je prohodíme.
xor eax, edx xor edx, eax W) mov ebp, [esp] W) pop dword [esp+4] V) xor eax, edx X) pop ecx jmp ecx
Instrukce V a X spolu také můžeme ze stejného důvodu prohodit:
W) mov ebp, [esp] W) pop dword [esp+4] X) pop ecx V) xor eax, edx jmp ecx
A poslední instrukce JMP je zase neprohoditelná.
A už to začíná vypadat pěkně:
strcpy: push 0F4DCE10 mov [esp], ebp sub esp, ebx mov ebp, esp add ebp, ebx mov dx, [ebp+0A] shl edx, 10 add esp, ebx mov dh, [ebp+09] push dword [ebp+0C] mov dl, [ebp+08] pop esi push edx lea edx, [ebp+08] mov edi, [edx] pop edx copy: mov ah, [esi] mov byte [edi], 5F xchg ah, al xor [edi], al push ebp smsw bp xor byte [edi], 5F and ebp, 1 add esi, ebp sub edi, eax stc pop ebp adc edi, eax add al, ch cmp al, ch ja copy jnb finished jmp copy finished: xor eax, edx xor edx, eax mov ebp, [esp] pop dword [esp+4] pop ecx xor eax, edx jmp ecx
Obfuskátor náhodně vybere části kódu pro přesun. S použitím
instrukcí JMP nebývá problém, v případě instrukcí
závisejících na zásobníku nesmí být pro přesun použita instrukce
CALL, která vkládá na zásobník návratovou
adresu. Je vidět, že došlo k docela slušné fragmentaci kódu:
strcpy: push 0F4DCE10 jmp moved1 ; instrukce mov [esp], ebp až back1: ; mov dx, [ebp+0A] přemístěny shl edx, 10 add esp, ebx mov dh, [ebp+09] push dword [ebp+0C] mov dl, [ebp+08] jmp skip_moved2 ; vytvoř prostor pro přemístěný kód moved2: smsw bp xor byte [edi], 5F and ebp, 1 add esi, ebp sub edi, eax stc retn skip_moved2: pop esi push edx lea edx, [ebp+08] mov edi, [edx] pop edx copy: mov ah, [esi] mov byte [edi], 5F xchg ah, al xor [edi], al push ebp call moved2 ; smsw bp až stc pop ebp adc edi, eax add al, ch cmp al, ch jmp moved3 ; instrukce ja copy a jnb finished back3: jmp copy moved1: ; za původní "jmp copy" šlo bezpečně vložit kód mov [esp], ebp sub esp, ebx mov ebp, esp add ebp, ebx mov dx, [ebp+0A] jmp back1 finished: xor eax, edx xor edx, eax jmp skip_moved3 ; vytvoř prostor pro přemístěný kód moved3: ja copy jnb finished jmp back3 skip_moved3: mov ebp, [esp] pop dword [esp+4] pop ecx xor eax, edx jmp ecx
Obfuskátor přidá jeden nadbytečný podmíněný skok
JNC, dva skoky (CALL a JMP)
zřetězí a vytvoří několik skoků do instrukce.
Pro prohlížení skoků do instrukce v debuggeru může být potřeba vypnout analýzu, která je odhalí a kód zobrazí správně.
strcpy: jmp skip_new_byte db 0B8 ; vytvoří falešnou instrukci MOV EAX, xxxxxxxx skip_new_byte: ; (pohltí následující čtyři bajty) push 0F4DCE10 jmp moved1 bebacksoon: ; za nový "jmp moved1" šlo bezpečně vložit kód jmp goingback back1: shl edx, 10 add esp, ebx jmp skip_moved2_chain ; vytvoř prostor pro meziskok moved2_chain: jmp moved2 ; meziskok skip_moved2_chain: mov dh, [ebp+09] push dword [ebp+0C] mov dl, [ebp+08] jmp skip_moved2 moved2: smsw bp xor byte [edi], 5F and ebp, 1 add esi, ebp jnc bebacksoon ; vložený podmíněný skok goingback: ; (někdy se provede, někdy ne, nezáleží na tom) sub edi, eax stc retn skip_moved2: pop esi push edx jmp skip_new_word db 05, 12 ; vytvoří falešnou instrukci ADD EAX, xxxxxx12 skip_new_word: ; (pohltí následující tři bajty) lea edx, [ebp+08] mov edi, [edx] pop edx copy: mov ah, [esi] mov byte [edi], 5F xchg ah, al xor [edi], al push ebp ; call moved2 ; zřetězení skoku call moved2_chain pop ebp adc edi, eax add al, ch cmp al, ch jmp moved3 back3: ; jmp copy ; zřetězení skoku jmp copy_chain moved1: mov [esp], ebp sub esp, ebx jmp skip_new_dword db 66, 81, 34, 9C ; vytvoří falešnou instrukci XOR WORD [ESP+EBX*4], xxxx skip_new_dword: ; (pohltí následující dva bajty) mov ebp, esp add ebp, ebx mov dx, [ebp+0A] jmp back1 finished: xor eax, edx xor edx, eax jmp skip_moved3 moved3: ja copy jnb finished jmp back3 copy_chain: ; za nový "jmp back3" šlo bezpečně vložit meziskok jmp copy skip_moved3: mov ebp, [esp] pop dword [esp+4] pop ecx xor eax, edx jmp ecx
Nakonec obfuskátor vloží nicnedělající
kód. Použijeme falešnou proceduru zmíněnou výše, která bude vložená
na náhodně určené místo a náhodně volaná. Ještě ji ale vylepšíme
tím, že bude jakoby přijímat jeden parametr (který se předává přes
zásobník pomocí PUSH). Tím bude náhodně zvolená hodnota
nebo registr.
strcpy: jmp skip_new_byte db 0B8 skip_new_byte: push 0F4DCE10 push edx ; náhodný parametr call do_nothing_2 ; volání falešné funkce jmp moved1 bebacksoon: jmp goingback back1: shl edx, 10 add esp, ebx jmp skip_moved2_chain moved2_chain: jmp moved2 skip_moved2_chain: mov dh, [ebp+09] push dword [ebp+0C] mov dl, [ebp+08] jmp skip_moved2 ; za nový "jmp skip_moved2" šlo bezpečně vložit falešnou funkci do_nothing_2: push ebp mov ebp, esp ; simuluj vytvoření stack frame push ecx mov ecx, 0 ; nastav na nula, takže repe cmpsw ; REPE se neprovede ani jednou pop ecx pop ebp ; uvolni stack retn 4 ; odstraň vstupní DWORD parametr moved2: smsw bp xor byte [edi], 5F and ebp, 1 add esi, ebp jnc bebacksoon push 1E3D22 ; náhodný parametr call do_nothing_2 ; volání falešné funkce goingback: sub edi, eax stc retn skip_moved2: pop esi push edx jmp skip_new_word db 05, 12 skip_new_word: lea edx, [ebp+08] mov edi, [edx] pop edx copy: mov ah, [esi] mov byte [edi], 5F xchg ah, al xor [edi], al push ebp call moved2_chain pop ebp adc edi, eax add al, ch cmp al, ch jmp moved3 back3: jmp copy_chain moved1: mov [esp], ebp sub esp, ebx jmp skip_new_dword db 66, 81, 34, 9C skip_new_dword: mov ebp, esp add ebp, ebx mov dx, [ebp+0A] jmp back1 finished: xor eax, edx push ebp ; náhodný parametr call do_nothing_2 ; volání falešné funkce xor edx, eax jmp skip_moved3 moved3: ja copy jnb finished jmp back3 copy_chain: jmp copy skip_moved3: mov ebp, [esp] pop dword [esp+4] push 80001 ; náhodný parametr call do_nothing_2 ; volání falešné funkce pop ecx xor eax, edx jmp ecx
Zdrojáky ve flat assembler syntaxi
a spustitelné soubory pro Windows i Linux jsou tady. Program nemá
pro zjednodušení žádný výstup, takže je potřeba ho natáhnout do
debuggeru. Pro ověření správného výstupu stačí provést step
over první instrukci CALL a podívat se do dat,
jestli se překopírování povedlo.
strcpy_orig_win.asm, strcpy_orig_win.exe
strcpy_obfus_win.asm, strcpy_obfus_win.exe
strcpy_orig_nix.asm, strcpy_orig_nix
strcpy_obfus_nix.asm, strcpy_obfus_nix
fasm můžete stáhnout tady. Překlad přímo do spustitelné podoby jde prostě přes fasm source.asm.
Spousta metod obfuskace, které jde také automaticky provádět, nebyla zmíněna. Jde třeba o samomodifikující se kód (SMC), kdy kód sám vytváří následující instrukce, takže je téměř nemožné je zjistit statickou analýzou kódu:
; původní kód 8BC3 mov eax, ebx smc_me: 03C1 add eax, ecx ; SMC zajistí přidání instrukce ADD dynamicky: 8BC3 mov eax, ebx 66C705xxxxxxxx mov word [smc_me], 0C103 EB00 jmp $+2 smc_me: 0401 add al, 1 ; falešná instrukce, která bude přepsána
Skok jmp $+2 na následující
instrukci zajistí, že dojde ke znovunačtení kódu do cache procesoru,
jinak by skutečně mohlo dojít ke spuštění původní instrukce
add al, 1.
Další zajímavou cestou pro zabránění statické analýzy je dynamická alokace paměti pro proměnné. V kapitole o prohazování instrukcí není zmíněno prohazování celých nezávislých bloků instrukcí, jako třeba prohození dvou funkcí.
Další oblíbenou a dnes často používanou ochranou kódu na úrovni instrukcí je tenký virtuální stroj. Představit si ho jde tak, že instrukce nejsou vykonávány přímo, ale vykonává je emulátor. Aby ale nebylo možné snadno získat a analyzovat původní kód, který emulátor spouští, tak jsou vstupní instrukce ve formátu x86 převedeny do virtuálního formátu, který zná jenom emulátor. Pro zjištění formátu instrukcí je potom potřeba analyzovat samotný emulátor. V kombinaci s obfuskací a proměnlivým formátem instrukcí jde o docela slušnou ochranu proti analýze. Virtualizace je ale téma na samostatný článek.
Jak je vidět, kromě prohazování instrukcí přidávají metody obfuskace spoustu instrukcí. Jak je to ale potom s rychlostí kódu? Na dnešních procesorech, na rozdíl od nějakého 80386, už nehraje samotný počet instrukcí takovou roli, snad jedině ve smyčkách, vykonávaných v řádu miliónů. Důležitějším faktorem je, jak program zachází s datovou cache procesoru, a to obfuskace většinou neovliňuje.
Pokud jste zkoušeli volání obfuskované funkce v debuggeru, určitě jste si všimli, že k určení, co vlastně dělá, není potřeba studovat kód, stačí sledovat paměť (analyzovat data). Obfuskace instrukcí není všemocná právě proto, že pracuje jenom na úrovni instrukcí. Jinak řečeno, v první řadě to musí být design, který je těžké analyzovat, obfuskace je až doplňující prvek.
Ideální by bylo mít nástroj, který pochopí, co vstupní kód dělá, a ten stejný algoritmus vygeneruje jednou z mnoha (tisíc, miliónů) možných cest. Implementovat ale něco takového je prakticky nemožné. Zajímavou cestou, jak se k tomu trochu přiblížit, je poskytnout obfuskátoru nějaké abstraktní vzory namísto konkrétního kódu, který by obfuskátor už generoval sám. Toto by ale bylo téma na jiný článek, protože jde o samostatnou metodu.
MazeGen, mazegen (ryba) gmail (.bodka.) com
návrat na obsah
čo ty na to ? diskusia
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.
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".
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.
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ú.
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.
vid, vid512 (ryba) gmail (.bodka.) com
návrat na obsah
čo ty na to ? diskusia