Nachrichten

"Windows 10 Anniversary Update" zerschießt Secure Boot

Software | 12.08.2016, 19:59
Im Juli (MS16-094) und August 2016 (MS16-100) stellte Microsoft jeweils ein Sicherheits-Update "für den sicheren Start" bereit. Wie erst jetzt bekannt wurde, haben die Redmonder beim "Anniversary Update" (Version 1607) von Windows 10 die Secure-Boot-Funktion zerschossen. Und richtig repariert wurde sie auch nicht.

Laut Microsoft gibt es Probleme mit bestimmten Richtlinien, die nur für Testzwecke gedacht waren. Sie ermöglichen es, die Codeintegritätsprüfungen zu deaktivieren und im Anschluss selbst signierte Dateien und Treiber zu laden. Darüber hinaus lässt sich die Integritätsprüfung für die Secure-Boot-Funktion ausschalten und man kann auch die Laufwerksverschlüsselung BitLocker sowie die Geräteverschlüsselung aushebeln. Um Richtlinien aus dem Netz heraus installieren zu können, muss sich ein Angreifer zunächst Administratorrechte verschaffen. Alternativ reicht auch ein physischer Zugang zum Computer. Abgesehen von Windows 10 lassen sich auch Windows 8.1, RT 8.1 sowie die Server 2012 und 2012 R2 über die fehlerhaften Richtlinien angreifen.

Wie das Malheur zustande kam

Die Entdecker des Fehlers nennen sich my123 (@never_released) und slipstream (@TheWack0lian), hatten das Problem im März bzw. April 2016 bemerkt und bei Microsoft gemeldet. Zunächst war Microsoft nicht an einer Fehlerbehebung interessiert, erkannte den Bug zwei Monate später dann aber doch an. Es folgten ein unzureichendes Update im Juli, welches die problematischen Richtlinien sperren sollte, sowie ein ebenso löchriges im August, das betroffene Bootmanager (auch Bootloader genannt) blockiert. Eigentlich müsste Microsoft alle alten Bootmanager auf eine schwarze Liste setzen, doch damit würden auch Installationsmedien und Wiederherstellungspartitionen unbrauchbar werden. Dass sich Secure Boot noch einmal komplett reparieren lässt, darf folglich bezweifelt werden.

Aus technischer Sicht

Secure Boot ist ein Bestandteil des "Unified Extensible Firmware Interface" (UEFI), welches sich als Nachfolger des BIOS (Basic Input/Output System) auf allen aktuellen Hauptplatinen von Workstations (x86-64), Desktop-PCs, Notebooks, Windows-Tablets und Windows-Smartphones befindet. Auf diesen Geräten stellt Secure Boot sicher, dass ausschließlich von Microsoft signierte Bootmanager gestartet werden. Hieraus baut sich eine Vertrauenskette auf: Der signierte Bootmanager lädt nur signierte Kernel, und diese Kernel laden nur signierte Treiber sowie signierte Anwendungen. Ziel dieser Architektur ist das Blockieren von Rootkits und anderen tief im System verankerten Schädlingen, doch auch problematische Treiber und Anwendungen sollen draußen bleiben.

Alle Windows-Tablets und viele Notebooks, die mit vorinstalliertem Windows ausgeliefert werden, verwenden Secure Boot und verhindern dessen Deaktivierung durch den Benutzer. Dies ist auch der Grund, weshalb sich auf etlichen Laptops weder Windows 7 noch ältere Linux-Distributionen installieren lassen – den Betriebssystemen und ihren Installationsmedien fehlt eine vertrauenswürdige Signatur. Für Linux gibt es inzwischen den seitens Microsoft signierten Bootmanager Shim, für Windows 7 könnte man die hier beschriebene Sicherheitslücke verwenden. Wobei es sich um keine Sicherheitslücke im eigentlichen Sinne handelt, sondern vielmehr um einen Designfehler beim Einbau neuartiger Richtlinien.

Bis zur Version 1607 von Windows 10 gab es nur Basisrichtlinien, die in einer UEFI-Variable oder auf der EFIESP-Partition gespeichert sind. Beim Laden der Richtlinien prüft der Bootmanager, ob es eine Gerätekennung (DeviceID) und BCD-Regeln (Boot Configuration Data) gibt. Über diese beiden Parameter können Entwickler ihre Geräte öffnen, um darauf – und nur auf diesen – ihre eigene Software zu testen. Mit der Version 1607 wurden dann ergänzende Richtlinien eingeführt, die immer auf der EFIESP-Partition liegen. Diese ergänzenden Richtlinien kommen ohne DeviceID und BCD-Regeln, da sie nicht alleine verwendet, sondern mit den Basisregeln zusammengeführt werden. Zunächst lädt der Bootmanager die Basisrichtlinien, dann die ergänzenden Richtlinien, und zum Schluss werden die beiden zusammengebastelt.

Was passiert nun, wenn ein älterer Bootmanager auf die ergänzenden Richtlinien trifft? Er hält diese für ganz normale signierte Richtlinien und setzt diese anstandslos um. Nun lassen sich nicht nur unsignierte Treiber und Rootkits, sondern auch eigene Bootmanager (Bootkits) laden. Tatsächlich müssen diese .efi-Dateien über eine Signatur verfügen. Es wird aber nicht überprüft, vom wem diese stammt. Man kann die Bootmanager also selbst signieren und Secure Boot auf diese Weise aushebeln oder gleich komplett abschalten. Wie gesagt: Um dieses Problem endgültig in den Griff zu bekommen, müsste Microsoft alle alten Bootmanager sperren.

Autor: mid
[pg]







Stichworte zur Meldung: Secure Microsoft Windows 10 Anniversery Update Boot