A Microsofttól nemrégiben kiszivárgott "Aranykulcs", valamint a hibakeresési mód lehetővé tette a biztonságos rendszerindítás letiltását a Windows-eszközökön. Olvass tovább!
A Windows-alapú operációs rendszerek már nem az alapértelmezett és a legjobb választás a mobil szcénában. Az Android nyílt forráskódú jellege sok rajongóra talált az OEM-eknél, és ennek köszönhetően manapság egyre kevesebb telefon használ Windowst.
De ha Ön azok közé tartozik, akik továbbra is Windows-eszközt használnak mindennapi életében, van egy kis hír az Ön számára. Jó vagy rossz, ez az Ön álláspontjától és a hír használati eseteinek értelmezésétől függ.
Amint arról beszámolt Ars Technica és A regisztráció a felől származó hírekkel webhely, amely valószínűleg fejfájást fog okozni (nem viccelek), néhány fejlesztő (@never_released és @TheWack0lian) rájöttek, hogy a Microsoft által hibakeresési célból beépített hátsó ajtó megnyitotta a lehetőséget a biztonságos rendszerindítás letiltására a Windows-eszközökön.
Secure Boot és mi az?
Amikor először indít el egy Windows-eszközt, a rendszerindítási eljárás a következő általános sorrendben zajlik: UEFI (Egységes bővíthető firmware-interfész, amely a BIOS-t helyettesíti) -> Boot Manager -> Boot Loader -> Ablakok. Az UEFI az a hely, ahol a Secure Boot funkció megtalálható. Ahogy a név is sugallja Biztonságos rendszerindítás, célja a biztonság javítása digitális aláírások megkövetelésével a következő lépéseknél. Lényegében, ha a rendszerbetöltő nincs aláírva olyan kulcsokkal, amelyekkel az UEFI elvárja, hogy legyen, akkor az eszköz indítási folyamata nem fejeződik be.
A biztonságos rendszerindítás opcionális szolgáltatás, de a Microsoft kötelezővé tette a Windows-tanúsítvány megszerzését a Windows 8-tól kezdve. Az indoklás az volt, hogy a Secure Boot megnehezítené a rosszindulatú programok készítői számára, hogy kódot illesszenek be a rendszerindítási eljárásba. A Secure Boot mellékhatása azonban az volt, hogy kissé bonyolulttá tette a kettős rendszerindítást Windows gépeken, mivel vagy a második operációs rendszert és az összes előfeltételét is digitálisan alá kell írni, vagy a Secure Boot kell Tiltva. Sok más probléma is van ezzel, és a tapasztalt kettős bakancsosok többet tudnak róluk, mint amennyit egy bekezdésben el tudnék magyarázni.
Vannak olyan eszközök, amelyeken a felhasználó még akkor sem tudja letiltani a Secure Boot funkciót, ha akarná. Ez az a terület, ahol a témánk drasztikusan leszűkül az összes Windows-eszközhöz képest (beleértve asztali számítógépekre) bizonyos Windows-eszközökre, például Windows Phone-eszközökre, Windows RT-eszközökre, egyes Surface-eszközökre vagy akár HoloLens. Ezek a végfelhasználói eszközök rendelkeznek Biztonságos rendszerindítás be van kapcsolva, vagyis egy A végfelhasználó nem módosíthatja vagy tilthatja le a Biztonságos rendszerindítással kapcsolatos szempontokat, és kiterjesztve, nem érinthetik meg az operációs rendszert a Microsoft által a végfelhasználó számára nem engedélyezett módon.
De a folyamatos hivatalos fejlesztés érdekében a Secure Boot-ot lazítani kell egy kicsit. Azokon az eszközökön, amelyeken a biztonságos rendszerindítás le van zárva, léteznek Biztonságos rendszerindítási házirendek, amelyek segíthetnek az engedélyezett fejlesztésben anélkül, hogy le kellene tiltani a biztonságos rendszerindítást. Ahogy a kutató felhasználók említik, ezt a Secure Boot Policy fájlt a Boot Manager tölti be a Windows rendszerindítási folyamatának elején. A házirend-fájlok tartalmazhatnak regisztrációs szabályokat is, amelyek többek között maguknak a házirendnek a konfigurációját is tartalmazhatják. A házirend-fájlt ismét alá kell írni, és vannak más rendelkezések is, amelyek biztosítják, hogy ezeket a változtatásokat csak a Microsoft tudja biztosítani.
Az aláíró elem az úgynevezett DeviceID-re is támaszkodik, amelyet az alkalmazás során használnak. Hagyom, hogy a blogbejegyzés magyarázza itt, mert van néhány rész, ami számomra nem olyan egyértelmű:
Ezenkívül létezik egy DeviceID nevű dolog. Ez a sózott SHA-256 hash első 64 bitje, néhány UEFI PRNG kimenetből. A házirendek Windows Phone és Windows RT rendszeren történő alkalmazásakor használatos (a Mobilestartup beállítja a Phone-on, és a SecureBootDebug.efi, amikor először indítják el RT-n). Telefonon a házirendnek egy adott helyen kell lennie az EFIESP partíción a fájlnévvel, beleértve az eszközazonosító hexadecimális alakját. (A Redstone-nál ez UnlockID-re változott, amelyet a bootmgr állít be, és ez csak a nyers UEFI PRNG kimenet).
Alapvetően a bootmgr betöltéskor ellenőrzi a házirendet. Ha tartalmaz egy DeviceID-t, amely nem egyezik annak az eszköznek az eszközazonosítójával, amelyen a bootmgr fut, a házirend betöltése sikertelen lesz. Bármilyen házirend, amely lehetővé teszi a tesztaláírást (az MS ezeket a Retail Device Unlock / RDU házirendeket nevezi, és telepítésük feloldja az eszköz zárolását), állítólag egy DeviceID-hez van zárva (UnlockID Redstone és felett). Valóban, több ilyen (a Windows Phone gyártási tanúsítvánnyal aláírt) házirendem is van, ahol az egyetlen különbség a mellékelt eszközazonosító és az aláírás. Ha nincs telepítve érvényes házirend, a bootmgr visszaáll az erőforrásaiban található alapértelmezett házirend használatára. Ez a házirend az, amely blokkolja a tesztaláírás stb. engedélyezését BCD-szabályok használatával.
Ez az a rész, ahol a dolgok érdekessé válnak. A Windows 10 v1607 fejlesztése során a Microsoft egy új típusú Secure Boot Policy-t hozott létre (a továbbiakban a rövidség kedvéért SBP néven hivatkozunk rá) belső tesztelés és hibakeresés céljából. A házirend „kiegészítő” jellegű, és nincs jelen DeviceID, és a beállításokat egy meglévő rendszerindítási házirendbe egyesíti. A Boot Manager betölti a régebbi típusú SBP-t, majd ellenőrzi annak aláírását és hitelességét, majd betölti ezeket a kiegészítő rendszerindítási házirendeket. A probléma az, hogy magának a kiegészítő szabályzatnak nincs további ellenőrzése. Ezenkívül a Windows 10 v1511-nél korábbi rendszerindítás-kezelők nem tudnak ezeknek a házirendeknek a kiegészítő jellegéről, és így úgy reagálnak, mintha egy tökéletesen érvényes és aláírt szabályzatot töltöttek volna be. Ez a viselkedés ismét a belső fejlesztés miatt valószínű, így a fejlesztőknek nem kellett volna minden egyes operációs rendszer verziót aláírniuk és az eszközön végrehajtandó kisebb változtatásokat.
Ezt az SBP-t "Aranykulcsnak" nevezik, mivel alapvetően érvényteleníti az aláírás-ellenőrzések célját. Ezt az SBP-t akaratlanul is kiskereskedelmi eszközökre szállították, jóllehet deaktivált állapotban. A fejlesztők megtalálták ezt az SBP-t, és ismertették eredményeiket. Most az SBP lehet az interneten lebegve találták, ahol ezt a zip-et használják az SBP telepítéséhez a Windows RT-eszközökön.
Mit is jelent ez?
Ha egy kiegészítő SBP-t töltött be, engedélyezheti a tesztaláírást a Windows számára, hogy lehetővé tegye aláírás nélküli illesztőprogramok betöltését. Továbbá, mivel ezek a házirendek a rendszerindítási eljárás Boot Manager szakasza előtt lépnek életbe, veszélyeztetheti a teljes megrendelés biztonságát, és jogosulatlan (önaláírt) kódot futtathat. Ez számos lehetőséget nyit meg a Windows egyes részeit engedély nélkül módosítani szándékozó felhasználók és a rosszindulatú programok készítői számára egyaránt.
Ennek a megállapításnak a szerzői az egész fiaskó iróniájára összpontosítanak. A Microsoft bizonyos eszközökön lezárta a Secure Boot funkciót, hogy távol tartsa a jogosulatlan változtatásokat, de beépített egy hátsó ajtót, hogy folytathassák a fejlesztést és a hibakeresést. De éppen ez a hátsó ajtó nyitja meg az utat a Secure Boot letiltásához minden Windows-t futtató eszközön, ami értelmetlenné teszi az egész megpróbáltatást.
A hajlandó felhasználók most már nem csak Linux disztribúciókat (és esetleg Androidot) telepíthetnek csak Windows rendszerű táblagépekre és A telefonokon a nem akaró felhasználók rosszindulatú indítókészleteket is telepíthetnek, ha veszélyeztetik a telefonjukhoz való fizikai hozzáférést. eszköz. Míg az előbbi olyasvalami, amit a levegőbe tudunk ugrani, az utóbbi nem kelt túl sok önbizalmat. Mindkét irányba megy, és megmutatja, miért kétélű fegyver a biztonság. Ezenkívül az SBP univerzális jellegű, lehetővé téve a használatát bármilyen eszközön, az architektúrától függetlenül. Nem különösebben hasznos olyan asztali számítógépeknél, ahol a Biztonságos rendszerindítás könnyen kikapcsolható, de óriási hatókört kínál az olyan eszközök számára, ahol nem lehet a Secure Boot-tal bajlódni.
Szóval, mi a megoldás?
A Microsoft kiadott néhány javítást, de a fejlesztők ragaszkodnak ahhoz, hogy a probléma nincs teljesen megoldva. Megnézheti ezeket a javításokat (MS16-094 és MS16-100), majd olvassa el a blog bejegyzés magát, hogy miért nem oldják meg a problémát. Ha helyesek, akkor a problémának nincs megoldása vagy javítása, bár ez nem akadályozza meg a Microsoftot abban, hogy további akadályokat próbáljon elhelyezni.
Mi a következő?
A lehetőségek tárháza van, és ezek egy része a Windows Fórumainkon készül el. Megnézheti fórumainkat a Windows Phone 8 fejlesztés és hackelés és fórumaink számára Windows 8, Windows RT és felületfejlesztés és hackelés. Meg is találhatod utasítási szálak egyes eszközökhöz, ahol más felhasználók is megbeszélik ugyanezt.
Ennek a hibakereső hátsó ajtónak a jelenléte és az SBP kiszivárgása nem csak a harmadik fél számára fontos A zárolt Windows-eszközök fejlesztése során egy komor emlékeztetőt is mutatnak nekünk arról, hogy mi történhet szándékosan hátsó ajtók maradnak. A közelmúltban a biztonságra való összpontosítás a nyomozó ügynökségek felé fordult, amelyek szorgalmazták az ilyen hátsó ajtók jelenlétét, hogy segítsék jogi nyomozási céljaikat. De előbb-utóbb ezek a módszerek akarat rossz kezekbe kerül. Amit a bűnözés elleni küzdelem és az igazságszolgáltatásban való segítségnyújtás eszközeként kívánnak használni, az egy napon magának a bűnözésnek az eszközévé válik.
Mi a véleményed a Debug SBP kiszivárogtatásáról? Úgy érzi, léteznie kell ilyen "Aranykulcsoknak"? Tudassa velünk az alábbi megjegyzésekben!