Zaščita pred zaganjanjem tujih aplikacij na Xbox 360 končno premagana

Šest let po izidu, po 55 milijonih prodanih enot in eni strojni reviziji je zaščita na Xbox 360, ki preprečuje zaganjanje nepodpisanih programov na tej konzoli, končno klecnila pod napadi dveh hekerjev, ki sta poznana pod vzdevkoma GliGli in Tiros.

Xbox 360 namreč vključuje zaščito, ki zahteva, da so vsi programi (vključno z jedrom operacijskega sistema ter firmwarom) podpisani z Microsoftovimi privatnimi ključi. Ti ključi niso nikoli zapustili Microsofta in tako vse do sedaj (z izjemo kratkotrajne ranljivosti v preteklosti) na tej konzoli ni bilo mogoče poganjati nobene t.i. homebrew programske opreme.

Zagon konzole namreč poteka v naslednjih korakih:

1. Prvi zaganjalnik (boot-loader), ki je shranjen v ROM-u na samem centralnem Xenon procesorju, dekriptira, preveri podpis in naloži drugi zaganjalnik, ki je shranjen v programabilnem NAND čipu


2. Drugi zaganjalnik (CB) inicializira strojno podporo šifriranja v centralnem procesorju, inicializira glavni DRAM konzole ter dekriptira, preveri in naloži naslednji zaganjalnik


3. Tretji zaganjalnik (CD) zatem naloži jedro operacijskega sistema (kernel) ter hipervizorja (Hypervisor), ter po znani zgodbi dešifrira, naloži in požene zadnjo stopnjo


4. Četrti zaganjalnik (CF) naloži še popravke za jedro in hipervizor, požene hipervizor, znotraj le-tega pa se zatem požene jedro operacijskega sistema, ki naloži Dashboard vmesnik

Vse stopnje za zaščito uporabljajo simetrično šifriranje, po navedbah najverjetneje algoritem RC4, vsaka stopnja pa je podpisana z RSA/SHA1-HMAC algoritmom. Za generiranje naključnih števil skrbi strojni generator naključnih števil v procesorju, kar zapre tudi to možnost napada na kriptoalgoritme. Ker je prva stopnja shranjena v ROM-u direktno v trojedrnem centralnem procesorju, Microsoftovi privatni ključi pa niso nikoli zapustili podjetja, je to zadnjih šest let preprečevalo zaganjanje kode, ki ni bila odobrena in podpisana s strani Microsofta.
Izjema je sta bili jedri z verzijama 4532 in 4538, kjer je luknja v hipervizorju omogočila zagon poljubne kode. Tu pa je prišla v poštev še dodatna zaščita: pri vsaki nadgradnji firmwara konzole se uniči ena izmed eFuse varovalk znotraj procesorja. Ker vsako jedro preverja, če je na voljo pravo število teh varovalk, to prepreči nalaganje starejših verzij (downgrade) jedra in programske opreme. Posledično sta ti dve različici jeder omejeni na konzole, izdelane pred koncem januarja 2007, ki niso bile nikoli posodobljene - kar je dandanes izjemna redkost. V novih revizijah nalagalnika CB in CD takoj ustavita zagon, če prepoznata podpis teh dveh različic.

Ta kombinacija zaščite je zadnjih 6 let preprečevala resne posege v delovanje programske opreme v konzoli (v tem so izvzete vse modifikacije firmwara DVD pogonov, ki so bile namenjene izključno poganjanju piratskih iger), sta pa sedaj GliGli in Tiros končno našla napako v strojni opremi, ki to zaščito onemogoči.

Krivec za napako je Xboxov 3.2GHz trojedrni centralni procesor Xenon, ki se v določenih pogojih ne obnaša po specifikaciji. Hekerja sta ugotovila, da se procesor pri znižani frekvenci pri signalu CPU_RESET ne resetira, temveč sproži napako v delovanju, zaradi katere funkcija memcmp vedno vrne 0. S funkcijo memcmp vse stopnje nalagalnika preverjajo, če se podpisi naslednje stopnje ujemajo s shranjenimi hashi. Vrednost 0 pomeni ujemanje, posledično v tem primeru nalagalnik sprejme poljubno kodo na naslednji stopnji.

To samo po sebi ne bi bilo dovolj - procesor je treba še vseeno upočasniti. Tako sta ugotovila, da pri starejši (bajsi) reviziji pravi signal na povezavi CPU_PLL_BYPASS upočasni procesor pri zagonu na vsega 66.6 MHz, kar je dovolj za izvedbo napada. Napad trenutno ni zanesljiv in pogosto je potrebnih več ponovnih zagonov konzole da uspe. Avtorja trdita, da se te revizije v povprečju poženejo v pol minute.

Stvari se pa zakomplicirajo pri novi (Slim) reviziji konzole, ki ima GPU in CPU na enem samem čipu in mu za to manjka CPU_PLL_BYPASS nožica. Vse ni izgubljeno, hekerja sta ugotovila, da ima HANA čip na matični plošči (HANA skrbi za upscaling slike iz ločljivosti na izhodu grafičnega procesorja na ločljivost potrebno na izhodu) I2C dostop do centralnega procesorja in lahko nadzoruje frekvenco CPUja. Tako uporabita pri zagonu HANA čip da s signalom čez I2C upočasni procesor, pošljeta CPU_RESET in potem HANA obnovi polno frekvenco CPUja.
Vseeno pa ta napad ni tako zanesljiv kot pri starih revizijah konzole in traja zagon konzole dlje, preteče lahko tudi nekaj minut resetiranja, preden je napad uspešen.

Kaj to pomeni za prihodnost konzole? Narava napada je takšna, da ga na trenutnih revizijah strojne opreme ni moč popraviti samo s programskim popravkom. Poraja se vprašanje, ali bo Microsoft zaradi tega primera porabil denar za novo revizijo strojne opreme brez teh pomanjkljivosti (kar ne bo trivialno ali poceni), ali bodo raje se bolje osredotočali na naslednika, ki je že gotovo na poti.
Trenutno namreč napad zahteva dokaj hitro in natančno strojno opremo in tudi po izboljšavah bo zahteval resen poseg v strojno opremo konzole, ki bo gotovo uničil garancijo.

Podrobnejše poročilo o podvigu z videom je na boljo na LibXenon forumu

So pa za razliko od Sonya vsaj uporabili strojni generator naključnih števil namesto Debianovega.