En nyligen genomförd läcka av en "Golden Key" från Microsoft i kombination med närvaron av ett felsökningsläge har tillåtit säker start att inaktiveras på Windows-enheter. Läs vidare!
Windows-baserade operativsystem är inte längre standard- och toppvalet i den mobila scenen. Androids öppen källkod har hittat många fans i OEM-tillverkare, och som ett resultat använder allt färre telefoner Windows nuförtiden.
Men om du är bland dem som fortfarande fortsätter att använda en Windows-enhet i ditt dagliga liv, finns det lite nyheter för dig. Bra eller dåligt, det beror på din hållning och tolkning av användningsfallen för den här nyheten.
Som rapporterats av Ars Technica och Registret med nyheterna som kommer från en webbplats som förmodligen kommer att ge dig huvudvärk (skämtar inte), några utvecklare (@aldrig_släppt och @TheWack0lian) har fått reda på att en bakdörr som Microsoft bakade in i felsökningssyfte har öppnat möjligheter att inaktivera säker start på Windows-enheter.
Säker start och vad är det?
När du först startar upp en Windows-enhet går startproceduren runt i denna allmänna ordning: UEFI (Unified Extensible Firmware Interface, som är en ersättning för BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI är där Secure Boot-funktionen finns. Som namnet antyder med Säker start, det syftar till att förbättra säkerheten genom att kräva digitala signaturer på nästa steg. I huvudsak, om starthanteraren inte är signerad med nycklar som UEFI förväntar sig att den ska vara med, kommer proceduren för uppstart av din enhet inte att slutföras.
Säker start är en valfri funktion, men Microsoft har gjort det obligatoriskt att få Windows-certifiering från Windows 8 och framåt. Resonemanget här var att Secure Boot skulle göra det svårt för författare av skadlig programvara att infoga kod i uppstartsproceduren. En bieffekt av Secure Boot var dock att det gjorde det lite komplicerat att dubbelstarta på Windows-maskiner, eftersom antingen måste det andra operativsystemet och alla dess krav också signeras digitalt, eller så måste säker start vara Inaktiverad. Det finns många andra problem med detta, och erfarna dual-booters skulle veta om dem mer än jag kunde förklara i ett stycke.
Nu finns det vissa enheter på vilka Secure Boot inte kan inaktiveras av användaren även om de skulle vilja. Det här är riket där vårt ämne blir drastiskt begränsat från alla Windows-enheter (inklusive stationära datorer) till specifika Windows-enheter som Windows Phone-enheter, Windows RT-enheter, vissa Surface-enheter och till och med HoloLens. Dessa slutanvändarenheter har Säker start låst på, vilket betyder att en slutanvändaren kan inte ändra eller inaktivera aspekter relaterade till säker start, och i förlängningen kan de inte röra operativsystemet på sätt som inte godkänts av Microsoft för slutanvändaren.
Men för pågående officiell utveckling måste Secure Boot lossna lite. På enheter som Secure Boot är låst på finns Secure Boot Policies som kan hjälpa till med auktoriserad utveckling utan att behöva inaktivera Secure Boot. Som forskande användare nämner, laddas denna Secure Boot Policy-fil av Boot Manager tidigt i startprocessen för Windows. Policyfilerna kan också innehålla registerregler som i sin tur har förmågan att bland annat innehålla konfigurationer för själva policyn. Återigen måste policyfilen signeras och det finns andra bestämmelser som finns för att säkerställa att endast Microsoft kan tillhandahålla dessa ändringar.
Signeringselementet förlitar sig också på det som kallas DeviceID, som används vid ansökan. Jag låter blogginlägget förklara här, eftersom det finns några delar som inte är lika tydliga för mig:
Det finns också något som heter DeviceID. Det är de första 64 bitarna av en saltad SHA-256-hash, av någon UEFI PRNG-utgång. Det används när policyer tillämpas på Windows Phone och på Windows RT (mobilstart ställer in det på telefonen och SecureBootDebug.efi när det lanseras för första gången på RT). På telefon måste policyn finnas på en specifik plats på EFIESP-partitionen med filnamnet inklusive hex-formen av DeviceID. (Med Redstone ändrades detta till UnlockID, som ställs in av bootmgr, och är bara den råa UEFI PRNG-utgången).
I grund och botten kontrollerar bootmgr policyn när den laddas, om den innehåller ett DeviceID, som inte matchar DeviceID för enheten som bootmgr körs på, kommer policyn inte att laddas. Alla policyer som tillåter att testsignering (MS kallar dessa Retail Device Unlock/RDU-policyer, och installera dem är att låsa upp en enhet), är tänkt att vara låst till ett DeviceID (UnlockID på Redstone och ovan). Jag har faktiskt flera policyer (signerade av Windows Phone-produktionscertifikatet) som detta, där de enda skillnaderna är det medföljande DeviceID och signaturen. Om det inte finns någon giltig policy installerad, går bootmgr tillbaka till att använda en standardpolicy som finns i dess resurser. Denna policy är den som blockerar möjliggörande av testsignering, etc, med BCD-regler.
Det här är den del där saker och ting blir intressanta. Under utvecklingen av Windows 10 v1607 skapade Microsoft en ny typ av Secure Boot Policy (hädanefter kallad SBP för korthetens skull) för intern testning och felsökning. Policyn är "kompletterande" till sin natur utan något enhets-ID, och den gör att dess inställningar slås samman med en befintlig startpolicy. Boot Manager läser in de äldre typerna av SBP, verifierar sedan dess signering och äkthet och läser sedan in dessa kompletterande startpolicyer. Problemet här är att det inte finns någon ytterligare verifiering av själva tilläggspolicyn. Boothanterare tidigare än Windows 10 v1511 känner inte heller till förekomsten av den kompletterande karaktären hos dessa policyer, och därför, reagera som om de laddade en helt giltig och undertecknad policy. Återigen, detta beteende var troligt för intern utveckling, så att utvecklarna inte skulle ha behövt signera varje OS-version och mindre förändring de behövde göra på enheten.
Denna SBP hänvisas till som en "Golden Key" eftersom den i princip upphäver syftet med signaturkontroller. Denna SBP skickades oavsiktligt på detaljhandelsenheter, om än i avaktiverat tillstånd. Utvecklarna hittade denna SBP och gjorde sina upptäckter kända. Nu kan SBP vara hittats flyta runt på internet, med denna speciella zip som används för att installera SBP på Windows RT-enheter.
Vad betyder det här?
Om du laddade en extra SBP kan du aktivera testsignering för Windows så att du kan ladda in osignerade drivrutiner. Dessutom, eftersom dessa policyer kommer in i spelet före Boot Manager-steget i uppstartsproceduren, kan du äventyra säkerheten för hela ordern och köra obehörig (läs självsignerad) kod. Detta öppnar upp för många möjligheter, för användare som avser att modifiera delar av Windows utan tillstånd och för skapare av skadlig programvara.
Författarna till detta fynd fokuserar på ironin i hela fiaskot. Microsoft låste Secure Boot på vissa enheter för att hålla obehöriga ändringar långt borta, men byggde sedan in en bakdörr för att låta dem fortsätta med utveckling och felsökning. Men just denna bakdörr banar väg för att Säker start ska inaktiveras på alla enheter som kör Windows, vilket gör hela prövningen meningslös.
Inte bara kan villiga användare nu installera Linux-distros (och möjligen Android) på surfplattor och endast Windows Telefoner, ovilliga användare kan också ha skadliga bootkit installerade om de äventyrar fysisk åtkomst till deras enhet. Även om det förra är något vi kan hoppa upp i luften på, ingjuter det senare inte riktigt mycket självförtroende. Det går åt båda hållen, och det visar oss varför säkerhet är ett tveeggat svärd. Vidare är SBP universell till sin natur, vilket tillåter dess användning på alla enheter oavsett arkitektur. Det är inte särskilt användbart för stationära datorer där Secure Boot lätt kan stängas av, men det är av enormt utrymme för enheter där du inte kan bråka med Secure Boot.
Så, vad är åtgärden?
Microsoft släppte vissa patchar, men utvecklarna insisterar på att problemet inte är helt åtgärdat. Du kan kolla in dessa patchar (MS16-094 och MS16-100) och läs sedan upp på blogginlägg sig på varför de inte löser problemet. Om de är korrekta har det här problemet ingen fix eller korrigering i sikte, även om det inte hindrar Microsoft från att försöka placera fler vägspärrar på vägen.
Vad härnäst?
Det finns en värld av möjligheter, och några av dem håller på att växa fram på våra Windows-forum. Du kan kolla in våra forum på Windows Phone 8 utveckling och hackning och våra forum för Windows 8, Windows RT och ytutveckling och hacking. Du kan också hitta instruktionstrådar för vissa enheter, där andra användare diskuterar detsamma.
Närvaron av denna debug-bakdörr och läckan av SBP är viktiga inte bara för tredje part utveckling av låsta Windows-enheter visar de oss också en dyster påminnelse om vad som kan hända om det är avsiktligt bakdörrar är kvar. Den senaste tidens fokus på säkerhet hade riktats mot utredningsorgan som tryckte på för att sådana bakdörrar skulle användas för att hjälpa till med deras rättsliga utredningssyfte. Men förr eller senare, dessa metoder kommer hamna i orätta händer. Det som är tänkt att användas som ett verktyg för att bekämpa brott och medverka till rättvisa, skulle sedan en dag bli redskapet för själva brottet.
Vad är dina tankar om läckan av Debug SBP? Känner du att "Golden Keys" som dessa borde finnas? Låt oss veta i kommentarerna nedan!