Microsoft "Zelta atslēgas" noplūde ļauj atspējot drošo sāknēšanu

Nesenā "Zelta atslēgas" noplūde no Microsoft kopā ar atkļūdošanas režīmu ir ļāvusi atspējot drošo sāknēšanu Windows ierīcēs. Turpini lasīt!

Operētājsistēmas, kuru pamatā ir Windows, vairs nav noklusējuma un labākā izvēle mobilajā vidē. Android atvērtā pirmkoda būtība ir atradusi daudzus fanus oriģinālo iekārtu ražotāju vidū, un tāpēc mūsdienās arvien mazāk tālruņu izmanto Windows.

Bet, ja esat viens no tiem, kas joprojām turpina izmantot Windows ierīci savā ikdienas dzīvē, jums ir daži jaunumi. Labi vai slikti, tas būs atkarīgs no jūsu nostājas un šo ziņu lietošanas gadījumu interpretācijas.

Kā ziņoja Ars Technica un Reģistrs ar ziņām, kas nāk no a vietne, kas, visticamāk, sagādās jums galvassāpes (nejokojot), daži izstrādātāji (@never_released un @TheWack0lian) ir noskaidrojuši, ka aizmugures durvis, ko Microsoft ieviesa atkļūdošanas nolūkos, ir pavērušas iespējas atspējot drošo sāknēšanu Windows ierīcēs.

Droša sāknēšana un kas tas ir?

Pirmoreiz palaižot Windows ierīci, sāknēšanas procedūra notiek šādā vispārējā secībā: UEFI (Vienotā paplašināmā programmaparatūras saskarne, kas aizstāj BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI ir vieta, kur ir pieejama Secure Boot funkcionalitāte. Kā norāda nosaukums

Droša sāknēšana, tā mērķis ir uzlabot drošību, pieprasot ciparparakstus par nākamajiem soļiem. Būtībā, ja sāknēšanas ielādētājs nav parakstīts ar atslēgām, ar kurām UEFI to paredz, ierīces sāknēšanas procedūra netiks pabeigta.

Droša sāknēšana ir izvēles līdzeklis, taču Microsoft ir padarījis to par obligātu, lai saņemtu Windows sertifikātu no operētājsistēmas Windows 8 un jaunākām versijām. Iemesls šeit bija tāds, ka droša sāknēšana apgrūtinās ļaunprātīgas programmatūras autoriem koda ievietošanu sāknēšanas procedūrā. Tomēr Drošas sāknēšanas blakusefekts bija tas, ka tas nedaudz sarežģīja dubulto sāknēšanu Windows iekārtās, jo vai nu otrajai operētājsistēmai un visiem tās priekšnosacījumiem arī ir jābūt ciparparakstam, vai arī jābūt drošai sāknēšanai invalīds. Ar to ir daudz citu problēmu, un pieredzējuši dubultā zābaku lietotāji par tiem zinātu vairāk, nekā es varētu izskaidrot vienā rindkopā.

Tagad ir dažas ierīces, kurās lietotājs nevar atspējot drošo sāknēšanu, pat ja viņš to vēlētos. Šī ir joma, kurā mūsu tēma tiek krasi sašaurināta no visām Windows ierīcēm (tostarp galddatoriem) noteiktām Windows ierīcēm, piemēram, Windows Phone ierīcēm, Windows RT ierīcēm, dažām Surface ierīcēm un pat HoloLens. Šīm gala lietotāja ierīcēm ir Drošā sāknēšana ir bloķēta, kas nozīmē, ka an galalietotājs nevar modificēt vai atspējot aspektus, kas saistīti ar drošo sāknēšanu, un tādējādi viņi nevar pieskarties operētājsistēmai tādā veidā, ko Microsoft nav atļāvusi galalietotājam.

Bet, lai turpinātu oficiālu attīstību, programma Secure Boot ir nedaudz jāatslābina. Ierīcēs, kurās ir bloķēta drošā sāknēšana, pastāv drošās sāknēšanas politikas, kas var palīdzēt autorizētā izstrādē, neatspējojot drošo sāknēšanu. Kā min pētošie lietotāji, šo drošās sāknēšanas politikas failu sāknēšanas pārvaldnieks ielādē Windows sāknēšanas procesa sākumā. Politikas faili var ietvert arī reģistra noteikumus, kas savukārt var saturēt pašas politikas konfigurācijas, cita starpā. Atkal politikas failam ir jābūt parakstītam, un pastāv citi noteikumi, kas pastāv, lai nodrošinātu, ka šīs izmaiņas var nodrošināt tikai Microsoft.

Parakstīšanas elements balstās arī uz tā saukto DeviceID, kas tiek izmantots pieteikšanās laikā. Es ļaušu emuāra ierakstam paskaidrot, jo ir dažas daļas, kas man nav tik skaidras:

Ir arī tāda lieta, ko sauc par DeviceID. Tie ir pirmie 64 biti no sālīta SHA-256 jaucējkodola, no dažām UEFI PRNG izvadēm. To izmanto, piemērojot politikas operētājsistēmā Windows Phone un operētājsistēmā Windows RT (mobilestartup iestata to tālrunī un SecureBootDebug.efi, kad tas pirmo reizi tiek palaists RT). Tālrunī politikai ir jāatrodas noteiktā vietā EFIESP nodalījumā ar faila nosaukumu, tostarp DeviceID hex-formu. (Izmantojot Redstone, tas tika mainīts uz UnlockID, ko iestata bootmgr, un tā ir tikai neapstrādāta UEFI PRNG izvade).

Būtībā bootmgr pārbauda politiku, kad tā tiek ielādēta. Ja tajā ir iekļauts ierīces ID, kas neatbilst tās ierīces DeviceID, kurā darbojas bootmgr, politiku neizdosies ielādēt. Jebkura politika, kas ļauj iespējot testa parakstīšanu (MS sauc šīs mazumtirdzniecības ierīču atbloķēšanas/RDU politikas, un to instalēšana ir ierīces atbloķēšana), ir paredzēts bloķēt ar DeviceID (UnlockID Redstone un virs). Patiešām, man ir vairākas šādas politikas (parakstītas ar Windows Phone ražošanas sertifikātu), kur vienīgās atšķirības ir iekļautais ierīces ID un paraksts. Ja nav instalēta derīga politika, bootmgr atkal izmanto noklusējuma politiku, kas atrodas tā resursos. Šī politika bloķē testa parakstīšanas utt. iespējošanu, izmantojot BCD noteikumus.

Šī ir daļa, kurā lietas kļūst interesantas. Operētājsistēmas Windows 10 v1607 izstrādes laikā Microsoft izveidoja jauna veida drošās sāknēšanas politiku (īsuma labad turpmāk tiek saukta par SBP) iekšējai pārbaudei un atkļūdošanai. Politika pēc būtības ir "papildu" bez DeviceID, un tās iestatījumi tiek apvienoti esošajā sāknēšanas politikā. Sāknēšanas pārvaldnieks tiek ielādēts vecākos SBP veidos, pēc tam pārbauda tā parakstu un autentiskumu un pēc tam tiek ielādēts šajās papildu sāknēšanas politikās. Problēma ir tāda, ka pati papildu politika netiek pārbaudīta. Arī sāknēšanas pārvaldnieki, kas ir vecāki par operētājsistēmu Windows 10 v1511, nezina par šo politiku papildu raksturu, un tādējādi reaģē tā, it kā viņi ielādētu pilnīgi derīgu un parakstītu politiku. Arī šī rīcība, visticamāk, bija paredzēta iekšējai izstrādei, tāpēc izstrādātājiem nevajadzēja parakstīt katru OS versiju un nelielas izmaiņas, kas viņiem bija jāveic ierīcē.

Šis SBP tiek saukts par "zelta atslēgu", jo tas būtībā atceļ parakstu pārbaudes mērķi. Šis SBP tika netīši piegādāts mazumtirdzniecības ierīcēm, lai gan deaktivizētā stāvoklī. Izstrādātāji atrada šo SBP un ​​darīja zināmus savus atklājumus. Tagad SBP var būt atrasts peldam internetā, izmantojot šo konkrēto zip, lai instalētu SBP Windows RT ierīcēs.

Ko tas nozīmē?

Ja ielādējāt papildu SBP, varat iespējot pārbaudes parakstīšanu operētājsistēmai Windows, lai varētu ielādēt neparakstītus draiverus. Turklāt, tā kā šīs politikas sāk darboties pirms sāknēšanas procedūras sāknēšanas procesa, jūs varat apdraudēt visa pasūtījuma drošību un palaist nesankcionētu (lasīt pašparakstītu) kodu. Tas paver daudz iespēju lietotājiem, kuri plāno modificēt Windows daļas bez autorizācijas, kā arī ļaunprātīgas programmatūras radītājiem.

Šī atraduma autori koncentrējas uz visa fiasko ironiju. Microsoft noteiktās ierīcēs bloķēja drošo sāknēšanu, lai neļautu veikt neatļautas izmaiņas, bet pēc tam iebūvēja aizmugures durvis, lai tās varētu turpināt izstrādi un atkļūdošanu. Taču tieši šīs aizmugures durvis paver ceļu drošas sāknēšanas atspējošanai visās ierīcēs, kurās darbojas sistēma Windows, padarot visu pārbaudījumu bezjēdzīgu.

Lietotāji, kas vēlas, tagad var ne tikai instalēt Linux distros (un, iespējams, Android) tikai Windows planšetdatoros un Tālruņos, nevēloties lietotājiem, var būt instalēti arī ļaunprātīgi sāknēšanas komplekti, ja tie apdraud fizisku piekļuvi saviem ierīci. Lai gan pirmais ir kaut kas tāds, par ko mēs varam uzlēkt gaisā, otrais īsti nerada lielu pārliecību. Tas notiek abos virzienos, un tas parāda, kāpēc drošība ir abpusēji griezīgs zobens. Turklāt SBP pēc būtības ir universāls, ļaujot to izmantot jebkurā ierīcē neatkarīgi no arhitektūras. Tas nav īpaši noderīgs galddatoriem, kur drošo sāknēšanu var viegli izslēgt, taču tas ir ļoti piemērots ierīcēm, kurās nevarat sajaukt ar drošo sāknēšanu.

Tātad, kāds ir labojums?

Microsoft izlaida dažus ielāpus, taču izstrādātāji uzstāj, ka problēma nav pilnībā novērsta. Jūs varat pārbaudīt šos ielāpus (MS16-094 un MS16-100) un pēc tam izlasiet emuāra ieraksts par to, kāpēc viņi neatrisina problēmu. Ja tie ir pareizi, šai problēmai nav redzams labojums vai ielāps, taču tas netraucēs korporācijai Microsoft mēģināt izveidot papildu šķēršļus.

Kas tālāk?

Ir daudz iespēju, un dažas no tām tiek atklātas mūsu Windows forumos. Jūs varat apskatīt mūsu forumus vietnē Windows Phone 8 izstrāde un uzlaušana un mūsu forumos par Windows 8, Windows RT un virsmas izstrāde un uzlaušana. Jūs varat arī atrast instrukciju pavedieni dažām ierīcēm, kur citi lietotāji apspriež to pašu.


Šīs atkļūdošanas aizmugures durvju klātbūtne un SBP noplūde ir svarīga ne tikai trešajai pusei. bloķētu Windows ierīču izstrādi, tie arī parāda mums drūmu atgādinājumu par to, kas var notikt, ja tas ir tīšs aizmugures durvis ir atstātas. Nesenā uzmanība drošībai bija vērsta uz izmeklēšanas aģentūrām, kas uzstāja, lai šādas aizmugures durvis tiktu izmantotas, lai palīdzētu to juridiskos izmeklēšanas nolūkos. Bet agrāk vai vēlāk šīs metodes gribu nonākt nepareizās rokās. Tas, ko paredzēts izmantot kā līdzekli noziedzības apkarošanai un palīdzības sniegšanai tieslietās, reiz kļūs par pašu nozieguma rīku.

Kādas ir jūsu domas par Debug SBP noplūdi? Vai jums šķiet, ka šādām "Zelta atslēgām" vajadzētu pastāvēt? Paziņojiet mums zemāk esošajos komentāros!