Microsofti "kuldse võtme" leke võimaldab turvalise alglaadimise keelata

Windowsi-põhised operatsioonisüsteemid ei ole enam mobiilimaastikul vaikimisi ja parimaks valikuks. Androidi avatud lähtekoodiga olemus on leidnud OEM-ides palju fänne ja seetõttu kasutab tänapäeval Windowsi üha vähem telefone.

Kuid kui kuulute nende hulka, kes jätkavad oma igapäevaelus Windowsi seadme kasutamist, on teile üks uudis. Hea või halb, see sõltub teie hoiakust ja selle uudise kasutusjuhtude tõlgendusest.

Nagu teatas Ars Technica ja Registreeri uudistega, mis pärinevad a veebisait, mis tekitab teile tõenäoliselt peavalu (ei tee nalja), mõned arendajad (@never_released ja @TheWack0lian) on avastanud, et Microsofti silumise eesmärgil sisse lülitatud tagauks on avanud võimaluse keelata Windowsi seadmetes turvaline alglaadimine.

Turvaline alglaadimine ja mis see on?

Windowsi seadme esmakordsel käivitamisel toimub alglaadimisprotseduur järgmises üldises järjekorras: UEFI (Unified Extensible Firmware Interface, mis asendab BIOS-i) -> Boot Manager -> Boot Loader -> Windows. UEFI on koht, kus on olemas turvalise alglaadimise funktsioon. Nagu nimigi viitab

Turvaline alglaadimine, selle eesmärk on parandada turvalisust, nõudes digitaalallkirja järgmistel sammudel. Põhimõtteliselt, kui alglaadur ei ole allkirjastatud võtmetega, mida UEFI eeldab, et teie seadme alglaadimine ei lõpe.

Turvaline käivitamine on valikuline funktsioon, kuid Microsoft on muutnud Windowsi sertifikaadi hankimise Windows 8-st ja uuemast versioonist kohustuslikuks. Põhjendus oli see, et turvaline käivitamine raskendaks pahavara autoritel alglaadimisprotseduuri koodi sisestamist. Turvalise alglaadimise kõrvalmõju oli aga see, et see muutis Windowsi masinate topeltkäivitamise pisut keeruliseks, kuna kas teine ​​OS ja kõik selle eeltingimused peavad samuti olema digitaalselt allkirjastatud või peaks olema turvaline alglaadimine puudega. Sellega on seotud palju muid probleeme ja kogenud topeltkäivitajad teaksid neist rohkem, kui ma saaksin ühes lõigus selgitada.

Nüüd on mõned seadmed, mille puhul kasutaja ei saa turvalist alglaadimist keelata, isegi kui nad seda sooviksid. See on valdkond, kus meie teema kitseneb kõigist Windowsi seadmetest (sh lauaarvutid) teatud Windowsi seadmetele, nagu Windows Phone seadmed, Windows RT seadmed, mõned Surface'i seadmed ja isegi HoloLens. Nendel lõppkasutajate seadmetel on Turvaline alglaadimine on lukustatud, mis tähendab, et an lõppkasutaja ei saa turvalise alglaadimisega seotud aspekte muuta ega keelataja lisaks ei saa nad OS-i puudutada viisil, mida Microsoft pole lõppkasutaja jaoks volitanud.

Kuid käimasoleva ametliku arenduse huvides peab Secure Boot veidi lõdvenema. Seadmetes, millel on turvaline algkäivitus lukustatud, on olemas turvalise alglaadimise poliitikad, mis aitavad volitatud arendusel ilma turvalist alglaadimist keelata. Nagu uurivad kasutajad mainivad, laadib alglaadimishaldur selle turvalise alglaadimispoliitika faili Windowsi alglaadimisprotsessi alguses. Poliitikafailid võivad sisaldada ka registrireegleid, mis omakorda võivad sisaldada muu hulgas ka poliitika enda konfiguratsioone. Jällegi, poliitikafail peab olema allkirjastatud ja kehtivad muud sätted, mis tagavad, et ainult Microsoft saab neid muudatusi teha.

Allkirjastamise element tugineb ka nn DeviceID-le, mida kasutatakse taotlemisel. Lasen siin blogipostitusel selgitada, kuna mõned osad pole mulle nii selged:

Samuti on olemas selline asi nimega DeviceID. See on UEFI PRNG väljundi soolatud SHA-256 räsi esimesed 64 bitti. Seda kasutatakse reeglite rakendamisel Windows Phone'is ja Windows RT-s (mobilestartup määrab selle telefonis ja SecureBootDebug.efi, kui see RT-s esmakordselt käivitatakse). Telefonis peab poliitika asuma EFIESP-i partitsiooni kindlas kohas koos failinimega, mis sisaldab seadme ID kuueteistkümnendvormi. (Redstone'iga muudeti see UnlockID-ks, mille määrab bootmgr ja mis on lihtsalt UEFI PRNG toorväljund).

Põhimõtteliselt kontrollib bootmgr poliitikat laadimisel. Kui see sisaldab seadme ID-d, mis ei ühti selle seadme seadme ID-ga, milles bootmgr töötab, ei õnnestu poliitikat laadida. Mis tahes poliitika, mis võimaldab lubada testsignaliseerimist (MS nimetab neid jaemüügiseadmete avamise / RDU poliitikaid ja nende installimine avab seadme), peaks olema lukustatud seadme ID-ga (UnlockID Redstone'is ja eespool). Tõepoolest, mul on mitu sellist poliitikat (allkirjastatud Windows Phone'i tootmissertifikaadiga), kus ainsad erinevused on kaasasolev DeviceID ja allkiri. Kui kehtivat poliitikat pole installitud, kasutab bootmgr tagasi selle ressurssides asuvat vaikepoliitikat. See reegel blokeerib BCD reeglite abil testimisallkirjastamise jms lubamise.

See on osa, kus asjad lähevad huvitavaks. Windows 10 v1607 arendamise käigus lõi Microsoft sisetestimise ja silumise eesmärgil uut tüüpi turvalise alglaadimise poliitika (edaspidi lühiduse huvides viidatud kui SBP). Reegel on olemuselt "täiendav" ilma DeviceID-ta ja selle seaded liidetakse olemasoleva alglaadimispoliitikaga. Alglaadimishaldur laadib vanemat tüüpi SBP-sse, seejärel kontrollib selle allkirjastamist ja autentsust ning seejärel laadib need täiendavad alglaadimispoliitikad. Probleem on selles, et täiendavat poliitikat ennast enam ei kontrollita. Samuti ei tea Windows 10 v1511 varasemad alglaadimishaldurid nende poliitikate täiendava olemuse olemasolust ja seega reageerivad nii, nagu oleksid nad laadinud täiesti kehtiva ja allkirjastatud poliitika. Jällegi oli see käitumine tõenäoline sisemise arenduse jaoks, nii et arendajad poleks pidanud allkirjastama iga OS-i versiooni ja väiksemaid muudatusi, mida nad pidid seadmes tegema.

Seda SBP-d nimetatakse "kuldseks võtmeks", kuna see tühistab põhimõtteliselt allkirjade kontrollimise eesmärgi. See SBP tarniti tahtmatult jaemüügiseadmetesse, ehkki deaktiveeritud olekus. Arendajad leidsid selle SBP ja tegid oma järeldused teatavaks. Nüüd võib SBP olla leitud internetist vedelemas, kusjuures seda konkreetset zipi kasutatakse SBP installimiseks Windows RT seadmetesse.

Mida see tähendab?

Kui laadisite täiendava SBP-i, saate lubada Windowsi testallkirjastamise, et saaksite laadida sisse allkirjastamata draivereid. Lisaks, kuna need poliitikad hakkavad käima enne alglaadimisprotseduuri alglaadimishalduri etappi, võite kahjustada kogu tellimuse turvalisust ja käivitada volitamata (loe ise allkirjastatud) koodi. See avab palju võimalusi nii kasutajatele, kes kavatsevad Windowsi osi ilma volituseta muuta, kui ka pahavara loojatele.

Selle leiu autorid keskenduvad kogu fiasko irooniale. Microsoft lukustas teatud seadmetes turvalise alglaadimise, et hoida volitamata muudatused kaugel, kuid seejärel ehitas sisse tagaukse, et võimaldada neil arendamist ja silumist jätkata. Kuid just see tagauks sillutab teed turvalise alglaadimise keelamisele kõigis Windowsiga töötavates seadmetes, muutes kogu katsumuse mõttetuks.

Soovijad kasutajad ei saa nüüd installida Linuxi distributsioone (ja võib-olla ka Androidi) ainult Windowsiga töötavatele tahvelarvutitele ja Telefonidesse võivad soovimatud kasutajad installida ka pahatahtlikud alglaadimiskomplektid, kui need kahjustavad füüsilist juurdepääsu oma seade. Kui esimene on midagi, mille peale saame õhku hüpata, siis teine ​​ei sisenda tegelikult palju enesekindlust. See käib mõlemas suunas ja näitab meile, miks turvalisus on kahe teraga mõõk. Lisaks on SBP oma olemuselt universaalne, võimaldades seda kasutada mis tahes seadmes, sõltumata arhitektuurist. See pole eriti kasulik lauaarvutite puhul, kus turvalist alglaadimist saab hõlpsasti välja lülitada, kuid see on tohutult kasulik seadmete jaoks, kus te ei saa turvalise alglaadimisega jamada.

Niisiis, mis on lahendus?

Microsoft andis mõned paigad välja, kuid arendajad nõuavad, et probleem pole täielikult lahendatud. Saate neid plaastreid vaadata (MS16-094 ja MS16-100) ja seejärel lugege edasi ajaveebi postitus ise, miks nad probleemi ei lahenda. Kui need on õiged, pole sellele probleemile lahendust ega paika näha, kuid see ei takista Microsoftil üritamast teele rohkem tõkkeid asetada.

Mis edasi?

Võimalusi on maailm ja mõned neist valmivad meie Windowsi foorumites. Saate vaadata meie foorumeid aadressil Windows Phone 8 arendus ja häkkimine ja meie foorumid Windows 8, Windows RT ning pinnaarendus ja häkkimine. Samuti võite leida mõnede seadmete juhised, kus teised kasutajad arutavad sama.

---

Selle silumise tagaukse olemasolu ja SBP leke on olulised mitte ainult kolmanda osapoole jaoks lukustatud Windowsi seadmete arendamisel näitavad need meile ka sünge meeldetuletus selle kohta, mis võib tahtlikul juhul juhtuda tagauksed on jäänud. Hiljutine tähelepanu turvalisusele oli pöördunud juurdlusasutuste poole, kes nõudsid selliste tagauste olemasolu, et neid saaks kasutada nende juriidiliste uurimiseesmärkide täitmiseks. Kuid varem või hiljem need meetodid tahe sattuda valedesse kätesse. Sellest, mida kavatsetakse kasutada kuritegevuse vastu võitlemise ja õigusemõistmisel abistava vahendina, saab siis ühel päeval kuriteo enda tööriist.

Millised on teie mõtted Debug SBP lekke kohta? Kas teile tundub, et sellised "Kuldvõtmed" peaksid olemas olema? Andke meile allolevates kommentaarides teada!