Firmware Attack Surface Reduction (FASR)

Im Oktober 2019 arbeitete Microsoft eng mit unseren OEM- und Silicon-Partnern zusammen, um gesicherte Secured-Core-PCs einzuführen. Diese Geräte verfügen über tief integrierte Hardware, Firmware und Software, um eine verbesserte Sicherheit für Geräte, Identität und Daten zu gewährleisten. Eine der wichtigsten Säulen der Sicherheit von Secured-Core-PCs ist die Bereitstellung von Firmwareschutz für Geräte. Eine grundlegende hardwarebasierte Funktion, die erforderlich ist, um dies zu erreichen, ist Dynamic Root of Trust for Measurement (D-RTM). Es gibt jedoch aufgrund der Abhängigkeit vom zugrunde liegenden Chipsatz für die Unterstützung dieser Funktion nicht viele Geräte, die D-RTM heute bieten, was unser Engagement dafür behindert, ein hohes Sicherheitsniveau für alle Windows-Geräte zu bieten und aufrechtzuerhalten.

Es kann mehr getan werden, um den Sicherheitsstatus aller Windows-Geräte zu verbessern, einschließlich solcher ohne D-RTM. Microsoft arbeitet mit Partnern zusammen, um die Kompatibilitätsprobleme zu überwinden, die verhindern, dass Speicherschutz in der UEFI-Firmware angewendet wird. Dazu werden verschiedene Open-Source-SMM-Sicherheitsverbesserungen entwickelt, um zusätzliche Flexibilität für OEMs zu bieten.

Um dieses Engagement für die Firmwaresicherheit zu unterstreichen, haben wir einen neuen Ansatz identifiziert, um sicherzustellen, dass Geräte die Firmwareschutzanforderungen von Secured-Core-PCs erfüllen können.

Überblick über FASR

Für Secured-Core-PCs, die keine hardwarebasierten D-RTM-Funktionen haben, müssen wir einen kleinen Satz von Firmwarekomponenten definieren, die eine reduzierte Angriffsfläche bieten und im Betriebssystem nachgewiesen werden können. Dieses Konzept wird als Firmware Attack Surface Reduction (FASR) bezeichnet. Damit FASR-basierte Firmware auf PCs unterschiedlicher Anbieter skaliert werden kann, musste ein neuer Ansatz für den Firmwarestartprozess definiert werden.

FASR unterstützt zwei Startpfade:

1. Zertifizierter Startpfad:

   • Es ist nur von Microsoft als vertrauenswürdig betrachteter, signierter und integrierter Code zulässig.

   • Manipulationen des Startpfads können vom Betriebssystem erkannt werden.

   Die folgende Abbildung zeigt den FASR S-RTM-Startflow auf dem zertifizierten Startpfad. Dieser Startpfad verhindert, dass unerwarteter Plattform-Firmwarecode ausgeführt wird. Er verwendet jedoch einige plattformspezifische Daten, die vom benutzerdefinierten Startpfad bereitgestellt werden. Das folgende Diagramm zeigt den FASR-Startflow auf dem zertifizierten Startpfad.

   

2. Benutzerdefinierter Startpfad: Der gesamte Plattform-Firmwarecode kann ausgeführt werden. Kritische Informationen für den Start, die für einen bestimmten OEM/eine bestimmte Plattform spezifisch sind, werden in Daten im benutzerdefinierten Startpfad konvertiert und vom zertifizierten Startpfad verwendet, um das System auf diesem Startpfad ordnungsgemäß zu konfigurieren. Das folgende Diagramm zeigt den FASR-Startflow auf dem benutzerdefinierten Startpfad.

   

   Ein FASR-Gerät, das für die Kompatibilität mit Secure-Core-PCs aktiviert ist, verwendet standardmäßig den zertifizierten Startpfad, es sei denn, es tritt ein Ereignis auf, das bewirkt, dass der Start früh im Firmwarestartprozess zum benutzerdefinierten Startpfad wechselt. Beispiele für solche Ereignisse sind ein Firmwareupdate, die Anforderung einer Firmwarebenutzeroberfläche durch einen Benutzer oder die Entscheidung des Benutzers, einen den Secure-Core-PC zu deaktivieren, was bedeutet, dass der Start immer auf dem benutzerdefinierten Startpfad erfolgt, bis er erneut aktiviert wird.

   Der benutzerdefinierte Start kann verwendet werden, um jedes Betriebssystem oder Software von Drittanbietern zu starten, wie von der Plattformfirmware auf einem FASR-fähigen Gerät unterstützt, aber Windows erkennt den Start auf dem benutzerdefinierten Startpfad nicht als Secure-Core-PC-kompatibel.

Um die Sicherheitstechnologien hinter FASR besser zu verstehen, möchten wir Ihnen einen schnellen Überblick über den Windows-Startprozess geben.

Windows-Startprozess

Root of Trust

Die anfängliche Firmwareausführung auf einem modernen PC folgt einem Startprozess, bei dem ein anfänglicher Codesatz anderen Code lädt und die Funktionalitätsebene erweitert wird, während der Start fortgesetzt wird. Jeder Codesatz überprüft den nächsten Codesatz, wodurch eine „Vertrauenskette“ entsteht. Wenn die UEFI-Firmware die Kontrolle übernimmt, folgt sie dem Secure Boot-Standard mit der Überprüfung von Softwaresignaturen, um die Vertrauenskette bis zum Betriebssystem fortzusetzen. Anschließend setzt das Windows-Startladeprogramm die Vertrauenskette mit Trusted Boot fort, wodurch alle anderen Betriebssystemkomponenten im Startprozess überprüft werden, bevor sie geladen werden.

Im Allgemeinen versuchen Angreifer, die Kontrolle so früh wie möglich im Startprozess zu erlangen, bevor Sicherheitsfeatures und Sperren, die den Schutz des Systems unterstützen, aktiviert sind. Wenn das System nach einer Rücksetzung neu startet, muss der anfängliche Codesatz als vertrauenswürdig verankert sein. Die Hardwareüberprüfungstechnologie, die diese frühe Codeüberprüfung durchführt, wird als Root of Trust bezeichnet. Während die genauen Details je nach Hardwareanbieter variieren, sind alle Roots of Trust in der Regel in unveränderlicher Hardware oder ROMs im SOC verwurzelt.

Kontrollierter Start

Secure Boot mit Verankerung in der Root of Trust stellt sicher, dass die digitale Signatur der gesamten Firmware überprüft wird. Es ist jedoch auch wünschenswert, genau die ausgeführte Firmware aufzuzeichnen. Das Windows Hardware Compatibility Program erfordert, dass alle Windows 10- und Windows 11-PCs einen TPM (Trusted Platform Module)-Chip enthalten. Das TPM enthält Speicherspeicherorte, die als Platform Configuration Registers (PCRs) bezeichnet werden. Jedes PCR enthält den Hash für einen Codetyp und/oder Daten, die während des Starts geladen werden, z. B. Firmwarecode auf dem nichtflüchtigen Speichergerät (z. B. SPI Flash), Options-ROMs von PCI-Geräten oder das Betriebssystemstartladeprogramm. Die Größe eines Wertes, der in einem PCR gespeichert werden kann, wird durch die Digest-Größe des unterstützten Hashing-Algorithmus bestimmt. Beispielsweise kann ein SHA-1-PCR 20 Byte speichern, während ein SHA-2-PCR 32 Byte speichern kann. Mehrere PCRs, die mit demselben Hashing-Algorithmus verbunden sind, werden als „Bank“ bezeichnet. Die TCG PC Client TPM Profile Specification definiert die Einbeziehung von mindestens einer PCR-Bank mit 24 Registern.

Mit einem TPM kann jede Firmwarekomponente das entsprechende PCR auch aktualisieren oder erweitern, wenn neuer Code und Daten im Startvorgang geladen werden. Der Erweiterungsprozess aktualisiert den PCR-Wert so, dass er die Ausgabe des Hashalgorithmus mithilfe des aktuellen PCR-Werts ist, der mit dem neuen Code oder Datenargument als Eingabe verkettet ist. Das Ergebnis ist, dass PCRs nach dem Startvorgang überprüft werden können, um festzustellen, was ausgeführt wird. Dadurch kann Software im Betriebssystem verstehen, ob sich der Startvorgang von früheren Starts unterscheidet. In einer sicherheitssensiblen Umgebung kann das Betriebssystem über die genauen Codemessungen informiert werden, die in bestimmten PCRs erwartet werden, um die Ausführung unerwarteter Firmwarecode zu erkennen. Da die ersten 16 PCRs in einer Bank nur zurückgesetzt werden können, indem das gesamte TPM zurückgesetzt wird, sind sie vertrauenswürdig und der bevorzugte Speicherort für wichtige Messungen im TPM.

Root of Trust für Messungen

Nachdem wir die Rolle der Root of Trust und der Verwendung von Measured Boot betrachtet haben, werden wir zwei verbreitete Ansätze zum Einrichten einer Root of Trust für die Meldung einer Messkette an das TPM betrachten: statisch und dynamisch.

Eine statische Root of Trust für Messungen (S-RTM) richtet beim Zurücksetzen des Systems eine Vertrauensstellung ein und erfordert, dass die Vertrauensstellung während des gesamten Startvorgangs beibehalten wird. Wenn die Vertrauensstellung an einem beliebigen Punkt des Startvorgangs kompromittiert wird, kann sie erst wieder wiederhergestellt werden, wenn das System zurückgesetzt wird. Das folgende Diagramm veranschaulicht, wie S-RTM auf dem zertifizierten Startpfad verwendet wird.

Im Gegensatz dazu vertraut Dynamic Root of Trust for Measurement (D-RTM) nur einem kleinen Teil des Firmwarecodes für die Initialisierung des Chipsatzes und einem Hardware-Agenten, der zum dynamischen Einrichten der Vertrauensstellung während des Starts verwendet wird. Das System kann zunächst mit nicht vertrauenswürdigem Firmwarecode gestartet werden, aber kurz nach dem Start wird es wieder auf einen vertrauenswürdigen Zustand zurückgesetzt, indem die Kontrolle über alle CPUs übernommen und ein bekannter und gemessener Pfad erzwungen wird. Das folgende Diagramm bietet eine Übersicht über einen herkömmlichen D-RTM-Fluss.

Es gibt einen Kompromiss zwischen S-RTM und D-RTM. S-RTM erfordert keine speziellen Hardwarefunktionen, jedoch Software, um den Code zu berücksichtigen, der während des gesamten Starts ausgeführt wurde. D-RTM erfordert spezielle Hardwarefunktionen, ermöglicht jedoch, dass Software während der Lebensdauer des Systems dynamisch in einen vertrauenswürdigen Zustand gestartet wird.

Windows Secured-Core-PCs haben einen D-RTM in Secure Launch verwendet, um Flexibilität für die breite Palette von Systemherstellern zu ermöglichen, einzigartige Features und Umgebungen in der Firmware zu implementieren und gleichzeitig sicherzustellen, dass das System einen vertrauenswürdigen und gemessenen Zustand erreichen kann, der für das Hosten einer sicheren Betriebssystemumgebung akzeptabel ist. Ein D-RTM-Startereignis wird verwendet, um die Vertrauensstellung aus einer unbekannten Umgebung wiederherzustellen, bevor ein sicherer Kernel geladen wird. Das folgende Diagramm zeigt das D-RTM-Startereignis zum erneuten Einrichten einer bekannten Systemumgebung.

In der Vergangenheit hätte S-RTM aufgrund seiner fehlenden Abhängigkeit von speziellen Hardwarefunktionen in mehr Geräten implementiert werden können, um den Sicherheitsstatus des Systems zu überprüfen, aber das Betriebssystem verfügte nicht über eine zuverlässige Methode, um zu bestätigen, dass sie den Messungen vertrauen könnte, die auf einem bestimmten Windows-Gerät mit S-RTM gemeldet wurden.

Sicherheitsverbesserungen für die Firmware

Minimieren der Firmwarekomponenten im Betriebssystem-Startpfad

Eine Möglichkeit, S-RTM-Messungen zu vertrauen, besteht darin, die Firmwarekomponenten so weit wie möglich zu reduzieren, die ausgeführt werden dürfen. Wenn alle Geräte, die S-RTM verwenden, dieselben Firmwarekomponenten verwendet haben, muss das Betriebssystem nur einem einzigen Satz erwarteter PCR-Werte für diese bekannten und vertrauenswürdigen Komponenten vertrauen. Bei diesem SRTM-basierten Ansatz kann angenommen werden, dass ein Gerät die Firmwareschutzanforderung von Secured-Core erfüllt, wenn die Gruppe der Startfirmware nur signierte Microsoft-Software enthält, die von Windows bestätigt werden kann. Um besser zu verstehen, wie sich diese Firmwarekomponenten von den bei einem normalen PC-Start verwendeten unterscheiden, betrachten wie das „Vorher“ und das „Nachher“ des Startvorgangs.

Aufgrund der Flexibilität und der zahlreichen Funktionen moderner PC-Firmware vergrößert der Code, der vor dem Betriebssystem ausgeführt wird, die Angriffsfläche. Das folgende Diagramm zeigt ein Beispiel für einen herkömmlichen S-RTM-Startflow.

Die Hauptaufgaben der Firmware während des Starts können erheblich vereinfacht werden:

• Plattformspezifisch: Funktionalität, die nur für das spezifische Plattform-Hardwaredesign gilt.

• Nicht-plattformspezifisch: Funktionalität, die Branchenstandards entspricht und auch für andere Hardware gilt.

Ein relativ kleiner Teil moderner Firmware ist in der Regel plattformspezifisch. Ein Großteil des Firmware-Infrastrukturcodes, der allgemeine Aufgaben ausführt wie z. B. das Zuweisen von Arbeitsspeicher, das Verteilen von Firmwaretreibern, den Umgang mit von Ereignissen usw., ist identisch zwischen allen (oder den meisten) UEFI-basierten Systemen. Die binären Firmwaretreiber für diese Aufgaben können über PCs hinweg wiederverwendet werden. Darüber hinaus ermöglichen Hardwarespezifikationen und -schnittstellen nach Branchenstandard gängige Firmwaretreiber, Festplatten, USB-Controller und andere Peripheriegeräte zu initialisieren. Die binären Firmware für diese Hardware können ebenfalls über PCs hinweg wiederverwendet werden. Zusammengefasst: PCs können mit einem minimalen Satz gängiger Firmwaretreiber gestartet werden.

Die Reduzierung der Gesamtzahl der beim Start geladenen Firmwaretreiber kann auch weitere Vorteile mit sich bringen:

• Verbesserte Startzeit

• Weniger Anbieterkoordination für Updates

• Geringere Fehlerbelastung

• Reduzierte Angriffsfläche

Überprüfung des FASR-Startpfads und Secured-Core-Compliance

Damit ein FASR-System die Firmwareschutzanforderungen von Secured-Core-PCs erfüllt, muss es auf dem zertifizierten Startpfad gestartet worden sein. Die FASR-Firmware unterstützt dies durch die Bereitstellung des Betriebssystems mit einem von Microsoft signierten Manifest mit der Bezeichnung FASR-Manifest (gemessen in das TPM), das die erwarteten PCR-Werte für die Modul-Startsequenz auf dem zertifizierten Pfad enthält. Dies kann mit der tatsächlichen Startsequenz verglichen werden, die auf dem zertifizierten Pfad aufgetreten ist. Wenn diese Messungen übereinstimmen, wird davon ausgegangen, dass das System die Firmwareschutzanforderung des Secured-Core-PC-Programms erfüllt. Jede Abweichung von der erwarteten zertifizierten Startpfadsequenz führt zu unerwarteten Messungen in den Plattformkonfigurationsregistern (PCRs) des TPM, die vom Betriebssystem erkannt werden.

Darüber hinaus veröffentlicht Windows nur hypervisor-geschützte Secrets nach erfolgreicher Überprüfung des signierten FASR-Manifests anhand der Messungen, die während des aktuellen Starts aufgezeichnet wurden. Wenn das FASR-Manifest auf einem zertifizierten Startpfad oder einem Capsule-Update nicht vorhanden ist, schlägt die Signaturüberprüfung fehl, oder es tritt ein PCR-Konflikt auf, und die VSM-Secrets werden nicht entsperrt oder migriert.

Wie FASR-Firmware mit Speicherschutz und SMM umgeht

Da jetzt eine einzelne von Microsoft signierte Binärdatei mit einem minimalen Satz von Funktionen definiert wurde, kann sie die grundlegenden, aber fehlenden Funktionen für den Firmwaresicherheitsschutz beinhalten, die Microsoft mit Partnern zusammen auf den Markt bringt. Der zertifizierte Startpfad muss mindestens die folgenden Anforderungen erfüllen:

1. Code liest/schreibt nicht in NULL/Seite 0

2. Imagecode und Datenabschnitte sind getrennt

3. Image-Abschnitte sind auf eine Seitengrenze (4 KB) ausgerichtet

4. Daten werden nur in Datenspeichertypen und Code in Codespeichertypen zugeordnet

5. Code-Images werden nicht aus Code geladen, der in Form von UEFI-Binärdateien verteilt wird (nur die angegebenen Verteiler)

6. Code verbleibt innerhalb der Grenzen der zugewiesenen Speicherpuffer mit Schutzseiten um Seitenzuweisungen

7. Stapelüberlauf kann erkannt werden

8. Code wird nicht aus dem Stack ausgeführt

9. Die Eigenschaft /NXCOMPAT DLL ist so festgelegt, dass NX-Schutzfunktionen aktiviert werden

Optionale ROMs, UEFI-Anwendungen und UEFI-Treiber von Drittanbietern wurden häufig nicht auf der Grundlage dieser Anforderungen erstellt oder überprüft. Daher wurden sie nicht auf dem zertifizierten Startpfad ausgeführt. Der benutzerdefinierte Startpfad kann optional entscheiden, die erforderliche Schutzebene zu senken, dieser Startpfad wird jedoch vom Betriebssystem nicht als Secure-Core-PC-kompatibel betrachtet.

Systemverwaltungsmodus (SMM)

SMM ist ein spezieller Prozessorbetriebsmodus in der x86-Architektur. Dieser stellt eine einzigartige Herausforderung für die Systemsicherheit dar, da der Code, der in der SMM-Umgebung ausgeführt wird, für das Betriebssystem nicht transparent ist und in der Regel auf der höchsten Berechtigungsstufe (manchmal als „Ring -2“ bezeichnet) der gesamten Software auf dem Hostprozessor ausgeführt wird. Bei der Eingabe konfiguriert SMM eine eigene Umgebung, indem die Seitentabelle, die Interrupt Dispatch-Seite (IDT) und andere Systemstrukturen eingerichtet werden. SMM stellt eine signifikante Angriffsfläche dar, die von bösartigem Code verwendet werden kann, um den durch virtualisierungsbasierte Sicherheit (VBS) aktivierten Betriebssystemschutz zu kompromittieren oder zu umgehen. Um die Gefahr durch SMM zu mindern, kann die Funktionalität in SMM wie folgt konzeptionell in die SMM-Kerninfrastruktur und SMM-Treiber aufgeteilt werden:

• SMM Core: Code, der für alle SMM-Implementierungen gilt, die architektur- und infrastrukturbezogene Verantwortlichkeiten haben

• SMM-Treiber: Code, der zum Ausführen einer plattformspezifischen Aufgabe in SMM geschrieben wurde

Einige wichtige Momente im SMM-Lebenszyklus sind die folgenden:

1. Wenn die SMM Foundation (oder der Core) eingerichtet wird – SMM Initial Program Load (IPL)

2. Wenn SMM-Treiber geladen werden – SMM Driver Dispatch

3. Wenn der Eintrag zu SMM erfolgt – über einen System Management Interrupt (SMI)

SMM Initial Program Load (IPL)

Die CPU verfügt über spezielle Funktionen, die SMM-Code seine hohen Berechtigungen gewähren und bei seinem Schutz helfen. Beispielsweise wird ein Mechanismus definiert, um SMM über Software- oder Hardwareereignisse einzugeben, eine CPU-Anweisung wird verwendet, um von SMM zurückzugeben, und mehrere Register werden definiert, um die Zugriffs- und Sperrkonfiguration von SMM zu steuern. Viele dieser Steuerregister werden vom SMM-IPL-Code konfiguriert, um den Zugriff auf den Speicherbereich einzuschränken, in dem SMM-Code und -Daten gespeichert werden (System Management RAM oder SMRAM).

Da sich der SMRAM-Bereich im Hauptspeicher (DRAM) befindet, kann er erst eingerichtet werden, wenn DRAM während des Starts aktiviert wurde. DRAM-Aktivierungsverfahren variieren je nach Chipanbieter, aber einige Megabyte Code können direkt aus dem CPU LLC-Cache (einschließlich des Codes, der DRAM initialisiert) ausgeführt werden, bevor der Hauptspeicher verfügbar ist.

FASR-Firmware bringt den SMM IPL-Punkt früher im Startvorgang als die meisten anderen Systeme. Dadurch wird die Gefahr reduziert, dass ein Angreifer diesen Prozess untergräbt und die Kontrolle über das System übernimmt, bevor SMM eingerichtet ist. Um diese und andere Verbesserungen, die an SMM in FASR-Firmware vorgenommen wurden, besser zu verstehen, müssen wir mehr über den Firmware-Startprozess wissen.

Plattforminitialisierungen (PI)-Start in UEFI-Firmware

Moderne PC-Firmware basiert auf vielen Spezifikationen. Die UEFI-Spezifikation definiert die Schnittstelle zwischen einem UEFI-kompatiblen Betriebssystem wie Windows und der Firmware auf dem Gerät. Eine weitere Spezifikation mit dem Namen Platform Initialization (PI) Specification definiert die Art und Weise, wie Firmware-Treiber erstellt werden, und detailliert den Startprozess selbst. Allgemein kann die UEFI-Spezifikation als eine der Standardisierungen betrachtet werden, mit denen ein einzelnes Windows-Image mit vielen verschiedenen Geräten arbeiten kann, und die PI-Spezifikation kann als eine der Standardisierungen gesehen werden, mit denen viele Firmware-Images von verschiedenen Hardwareanbietern zusammenarbeiten können. Beide Spezifikationen werden vom UEFI-Forum verwaltet.

Die PI-Spezifikation definiert Startphasen, und welche Treiber in die Startphasen geschrieben werden. Während des Firmware-Starts wird jede Phase an die nächste übergeben, und in den meisten Fällen werden die Treiber aus der Phasenübergabe nicht mehr verwendet und nur wichtige Daten werden an die nächste Phase übergeben, damit der Startvorgang fortgesetzt werden kann. Die Startphasen können in folgender Weise zusammengefasst werden:

1. SEC – Übernahme der Kontrolle im CPU-Reset-Vektor und Übergang von Assembly zu C-Code zum Laden von PEI

2. PEI – Initialisieren des Systemzustands zum Laden von DXE und zum Initialisieren von DRAM

3. DXE – Durchführen der verbleibenden Systeminitialisierung, die die Bereitstellung der Unterstützung für BDS umfasst, um ein Betriebssystem zu laden

4. BDS – Erkennen der Startoption für den aktuellen Start (z. B. Betriebssystem-Startladeprogramm) und Versuch, diese Option zu starten

5. OS – Der Betriebssystem-Kernel

Schützen des SMM Initial Program Load (IPL)

Herkömmliche mit der UEFI PI-Spezifikation kompatible Firmware lädt die SMM IPL in der DXE-Startphase. FASR-Firmware lädt die SMM IPL in der PEI-Startphase. Die Trusted Computing Base (TCB) für ein System ist der gesamte Satz von Schutzmechanismen, die es schützen, einschließlich Hardware, Firmware und Software. Durch das Verschieben der SMM IPL von DXE zu PEI wird die gesamte DXE-Phase (eine größere und umfangreichere Umgebung als PEI) aus dem TCB entfernt. Das folgende Diagramm zeigt die zuvor im UEFI-Startvorgang verschobene SMM-IPL.

Der PEI- und der DXE-Code werden bei Ring 0 ausgeführt und bleiben (mit wenigen Ausnahmen) nicht im Betriebssystem erhalten. SMM-Code wird mit einer höheren Berechtigung als Ring 0 (und der Hypervisor) ausgeführt und bleibt im Betriebssystem erhalten, so dass eine DXE-Sicherheitsanfälligkeit keine Auswirkungen auf die Einrichtung von SMM hat, was die gesamte Angriffsfläche des Systems verkleinert. Da SMM früher im Startvorgang gestartet wird, können die Sperrbits, die zum Schutz von SMM gesetzt sind, früher im Startvorgang aktiviert werden, wodurch die Angriffsfläche für eine Kompromittierung von SMM weiter minimiert wird.

Schützen des SMM-Treiber-Dispatch-Prozesses

Innerhalb der PI-Spezifikation sind zwei SMM-Modi definiert: Traditional MM und Standalone MM. Traditional MM entspricht dem SMM-Softwaremodell, das früher in PI-kompatibler Firmware verwendet wurde, d.h. in der meisten UEFI-Firmware der Branche. Standalone MM ist ein relativ neuer Modus, der das historische Modell abwandelt, um die Sicherheit der SMM-Umgebung zu verbessern und häufige Fehler in Traditional MM-Implementierungen zu verhindern, die im Laufe der Jahre zu zahlreichen Portabilitäts- und Sicherheitsproblemen geführt haben.

FASR-Firmware wird ausschließlich im Standalone MM-Modus ausgeführt. Auf diese Weise kann die FASR-Firmware einem disziplinierten Ansatz zur Softwareausführung in SMM folgen. Sehr viele SMM-basierte Sicherheitsrisiken sind heute auf problematische Verfahren zurückzuführen, die im SMM-Code in Traditional MM zulässig sind, und die in Standalone MM einfach entfernt werden können. Generell geschieht dies, da – im Traditional MM-Modell – ein SMM-Treiber zweimal vom DXE-Dispatcher in Ring 0 und erneut vom SMM-Dispatcher in SMM verteilt wird. Dies bietet ausreichend Gelegenheit für den in der DXE-Umgebung ausgeführten Treibercode, Zeiger auf Ressourcen außerhalb von SMRAM zwischenzuspeichern, auf die sie nach der Rückgabe des Einstiegspunkts nicht zugreifen sollten. Angriffe, die davon abhängen, dass SMM-Code außerhalb von SMM Code aufruft, werden häufig als „SMM Callout Attacks“ bezeichnet.

Schützen des Eintrags in SMM

Daten werden über eine Struktur mit der Bezeichnung „Kommunikationspufferׂ an einen SMI-Handler übergeben. Der SMI-Handler hat zu überprüfen, ob die Daten bestimmte Anforderungen an ihrem Eintragspunkt erfüllen. Die Windows SMM Security Mitigation Table (WSMT) ist ein Mechanismus, mit dem die Bedrohung bekämpft werden kann, die von ungeprüften SMI-Handlern für die virtualisierungsbasierte Sicherheit im Betriebssystem ausgeht. Microsoft hat Code zum TianoCore-Projekt beigetragen, um die Pufferüberprüfung bei der Kommunikation zu verbessern. Neben der Anwendung dieser beiden Techniken implementiert der FASR-Code auch strengen Speicherzugriffsschutz, so dass SMM-Code nur auf explizit zulässige Speicherbereiche zugreifen kann.

Management Mode Supervisor (MM Supervisor)

Der SMM-Kerncode ist verbreitet üblich und wird mit nur minimalen (oder keinen) Änderungen zwischen Systemen geteilt. Die durch SMM verursachte Angriffsfläche kann durch die Einführung der Berechtigungstrennung in die SMM-Umgebung erheblich reduziert werden. Aus diesem Grund enthält FASR-Firmware einen SMM Supervisor, der in Standalone MM ausgeführt wird. Dies führt zu einer gut definierten SMM-Umgebung mit einem minimalen TCB mit Berechtigungsstufen, die von der Erstellung erzwungen werden. Der MM Supervisor legt Einschränkungen für E/A-Portzugriffe, Model Specific Register (MSR)-Zugriffe, MMIO-Zugriff, CPU-Speicherstatuszugriff und zulässige Anweisungen in der SMM-Umgebung fest. Eine SMM Supervisor-Richtlinie wird verwendet, um die exakten Details dazu zu konfigurieren, welche Hardwareressourcen eingeschränkt werden sollen, und diese Details können für jede Chipgeneration geändert werden.

Die Richtlinie ist kürzlich zu einem „Deny-by-Default“-Ansatz übergegangen, der die Hardwareressourcen, die außerhalb des SMM Supervisors für Code verfügbar sind, erheblich reduziert. Dieser Supervisor arbeitet ohne Abhängigkeit von Hardwarefunktionen, die in modernen PCs häufig nicht vorhanden sind.

Der MM Supervisor in FASR ist Open-Source und steht im Project Mu MM Supervisor Repository zur Verfügung.

FASR-Systemkonformität mit den Anforderungen von Secure-Core-PCs

Die folgende Tabelle zeigt die allgemeinen Sicherheitssäulen bzw. die Ziele von Secured-Core-PCs sowie, wie FASR-Systeme, die im zertifizierten Pfad gestartet werden, die Anforderungen von Secured-Core-PCs erfüllen können:

Sicherheitsvorteile	Sicherheitsfeatures von Secured-Core-PCs
Erstellen einer hardwarebasierten Root of Trust	Sicherer Start
	Trusted Platform Module 2.0
	Direct Memory Access (DMA)-Schutz
Abwehr von Angriffen auf Firmware-Ebene (siehe den Hinweis unten)	System Guard Secure Launch (D-RTM) oder S-RTM (FASR FW)
	Systemverwaltungsmodus (SMM) Isolation oder Standalone MM mit MM Supervisor (FASR FW)
Schützen Sie das Betriebssystem vor der Ausführung von nicht verifiziertem Code	Speicherintegrität (auch als HVCI bezeichnet)
Bereitstellen einer erweiterten Identitätsüberprüfung und -schutz	Windows Hello
Schutz kritischer Daten bei verlorengegangenen oder gestohlenen Geräten	BitLocker-Verschlüsselung

Wenn das System nicht über erweiterte Sicherheitsfunktionen verfügt, um D-RTM zu unterstützen, können die Anforderungen an den Firmwareschutz mithilfe einer Kombination von S-RTM und Standalone MM mit MM Supervisor erfüllt werden, die beide von der FASR-Firmware angeboten werden.

Zusammenfassung

Dies sind einige der Investitionen, die Microsoft vorgenommen hat, um der zunehmenden Anzahl von Firmwareangriffen zu begegnen, die heute in der gesamten Branche weit verbreitet sind. Durch die Verwendung von Open-Source-Code für diese Änderungen ermöglichen wir unseren Partnern, einige dieser Sicherheitsvorteile zu nutzen, was wiederum dem breiteren Ökosystem und der Branche insgesamt zugute kommt.

Das Hauptziel der Secured-Core-PC-Initiative besteht darin, sicherzustellen, dass Kunden Zugriff auf einige der modernsten Sicherheitsfunktionen haben, die für Windows-PCs verfügbar sind. Mit einigen dieser Firmwareänderungen befinden wir uns einen Schritt weiter auf dem Weg zur Verwirklichung dieses Ziels und dies wird durch die Aktualisierung der Firmware-Schutzanforderungen von Secured-Core-PCs unterstrichen. Weitere Informationen zu Secured-Core-PCs finden Sie hier.