Puščanje Microsoftovega "zlatega ključa" omogoča onemogočanje varnega zagona

Nedavno uhajanje Microsoftovega "zlatega ključa" skupaj s prisotnostjo načina za odpravljanje napak je omogočilo onemogočanje varnega zagona v napravah Windows. Beri naprej!

Operacijski sistemi Windows niso več privzeta in najboljša izbira na mobilnem prizorišču. Odprtokodna narava Androida je našla veliko oboževalcev pri proizvajalcih originalne opreme, zato dandanes vse manj telefonov uporablja Windows.

Če pa ste med tistimi, ki v vsakdanjem življenju še vedno uporabljajo napravo Windows, je za vas nekaj novic. Dobro ali slabo, odvisno od vašega stališča in interpretacije primerov uporabe te novice.

Kot poroča Ars Technica in TheRegister z novico, ki izvira iz a spletno mesto, ki vam bo verjetno povzročilo glavobol (ne hecam se), nekaj razvijalcev (@never_released in @TheWack0lian) so ugotovili, da so zadnja vrata, ki jih je Microsoft uporabil za namene odpravljanja napak, odprla možnosti za onemogočanje varnega zagona v napravah Windows.

Secure Boot in kaj je to?

Ko prvič zaženete napravo Windows, gre postopek zagona v tem splošnem vrstnem redu: UEFI (Unified Extensible Firmware Interface, ki je zamenjava za BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI je tam, kjer je prisotna funkcija Secure Boot. Kot že ime pove z

Varen zagon, želi izboljšati varnost z zahtevanjem digitalnih podpisov na naslednjih korakih. V bistvu, če zagonski nalagalnik ni podpisan s ključi, ki jih pričakuje UEFI, postopek zagona vaše naprave ne bo dokončan.

Varni zagon je izbirna funkcija, vendar je Microsoft omogočil obvezno pridobitev certifikata za Windows od sistema Windows 8 in naprej. Razlog je bil, da bi varni zagon avtorjem zlonamerne programske opreme otežil vstavljanje kode v postopek zagona. Vendar pa je bil stranski učinek varnega zagona ta, da je nekoliko zapletel dvojni zagon na napravah Windows, saj bodisi drugi OS in vsi njegovi predpogoji morajo biti prav tako digitalno podpisani ali pa mora biti varen zagon onemogočeno. V zvezi s tem je veliko drugih težav in izkušeni uporabniki dvojnega zagona bi o njih vedeli več, kot bi lahko razložil v odstavku.

Obstaja nekaj naprav, na katerih uporabnik ne more onemogočiti varnega zagona, tudi če bi želel. To je področje, kjer se naša tema drastično zoži glede na vse naprave Windows (vključno z namizja) na določene naprave Windows, kot so naprave Windows Phone, naprave Windows RT, nekatere naprave Surface in celo HoloLens. Te naprave končnih uporabnikov imajo Varni zagon je zaklenjen, kar pomeni, da an končni uporabnik ne more spremeniti ali onemogočiti vidikov, povezanih z varnim zagonom, in posledično se ne smejo dotikati operacijskega sistema na načine, ki jih Microsoft ni odobril za končnega uporabnika.

Toda za namene stalnega uradnega razvoja mora Secure Boot nekoliko popustiti. V napravah, na katerih je zaklenjen varni zagon, obstajajo pravilniki varnega zagona, ki lahko pomagajo pri pooblaščenem razvoju, ne da bi morali onemogočiti varni zagon. Kot omenjajo raziskovalci, to datoteko s pravilnikom o varnem zagonu naloži upravitelj zagona zgodaj v procesu zagona za Windows. Datoteke pravilnika lahko vsebujejo tudi pravila registra, ki lahko med drugim vsebujejo konfiguracije samega pravilnika. Datoteka s pravilnikom mora biti podpisana in obstajajo tudi druge določbe, ki zagotavljajo, da lahko samo Microsoft zagotovi te spremembe.

Element podpisovanja je odvisen tudi od tega, kar se imenuje DeviceID, ki se uporablja pri prijavi. Pustil bom, da tukaj razlaga objava v spletnem dnevniku, saj mi nekaj delov ni tako jasnih:

Obstaja tudi nekaj takega, imenovano DeviceID. To je prvih 64 bitov zasoljene zgoščene vrednosti SHA-256 nekega izhoda UEFI PRNG. Uporablja se pri uporabi pravilnikov v sistemu Windows Phone in sistemu Windows RT (mobilestartup ga nastavi v telefonu in SecureBootDebug.efi, ko se prvič zažene v sistemu RT). Na telefonu mora biti pravilnik na določenem mestu na particiji EFIESP z imenom datoteke, vključno s šestnajstiško obliko ID-ja naprave. (Z Redstoneom se je to spremenilo v UnlockID, ki ga nastavi bootmgr in je le neobdelani izhod UEFI PRNG).

V bistvu bootmgr preveri pravilnik, ko se naloži, če vključuje DeviceID, ki se ne ujema z DeviceID naprave, na kateri se izvaja bootmgr, pravilnika ne bo mogoče naložiti. Vsak pravilnik, ki omogoča omogočanje testnega podpisovanja (MS te pravilnike Retail Device Unlock/RDU poimenuje in njihova namestitev je odklepanje naprave), naj bi bil zaklenjen na DeviceID (UnlockID na Redstone in nad). Dejansko imam več pravilnikov (podpisanih s certifikatom proizvodnje telefona Windows), kot je ta, kjer sta edini razliki vključen DeviceID in podpis. Če veljaven pravilnik ni nameščen, se bootmgr vrne k uporabi privzetega pravilnika, ki se nahaja v njegovih virih. Ta pravilnik je tisti, ki blokira omogočanje testnega podpisovanja itd. z uporabo pravil BCD.

To je del, kjer stvari postanejo zanimive. Med razvojem sistema Windows 10 v1607 je Microsoft ustvaril novo vrsto pravilnika o varnem zagonu (v nadaljevanju zaradi jedrnatosti imenovanega SBP) za namene internega testiranja in odpravljanja napak. Pravilnik je po naravi "dodaten" brez prisotnega ID-ja naprave in povzroči, da se njegove nastavitve združijo z obstoječim pravilnikom zagona. Upravitelj zagona naloži starejše vrste SBP, nato preveri njegovo podpisovanje in pristnost ter nato naloži te dodatne politike zagona. Težava je v tem, da ni dodatnega preverjanja same dodatne politike. Poleg tega upravitelji zagona, starejši od Windows 10 v1511, ne vedo za obstoj dopolnilne narave teh pravilnikov in zato reagirajo, kot da so naložili popolnoma veljavno in podpisano politiko. Še enkrat, to vedenje je bilo verjetno za notranji razvoj, tako da razvijalcem ne bi bilo treba podpisati vsake različice OS in manjših sprememb, ki bi jih morali narediti na napravi.

Ta SBP se imenuje "zlati ključ", saj v bistvu izniči namen preverjanja podpisov. Ta SBP je bil nenamerno poslan v maloprodajne naprave, čeprav v deaktiviranem stanju. Razvijalci so našli ta SBP in objavili svoje ugotovitve. Zdaj je lahko SBP našli lebdeči po internetu, pri čemer se ta poseben zip uporablja za namestitev SBP v naprave Windows RT.

Kaj to pomeni?

Če ste naložili dodatni SBP, lahko omogočite preizkusno podpisovanje za Windows, da omogočite nalaganje nepodpisanih gonilnikov. Nadalje, ker ti pravilniki pridejo v poštev pred stopnjo upravitelja zagona v postopku zagona, lahko ogrozite varnost celotnega naročila in zaženete nepooblaščeno (beri samopodpisano) kodo. To odpira veliko možnosti za uporabnike, ki nameravajo spreminjati dele sistema Windows brez dovoljenja, in za ustvarjalce zlonamerne programske opreme.

Avtorji te ugotovitve se osredotočajo na ironijo celotnega fiaska. Microsoft je zaklenil varni zagon na določenih napravah, da prepreči nepooblaščene spremembe, nato pa je vgradil stranska vrata, da lahko nadaljujejo z razvojem in odpravljanjem napak. Toda prav ta zadnja vrata utirajo pot, da je varni zagon onemogočen na vseh napravah z operacijskim sistemom Windows, zaradi česar je celotna preizkušnja nesmiselna.

Ne samo, da lahko voljni uporabniki zdaj namestijo distribucije Linuxa (in morda Android) na tablične računalnike samo z operacijskim sistemom Windows in Telefoni, imajo lahko nezaželeni uporabniki nameščene tudi zlonamerne zagonske komplete, če ogrozijo fizični dostop do svojih napravo. Medtem ko je prvo nekaj, ob čemer lahko skočimo v zrak, pa drugo ne vliva prav veliko zaupanja. Gre za obe smeri in nam pokaže, zakaj je varnost dvorezen meč. Poleg tega je SBP po naravi univerzalen, kar omogoča uporabo na kateri koli napravi, ne glede na arhitekturo. Ni posebej uporabno za primere namiznih računalnikov, kjer je varni zagon mogoče preprosto izklopiti, vendar je izjemno uporaben za naprave, kjer se ne morete zapletati z varnim zagonom.

Torej, kaj je popravek?

Microsoft je izdal nekaj popravkov, vendar razvijalci vztrajajo, da težava ni v celoti odpravljena. Lahko si ogledate te popravke (MS16-094 in MS16-100) in nato preberite o blog objava zakaj ne rešijo težave. Če so pravilni, ta težava nima popravka ali popravka na vidiku, čeprav to Microsoftu ne bo preprečilo, da bi na poti postavil nove ovire.

Kaj je naslednje?

Možnosti je ogromno in nekatere od njih se pojavljajo na naših forumih Windows. Naše forume si lahko ogledate na Razvoj in vdiranje v Windows Phone 8 in naši forumi za Windows 8, Windows RT ter Surface Development and Hacking. Lahko tudi najdete niti z navodili za nekatere naprave, kjer drugi uporabniki razpravljajo o istem.


Prisotnost teh stranskih vrat za odpravljanje napak in puščanje SBP nista pomembna le za tretje osebe razvoj zaklenjenih naprav Windows, nam pokažejo tudi mračen opomnik, kaj se lahko zgodi, če namerno zadnja vrata so ostala. Nedavni poudarek na varnosti se je usmeril k preiskovalnim agencijam, ki zahtevajo prisotnost takšnih stranskih vrat, ki bi jih uporabili za pomoč pri svojih zakonitih preiskovalnih namenih. Toda prej ali slej te metode volja pade v napačne roke. Kar naj bi se uporabljalo kot orodje za boj proti kriminalu in pomoč pri pravosodju, bi nekega dne postalo orodje za sam zločin.

Kaj menite o uhajanju Debug SBP? Se vam zdi, da bi takšni "zlati ključi" morali obstajati? Sporočite nam v komentarjih spodaj!