Microsoft setzt aus Versehen Secure Boot Schachmatt

Mit dem Anniversary Update für Windows 10 (Version 1607) hat Microsoft eine Secure Boot Policy in den eigenen Bootloader eingebaut, die es einem Administrator auf einem System erlaubt, den Secure-Boot-Schutz zu umgehen. Damit ist es möglich, beliebige eigene Betriebssystem-Komponenten zu booten. Dieser Code muss lediglich irgendwie signiert sein – zum Beispiel mit einer selbst erstellten Signatur – damit der Bootloader ihn ausführt. Das umgeht die Schutzmechanismen von Secure Boot, da eigentlich nur Komponenten geladen werden dürften, die von Microsoft signiert sind.

Secure Boot? Nö!

Da die von Microsoft signierte und damit gültige Policy mittlerweile im Netz kursiert, kann nun ein eigentlich unberechtigter Angreifer, sofern er Administratorrechte besitzt, Secure Boot deaktivieren, ohne vor dem entsprechenden Rechner sitzen zu müssen. Bei PCs müsste er sonst in die Firmware booten und Secure Boot manuell abstellen. Bei Hardware bei der Microsoft dem Nutzer nicht erlaubt, Secure Boot zu deaktivieren (etwa Surface Tablets und Windows Phones) hat das den interessanten Effekt, dass Nutzer nun doch Secure Boot ausschalten und eigene Betriebssysteme booten kann.

Die Policy scheint eine Debug-Funktion zu sein. Microsoft hat sie anscheinend während der Entwicklung des Anniversary Updates eingebaut, um damit die eigenen Entwickler Builds von Betriebssystemkomponenten testen können, ohne sie jedes Mal mit dem offiziellen Microsoft-Schlüssel signieren zu müssen.

Ein unwirksamer Fix nach dem anderen

Die beiden Sicherheitsforscher, die Microsofts Fauxpas entdeckten, informierten die Firma im März. Zuerst wurde ihnen mitgeteilt, dass man das Problem nicht beheben wolle. Im Juli veröffentlichte Microsoft dann im Rahmen des Patchdays das Update MS16-094, allerdings stellten die Forscher fest, dass durch einen weiteren eklatanten Fehler Microsofts dieser das Problem nicht behebt. Auch der Patch MS16-100 vom gestrigen Patchday erschwert den Missbrauch der Policy nur, verhindert ihn aber nicht. Es ist zu erwarten, dass Microsoft die anstößige Policy mit einem weiteren Update komplett entfernt und die Lücke endgültig stopft.

Quelle: heise.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.