Microsoftin äskettäinen "kultaisen avaimen" vuoto yhdistettynä virheenkorjaustilaan on mahdollistanut suojatun käynnistyksen poistamisen käytöstä Windows-laitteissa. Jatka lukemista!
Windows-pohjaiset käyttöjärjestelmät eivät ole enää oletus- ja suosituin vaihtoehto mobiilimaailmassa. Androidin avoimen lähdekoodin luonne on löytänyt monia faneja OEM-valmistajilta, ja sen seurauksena yhä harvemmat puhelimet käyttävät Windowsia nykyään.
Mutta jos kuulut niihin, jotka edelleen käyttävät Windows-laitetta jokapäiväisessä elämässäsi, sinulla on vähän uutisia. Hyvä vai huono, se riippuu asenteesta ja tämän uutisen käyttötapausten tulkinnasta.
Kuten raportoi Ars Technica ja Rekisteri uutisten kanssa, jotka ovat peräisin a sivusto, joka todennäköisesti aiheuttaa sinulle päänsärkyä (ei vitsi), muutama kehittäjä (@never_released ja @TheWack0lian) ovat havainneet, että Microsoftin virheenkorjaustarkoituksiin käyttämä takaovi on avannut mahdollisuuden poistaa suojatun käynnistyksen käytöstä Windows-laitteissa.
Secure Boot ja mikä se on?
Kun käynnistät Windows-laitteen ensimmäisen kerran, käynnistysprosessi etenee tässä yleisessä järjestyksessä: UEFI (Unified Extensible Firmware Interface, joka korvaa BIOSin) -> Boot Manager -> Boot Loader -> Windows. UEFI on paikka, jossa Secure Boot -toiminto on läsnä. Kuten nimestä voi päätellä Suojattu käynnistys, sen tavoitteena on parantaa turvallisuutta vaatimalla digitaalisia allekirjoituksia seuraavissa vaiheissa. Pohjimmiltaan, jos käynnistyslatainta ei ole allekirjoitettu avaimilla, joita UEFI odottaa sen sisältävän, laitteen käynnistys ei suoriteta loppuun.
Secure Boot on valinnainen ominaisuus, mutta Microsoft on tehnyt sen sallimisen pakolliseksi saada Windows-sertifikaatti Windows 8:sta alkaen. Syynä tähän oli se, että Secure Boot vaikeuttaisi haittaohjelmien tekijöitä lisäämään koodia käynnistysmenettelyyn. Secure Bootin sivuvaikutus oli kuitenkin se, että se teki Windows-koneiden kaksoiskäynnistyksen hieman monimutkaisemmaksi, koska joko toinen käyttöjärjestelmä ja kaikki sen edellytykset on myös allekirjoitettava digitaalisesti tai Secure Boot on oltava liikuntarajoitteinen. Tähän liittyy monia muita ongelmia, ja kokeneet kaksoiskäynnistimet tietäisivät niistä enemmän kuin voisin selittää kappaleessa.
Nyt on joitakin laitteita, joissa käyttäjä ei voi poistaa suojattua käynnistystä käytöstä, vaikka he haluaisivat. Tämä on alue, jossa aiheemme rajataan rajusti kaikista Windows-laitteista (mukaan lukien pöytätietokoneet) tiettyihin Windows-laitteisiin, kuten Windows Phone -laitteisiin, Windows RT -laitteisiin, joihinkin Surface-laitteisiin ja jopa HoloLens. Näillä loppukäyttäjälaitteilla on Suojattu käynnistys lukittu, mikä tarkoittaa, että an loppukäyttäjä ei voi muokata tai poistaa käytöstä suojattuun käynnistykseen liittyviä näkökohtia, ja lisäksi he eivät voi koskettaa käyttöjärjestelmää tavoilla, joita Microsoft ei ole hyväksynyt loppukäyttäjälle.
Mutta jatkuvaa virallista kehitystä varten Secure Bootin on löysättävä hieman. Laitteissa, joissa Secure Boot on lukittu, on olemassa suojattuja käynnistyskäytäntöjä, jotka voivat auttaa valtuutettua kehitystä ilman, että suojattua käynnistystä tarvitsee poistaa käytöstä. Kuten tutkivat käyttäjät mainitsevat, Boot Manager lataa tämän Secure Boot Policy -tiedoston Windowsin käynnistyksen alussa. Käytäntötiedostot voivat myös sisältää rekisterisääntöjä, jotka puolestaan voivat sisältää muun muassa itse käytännön määrityksiä. Käytäntötiedosto on jälleen allekirjoitettava, ja olemassa on muita säännöksiä, joilla varmistetaan, että vain Microsoft voi tehdä nämä muutokset.
Allekirjoituselementti perustuu myös niin kutsuttuun DeviceID: hen, jota käytetään hakemuksessa. Annan blogikirjoituksen selittää tässä, koska muutama osa ei ole minulle yhtä selvää:
Lisäksi on olemassa sellainen asia nimeltä DeviceID. Se on suolatun SHA-256-hajasteen ensimmäiset 64 bittiä jostain UEFI PRNG -tulosta. Sitä käytetään sovellettaessa käytäntöjä Windows Phonessa ja Windows RT: ssä (mobilestartup asettaa sen puhelimeen ja SecureBootDebug.efi, kun se käynnistetään ensimmäisen kerran RT: ssä). Puhelimessa käytännön on sijaittava tietyssä paikassa EFIESP-osiossa, ja sen tiedostonimi sisältää DeviceID: n heksadesimaalimuodon. (Redstonen kanssa tämä muuttui UnlockID: ksi, jonka bootmgr asettaa, ja se on vain raaka UEFI PRNG -lähtö).
Periaatteessa bootmgr tarkistaa käytännön latautuessaan. Jos se sisältää DeviceID: n, joka ei vastaa sen laitteen DeviceID: tä, jolla bootmgr on käynnissä, käytäntö ei lataudu. Mikä tahansa käytäntö, joka sallii testiallekirjoituksen sallimisen (MS kutsuu näitä Retail Device Unlock / RDU-käytäntöjä ja niiden asentaminen avaa laitteen lukituksen), sen oletetaan olevan lukittu DeviceID: hen (UnlockID Redstonessa ja edellä). Itse asiassa minulla on useita tällaisia käytäntöjä (allekirjoitettu Windows Phone -tuotantosertifikaatilla), joissa ainoat erot ovat mukana tuleva DeviceID ja allekirjoitus. Jos kelvollista käytäntöä ei ole asennettu, bootmgr palaa käyttämään sen resursseissa olevaa oletuskäytäntöä. Tämä käytäntö estää testiallekirjoituksen jne. sallimisen BCD-sääntöjen avulla.
Tämä on se osa, jossa asiat muuttuvat mielenkiintoisiksi. Windows 10 v1607:n kehittämisen aikana Microsoft loi uudentyyppisen Secure Boot Policyn (jota kutsutaan vastedes lyhennyksen vuoksi nimellä SBP) sisäiseen testaukseen ja virheenkorjaustarkoituksiin. Käytäntö on luonteeltaan "täydentävä" ilman DeviceID: tä, ja sen asetukset yhdistetään olemassa olevaan käynnistyskäytäntöön. Boot Manager lataa vanhemmat SBP-tyypit, varmistaa sen allekirjoituksen ja aitouden ja lataa sitten nämä lisäkäynnistyskäytännöt. Ongelmana tässä on se, että itse täydentävää politiikkaa ei voida enää tarkistaa. Myöskään Windows 10 v1511:tä aiemmat Boot Managerit eivät tiedä näiden käytäntöjen täydentävästä luonteesta, joten reagoivat ikään kuin he olisivat ladaneet täysin kelvollisen ja allekirjoitetun käytännön. Jälleen tämä käyttäytyminen oli todennäköistä sisäisen kehityksen kannalta, joten kehittäjien ei olisi pitänyt allekirjoittaa jokaista käyttöjärjestelmäversiota ja pieniä muutoksia, joita heidän oli tehtävä laitteeseen.
Tätä SBP: tä kutsutaan "kultaiseksi avaimeksi", koska se periaatteessa mitätöi allekirjoitusten tarkistuksen tarkoituksen. Tämä SBP lähetettiin tahattomasti vähittäiskaupan laitteisiin, vaikkakin deaktivoituna. Kehittäjät löysivät tämän SBP: n ja ilmoittivat havainnoistaan. Nyt SBP voi olla löytyi kellumassa internetistä, jossa tätä zip-tiedostoa käytetään SBP: n asentamiseen Windows RT -laitteisiin.
Mitä tämä tarkoittaa?
Jos latasit täydentävän SBP: n, voit ottaa käyttöön testiallekirjoituksen Windowsille, jotta voit ladata allekirjoittamattomia ohjaimia. Lisäksi, koska nämä käytännöt tulevat käyttöön ennen Boot Manager -vaihetta käynnistysprosessissa, voit vaarantaa koko tilauksen turvallisuuden ja suorittaa luvattoman (lue itse allekirjoitetun) koodin. Tämä avaa paljon mahdollisuuksia käyttäjille, jotka aikovat muokata Windowsin osia luvatta, ja haittaohjelmien luojille.
Tämän löydön kirjoittajat keskittyvät koko fiaskon ironiaan. Microsoft lukitsi Secure Bootin tietyissä laitteissa pitääkseen luvattomat muutokset kaukana, mutta rakensi sitten takaoven, jotta ne voivat jatkaa kehitystä ja virheenkorjausta. Mutta juuri tämä takaovi tasoittaa tietä Secure Bootin poistamiselle käytöstä kaikissa Windowsia käyttävissä laitteissa, mikä tekee koko koettelemuksesta hyödyttömän.
Halukkaat käyttäjät voivat nyt asentaa Linux-distroja (ja mahdollisesti Androidin) vain Windows-tabletteihin ja Puhelimet, haluttomat käyttäjät voivat myös asentaa haitallisia käynnistyssarjoja, jos ne vaarantavat fyysisen pääsyn laite. Vaikka edellinen on jotain, jota voimme hypätä ilmaan, jälkimmäinen ei todellakaan juurruta paljon luottamusta. Se toimii molempiin suuntiin, ja se osoittaa meille, miksi turvallisuus on kaksiteräinen miekka. Lisäksi SBP on luonteeltaan universaali, mikä mahdollistaa sen käytön missä tahansa laitteessa arkkitehtuurista riippumatta. Se ei ole erityisen hyödyllinen pöytäkoneissa, joissa Secure Boot voidaan kytkeä pois päältä helposti, mutta se on valtavan käyttökelpoinen laitteissa, joissa et voi sekaisin Secure Bootin kanssa.
Joten mikä on korjaus?
Microsoft julkaisi joitain korjaustiedostoja, mutta kehittäjät väittävät, että ongelmaa ei ole kokonaan korjattu. Voit tarkistaa nämä paikat (MS16-094 ja MS16-100) ja lue sitten blogipostaus itse, miksi he eivät ratkaise ongelmaa. Jos ne ovat oikein, tälle ongelmalle ei ole korjausta tai korjausta näköpiirissä, vaikka se ei estä Microsoftia yrittämästä asettaa lisää tiesulkuja tielle.
Mitä seuraavaksi?
Mahdollisuuksia on valtavasti, ja osa niistä valmistuu Windows-foorumeillamme. Voit tutustua foorumeihimme osoitteessa Windows Phone 8 -kehitys ja hakkerointi ja foorumimme Windows 8, Windows RT ja pintakehitys ja hakkerointi. Voit myös löytää ohjesäikeitä joillekin laitteille, jossa muut käyttäjät keskustelevat samasta.
Tämän virheenkorjauksen takaoven olemassaolo ja SBP: n vuoto ovat tärkeitä paitsi kolmannelle osapuolelle. Lukittujen Windows-laitteiden kehittämisessä ne näyttävät myös synkän muistutuksen siitä, mitä voi tapahtua, jos se on tahallista takaovet jäävät. Viime aikoina keskittyminen turvallisuuteen oli kääntynyt kohti tutkintavirastoja, jotka vaativat tällaisten takaovien läsnäoloa auttamaan heidän laillisissa tutkintatarkoituksiinsa. Mutta ennemmin tai myöhemmin nämä menetelmät tahtoa joutua vääriin käsiin. Siitä, mitä on tarkoitettu käytettäväksi rikollisuuden torjuntaan ja oikeuden auttamiseen, tulee joskus itse rikollisuuden työkalu.
Mitä mieltä olet Debug SBP: n vuotamisesta? Tuntuuko, että tällaisia "kultaisia avaimia" pitäisi olla olemassa? Kerro meille alla olevissa kommenteissa!