Einführung
Microsoft wurde auf eine Sicherheitslücke im Windows-Bootmanager aufmerksam gemacht, die es einem Angreifer ermöglicht, den sicheren Start zu umgehen. Das Problem im Bootmanager wurde behoben und als Sicherheitsupdate veröffentlicht. Die verbleibende Sicherheitslücke besteht darin, dass ein Angreifer mit Administratorrechten oder physischem Zugriff auf das Gerät den Bootmanager auf eine Version ohne das Sicherheitsupdate zurücksetzen kann. Diese Rollback-Schwachstelle wird von der BlackLotus-Schadsoftware verwendet, um den von CVE-2023-24932beschriebenen sicheren Start zu umgehen. Um dieses Problem zu beheben, widerrufen wir die anfälligen Bootmanager.
Aufgrund der großen Anzahl von Bootmanagern, die blockiert werden müssen, verwenden wir eine alternative Möglichkeit, die Bootmanager zu blockieren. Dies betrifft Nicht-Windows-Betriebssysteme, da auf diesen Systemen ein Fix bereitgestellt werden muss, um zu verhindern, dass die Windows-Bootmanager als Angriffsvektor auf Nicht-Windows-Betriebssystemen verwendet werden.
Weitere Informationen
Eine Methode, um das Laden anfälliger EFI-Anwendungsbinärdateien durch die Firmware zu blockieren, besteht darin, Hashes der anfälligen Anwendungen in die UEFI Forbidden List (DBX) aufzunehmen. Die DBX-Liste wird im firmwareseitig verwalteten Flash der Geräte gespeichert. Die Einschränkung dieser Blockierungsmethode ist der begrenzte Firmware-Flashspeicher, der für die Speicherung des DBX zur Verfügung steht. Aufgrund dieser Einschränkung und der großen Anzahl von Bootmanagern, die blockiert werden müssen (Windows-Bootmanager der letzten 10+ Jahre), ist es nicht möglich, sich bei diesem Problem ausschließlich auf DBX zu verlassen.
Für dieses Problem haben wir eine hybride Methode zum Blockieren der anfälligen Bootmanager gewählt. Nur wenige Bootmanager, die in früheren Versionen von Windows veröffentlicht wurden, werden dem DBX hinzugefügt. Für Windows 10 und höhere Versionen wird eine WDAC-Richtlinie (Windows Defender Application Control) verwendet, die anfällige Windows-Bootmanager blockiert. Wenn die Richtlinie auf ein Windows-System angewendet wird, „sperrt“ der Bootmanager die Richtlinie für das System, indem er der UEFI-Firmware eine Variable hinzufügt. Windows-Bootmanager berücksichtigen die Richtlinie und die UEFI-Sperre. Wenn die UEFI-Sperre eingerichtet ist und die Richtlinie entfernt wurde, wird der Windows-Bootmanager nicht gestartet. Wenn die Richtlinie vorhanden ist, wird der Bootmanager nicht gestartet, wenn er durch die Richtlinie blockiert wurde.
Leitfaden zum Blockieren anfälliger Windows-Bootmanager
HINWEIS: Benutzern sollte die Möglichkeit gegeben werden, die Variable anzuwenden, damit sie steuern können, wann sie geschützt werden.
Die Aktivierung der UEFI-Sperre führt dazu, dass vorhandene bootfähige Windows-Medien nicht mehr gestartet werden, bis die Medien mit den Windows-Updates aktualisiert werden, die am oder nach dem 9. Mai 2023 veröffentlicht werden. Eine Anleitung zum Aktualisieren von Medien finden Sie unterKB5025885: Verwalten der Windows Bootmanager-Widerrufe für Änderungen am sicheren Start im Zusammenhang mit CVE-2023-24932.
-
Für Systeme mit aktiviertem sicherem Start, die nur Nicht-Windows-Betriebssysteme starten
Für Systeme, die nur Nicht-Windows-Betriebssysteme starten und niemals Windows starten, können diese Abhilfemaßnahmen sofort auf das System angewendet werden. -
Für Systeme, die Windows und ein anderes Betriebssystem dual starten
Für Systeme, die Windows starten, sollten die Nicht-Windows-Abhilfemaßnahmen erst angewendet werden, nachdem das Windows-Betriebssystem auf die Windows-Updates aktualisiert wurde, die am oder nach dem 9. Mai 2023 veröffentlicht wurden.
Erstellen der UEFI-Sperre
Die UEFI-Sperre verfügt über zwei Variablen, die erforderlich sind, um Rollbackangriffe im Windows-Bootmanager zu verhindern. Diese Variablen lauten wie folgt:
-
SKU-SiPolicy-Attribute
Diese Richtlinie weist die folgenden Attribute auf:
-
Richtlinientyp-ID:
{976d12c8-cb9f-4730-be52-54600843238e}
-
Spezifischer Dateiname von „SkuSiPolicy.p7b“
-
Spezifischer physischer Speicherort von EFI\Microsoft\Boot
Wie alle signierten WDAC-Richtlinien wird eine signierte SKU-Richtlinie durch zwei UEFI-Variablen geschützt:
-
SKU_POLICY_VERSION_NAME: „SkuSiPolicyVersion“
-
SKU_POLICY_UPDATE_POLICY_SIGNERS_NAME: „SkuSiPolicyUpdateSigners“
-
-
SKU-SiPolicy-Variablen
Diese Richtlinie verwendet zwei UEFI-Variablen, die unter EFI-Namespace/Vendor
GUID(SECUREBOOT_EFI_NAMESPACE_GUID) gespeichert sind:#define SECUREBOOT_EFI_NAMESPACE_GUID \
{0x77fa9abd, 0x0359, 0x4d32, \
{0xbd, 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}};
-
SkuSiPolicyVersion
-
ist zur Laufzeit vom Typ ULONGLONG/UInt64
-
wird durch <VersionEx>2.0.0.2</VersionEx> innerhalb der XML-Richtlinie in Form von (MAJOR.MINOR.REVISION.BUILDNUMBER) definiert
-
Sie wird in ULONGLONG übersetzt als
((major##ULL << 48) + (minor##ULL << 32) + (revision##ULL << 16) + buildnumber)
Jede Versionsnummer hat 16 Bits, also insgesamt 64 Bits.
-
Die Version der neueren Richtlinie muss gleich oder größer sein als die Version, die zur Laufzeit in der UEFI-Variablen gespeichert ist.
-
Beschreibung: Legt die Version der Bootrichtlinie für die Code-Integrität fest.
-
Attribute:
(EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS)
-
Namespace-GUID:
77fa9abd-0359-4d32-bd60-28f4e78f784b
-
Datentyp:
uint8_t[8]
-
Daten:
uint8_t SkuSiPolicyVersion[8] = { 0x2,0x0,0x0,0x0,0x0,0x0,0x2,0x0 };
-
-
SkuSiPolicyUpdateSigners
-
Muss der Windows-Unterzeichner sein.
-
Beschreibung: Informationen zum Unterzeichner der Richtlinie.
-
Attribute:
(EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS)
-
Namespace-GUID:
77fa9abd-0359-4d32-bd60-28f4e78f784bd
-
Datentyp:
uint8_t[131]
-
Daten:
uint8_tSkuSiPolicyUpdateSigners[131] =
{ 0x01, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
0x0b, 0x00, 0x00, 0x00, 0xd0, 0x91, 0x73, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,
0x00, 0x00, 0x00, 0x00, 0x54, 0xa6, 0x78, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,
0x00, 0x00, 0x00, 0x00, 0x5c, 0xa6, 0x78, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00,
0x00, 0x00, 0x00, 0x00, 0x64, 0xa6, 0x78, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x0a, 0x2b, 0x06, 0x01,
0x04, 0x01, 0x82, 0x37, 0x0a, 0x03, 0x06, 0x00,
0x00, 0x00, 0x00};
-
-
Anwenden von DBX
Wir haben die Datei DbxUpdate.bin für dieses Problem auf UEFI.orgveröffentlicht. Diese Hashes enthalten alle widerrufenen Windows-Bootmanager, die zwischen Windows 8 und der ersten Version von Windows 10 veröffentlicht wurden und die Code-Integritätsrichtlinie nicht einhalten.
Es ist von größter Wichtigkeit, dass diese mit Bedacht angewendet werden, da das Risiko besteht, dass sie ein Dual Boot-System beschädigen, das mehrere Betriebssysteme und einen dieser Bootmanager verwendet. Kurzfristig wird empfohlen, dass diese Hashes für jedes System optional angewendet werden.
