Erinnern Sie sich an die Gelegenheiten, bei denen wir über Secure Boot gesprochen haben? Nun, auf irgendeine Weise ließ Redmond einige „goldene Schlüssel“ entkommen, die eigentlich eine spezielle Politik symbolisieren, die einem „Entwicklungsmodus“ entspricht und die wiederum mehrere Hauptfunktionen von Secure Boot deaktiviert. Das Beste? Microsoft dachte zunächst, dass dieses kein Problem sei, veröffentlichte aber innerhalb von weniger als einem Monat zwei Patches. Ist der Geist aus der Lampe entkommen?
Privatsphäre, Sicherheit, proprietärer Code, Open Source, Jailbreaking, Rooting… Begriffe, die kommen, gehen, kollidieren, einen ähnlichen Weg teilen oder sich gegenseitig zerreißen. Der durchschnittliche Benutzer steckt in einem Sturm fest, ohne zu wissen, was am besten ist, und die Argumente aller Beteiligten werden zu weißem Rauschen. Die neueste Neuigkeit, die sich über dieses Rauschen erhebt, betrifft Secure Boot, ein alter Bekannter hier bei NeoTeo, theoretischer Beschützer der Integrität des Computers und seines Betriebssystems (in diesem speziellen Fall verschiedene Windows-Versionen) und Todfeind vieler Linux-Reiter, die ein „Dual-Boot“ auf ihren neuen Geräten einrichten wollten und es nicht schafften. Microsoft gab (mehr als einmal) an, dass zertifizierte Systeme auf x86-Basis Secure Boot in einen „benutzerdefinierten Modus“ versetzen oder die Option bieten müssen, es vollständig zu deaktivieren, obwohl dies nicht für ARM-Geräte gilt. Das ist einer der Gründe, warum all diese Tablets mit Windows RT heute kaum mehr als Ziegelsteine sind. Der allgemeine Zustand von Secure Boot könnte sich jedoch innerhalb weniger Monate vollständig ändern.
Was genau ist passiert? Zwei Sicherheitsexperten mit den Pseudonymen MY123 und Slipstream entdeckten etwas, das sie „goldene Schlüssel“ nannten. Das sind keine digitalen Schlüssel im herkömmlichen Sinne, sondern eine spezielle Secure-Boot-Richtlinie, die die von UEFI beim Start ausgeführten Aufgaben verändert – darunter auch die Signaturprüfung. Offenbar existiert diese Richtlinie als „Entwicklungsmodus“ oder „Debug-Modus“, der es Programmierern ermöglicht, neue Builds zu evaluieren, Bugs zu finden und Korrekturen anzuwenden, ohne alles signieren zu müssen. Wie gelangte sie in die Hände von MY123 und Slipstream? Im Grunde fanden sie sie Ende März „schlafend“ in Geräten, die Microsoft zum Verkauf anbietet. Sie kontaktierten das Unternehmen im April, und damals hielt Microsoft es nicht für ein Sicherheitsrisiko (es erfordert physischen Zugriff „oder“ Administratorrechte), aber zwischen Juni und Juli beschloss man, eine Belohnung zu zahlen und zwei Patches zu veröffentlichen, MS16-094 und MS16-100, die die Situation zwar abmildern, aber keine endgültige Lösung darstellen.
Was wird daraus werden? Die Antwort ist „das kommt darauf an“. Die Richtlinie könnte die Installation alternativer Betriebssysteme auf Geräten mit Windows RT (ohne die zuvor genannten Hotfixes) oder Windows Phone ermöglichen. Persönlich würde ich gerne sehen, was die Community tun kann (es wird nicht einfach sein, aber es gibt Genies da draußen, die ständig nach solchen Herausforderungen suchen), aber die Medaille hat zwei Seiten. Es ist nicht logisch, eine schwarze Liste mit jedem betroffenen „bootmgr“ zu erstellen, weil das die Kompatibilität in mehr als einem Fall brechen würde (Original-Installationsdisks, Rettungspartitionen, Backups usw.). Und wenn jemand diese Lücke nutzt, um ein bösartiges „Paket“ zu installieren, nun ja...
(Anm. d. Red.: Ja, die offizielle Seite sieht aus wie ein Cracktro aus den 90ern.)
