Microsoft zieht die "Secure Boot"-Bremse

Mit einem Update für Windows 8, Server 2012, 8.1 und Server 2012 R2 installiert Microsoft neue Schlüssel-Datenbanken, die den Start einiger UEFI-Module blockieren.

In Pocket speichern vorlesen Druckansicht 602 Kommentare lesen
Lesezeit: 3 Min.

Optionen für Secure Boot im BIOS-Setup eines Windows-8-PC

UEFI Secure Boot arbeitet mit kryptografischen Signaturen, Schlüsseln und Prüfungen, um den Start unerwünschter Software zu verhindern. Mit dem Update Rollup 2920189 nutzt Microsoft nun zum zweiten Mal die Möglichkeit, nachträglich die Schlüsseldatenbanken von Secure Boot zu verändern. Startet ein Windows-System im UEFI-Modus mit aktivierter Secure-Boot-Funktion, wird so das Laden von vier bestimmten UEFI-Modulen verhindert, die Microsoft dummerweise nicht konkret benennt.

Das Update steht für die 32- und 64-Bit-Versionen von Windows 8, Windows 8.1, Windows Server 2012 und Windows Server 2012 R2 bereit, aber nicht für die Windows-RT-Versionen für Tablets mit ARM-SoCs.

Das Update Rollup 2920189 spielt neue Versionen der von der UEFI-Spezifikation 2.3.1 für Secure Boot eingeführten Schlüsseldatenbanken dbupdate.bin und dbxupdate.bin ein. Diese Datenbanken speichert die Firmware in nichtflüchtigem Speicher und kontrolliert im Secure-Boot-Modus vor dem Laden jedes Software-Moduls, ob dessen Signatur dort abgelegt ist. Falls die Signatur nicht in der Liste der erlaubten Signaturen steht oder gar in der Liste der gesperrten Signaturen, wird der UEFI-Programmcode nicht ausgeführt.

UEFI-Firmware mit Secure Boot speichert Datenbanken, darunter DB und DBX mit erlaubten und gesperrten Signaturen.

Im Security Advisory 2962824 erklärt Microsoft einige weitere Details und verweist auch auf das ältere Update 287169 für Windows 8 und Server 2012, welches bereits die Signaturen von neun UEFI-Bootloadern sperrte. Diese waren aber angeblich nur zu Testzwecken genutzt worden

Im Artikel 2962824 weist Microsoft zudem darauf hin, dass manche Systeme nach dem Einspielen der erwähnten Updates möglicherweise nicht mehr booten, zumindest nicht im Secure-Boot-Modus – das ist ja der Zweck des Verfahrens. Im letztgenannten Artikel steht auch, dass bei manchen Windows-Server-2012-Installationen mit oder ohne Hyper-V ein Bug auftritt: Hier erwartet das Update, dass BitLocker installiert ist – BitLocker muss allerdings nicht aktiviert und konfiguriert sein.

Ob die Firmware und das Betriebssystem im Secure-Boot-Modus starten, verrät unter Windows 8 das mitgelieferte Tool Systeminformationen (msinfo32.exe): Es zeigt an, ob der "sichere Startzustand" aktiv ist.

Eine UEFI-Firmware führt Programme und Treiber aus, die in EFI Byte Code (EBC) geschrieben und für die jeweilige Plattform übersetzt wurden; es gibt 32- und 64-Bit-UEFI-Versionen für x86-Prozessoren, die IA64-Version für Itanium, eine 32-Bit- und bald auch eine 64-Bit-ARM-Version. Bei manchen Komplettrechnern sind Diagnosefunktionen oder BIOS-Update-Tools als EBC-Module installiert.

Die 13 von den beiden Secure-Boot-Updates blockierten UEFI-Module und -Bootloader besitzen laut Microsoft die folgenden SHA256-Hashes:

D626157E1D6A718BC124AB8DA27CBB65072CA03A7B6B257DBDCBBD60F65EF3D1
D063EC28F67EBA53F1642DBF7DFF33C6A32ADD869F6013FE162E2C32F1CBE56D
29C6EB52B43C3AA18B2CD8ED6EA8607CEF3CFAE1BAFE1165755CF2E614844A44
90FBE70E69D633408D3E170C6832DBB2D209E0272527DFB63D49D29572A6F44C
80B4D96931BF0D02FD91A61E19D14F1DA452E66DB2408CA8604D411F92659F0A
F52F83A3FA9CFBD6920F722824DBE4034534D25B8507246B3B957DAC6E1BCE7A
C5D9D8A186E2C82D09AFAA2A6F7F2E73870D3E64F72C4E08EF67796A840F0FBD
363384D14D1F2E0B7815626484C459AD57A318EF4396266048D058C5A19BBF76
1AEC84B84B6C65A51220A9BE7181965230210D62D6D33C48999C6B295A2B0A06
E6CA68E94146629AF03F69C2F86E6BEF62F930B37C6FBCC878B78DF98C0334E5
C3A99A460DA464A057C3586D83CEF5F4AE08B7103979ED8932742DF0ED530C66
58FB941AEF95A25943B3FB5F2510A0DF3FE44C58C95E0AB80487297568AB9771
5391C3A2FB112102A6AA1EDC25AE77E19F5D6F09CD09EEB2509922BFCD5992EA

(ciw)