Herinner je je die keren dat we het over Secure Boot hadden? Op de een of andere manier heeft Redmond bepaalde gouden sleutels laten ontsnappen, die in werkelijkheid een speciaal beleid symboliseren dat gelijk staat aan een ontwikkelingsmodus en die op hun beurt verschillende hoofdfuncties van Secure Boot uitschakelt. Het beste deel? Microsoft dacht aanvankelijk dat dit geen probleem was, maar bracht binnen minder dan een maand twee patches uit. Is de geest uit de fles ontsnapt?

Microsoft lekte een “meestermechanisme” van Secure Boot
Secure Boot

Privacy, beveiliging, propriëtaire code, open source, jailbreaking, rooting... termen die gaan, komen, botsen, een vergelijkbaar pad delen of elkaar vernietigen. De gemiddelde gebruiker zit gevangen in een storm zonder te weten wat het beste is, en de argumenten van alle betrokken partijen worden witte ruis. Het laatste nieuws dat boven die ruis uitstijgt, heeft te maken met Secure Boot, een oude bekende hier bij NeoTeo, theoretische beschermer van de integriteit van de computer en zijn besturingssysteem (in dit specifieke geval, verschillende versies van Windows), en de doodsvijand van veel Linux-rijders die een “dual-boot” wilden maken op hun nieuwe apparaten en dat niet lukte. Microsoft gaf (meer dan eens) aan dat gecertificeerde systemen op basis van x86 Secure Boot in een “aangepaste modus” moeten laten gaan of de mogelijkheid moeten bieden om het volledig uit te schakelen, hoewel dat niet geldt voor ARM-apparaten, een van de redenen waarom al die tablets met Windows RT tegenwoordig weinig meer zijn dan bakstenen. De algemene staat van Secure Boot zou echter binnen enkele maanden volledig kunnen veranderen.

Microsoft lekte een “meestermechanisme” van Secure Boot
Secure Boot kan in veel gevallen worden uitgeschakeld, maar in andere blijft het aanwezig, zelfs als de gebruiker dat niet wil.

De ontdekking

Wat is er precies gebeurd? Twee beveiligingsexperts met de pseudoniemen MY123 en Slipstream ontdekten iets dat ze “gouden sleutels” hebben genoemd, die geen digitale sleutels zijn in de traditionele zin, maar een speciaal Secure Boot-beleid dat de taken die door UEFI aan het begin worden uitgevoerd, wijzigt... waaronder de controle van handtekeningen. Blijkbaar bestaat dit beleid als een “ontwikkelingsmodus” of “debugmodus” als je wilt, die programmeurs in staat stelt om nieuwe builds te evalueren, bugs te detecteren en de nodige correcties toe te passen zonder alles te hoeven ondertekenen. Hoe kwam het in handen van MY123 en Slipstream? Kort gezegd vonden ze het eind maart “slapend” op apparaten die Microsoft te koop aanbiedt. Ze namen in april contact op met het bedrijf, en toen vond Microsoft dat het geen beveiligingsrisico was (vereist fysieke toegang “of” beheerdersrechten), maar tussen juni en juli besloten ze een beloning te betalen en twee patches uit te brengen, MS16-094 en MS16-100, die de situatie weliswaar beperken, maar geen definitieve oplossing bieden.

De gevolgen

Waar zal dit toe leiden? Het antwoord is “het hangt ervan af”. Het beleid zou de installatie van alternatieve besturingssystemen op apparaten met Windows RT (zonder de eerder genoemde hotfixes) of Windows Phone kunnen toestaan. Persoonlijk zou ik graag zien wat de gemeenschap kan doen (het zal niet eenvoudig zijn, maar er zijn genieën die op zoek zijn naar dit soort uitdagingen), maar er zijn twee kanten aan de medaille. Het is niet logisch om een zwarte lijst te maken met elke getroffen “bootmgr”, omdat dat de compatibiliteit in meer dan één geval zou breken (originele installatieschijven, herstelpartities, back-ups, enz.), en als iemand deze opening misbruikt om een kwaadaardig “pakket” te installeren, nou...

(N.v.d.r.: Ja, de officiële pagina ziet eruit als een cracktro uit de jaren '90)

Officiële site:

Bron: