Verringerung der Firmwareangriffsfläche (FASR)
Im Oktober 2019 arbeitete Microsoft eng mit unseren OEM- und Silicon-Partnern zusammen, um Secured-Core-PCs auf den Markt zu bringen. Diese Geräte verfügen über tief integrierte Hardware, Firmware und Software, um eine verbesserte Sicherheit für die Geräte, Identität und Daten zu gewährleisten. Eine der wichtigsten Sicherheitssäulen von Secured-Core-PCs ist es, Firmwareschutz für Geräte zu bieten. Ein grundlegendes hardwarebasiertes Feature, das erforderlich ist, um diese Säule zu erfüllen, ist Dynamic Root of Trust for Measurement (D-RTM). Aufgrund der Abhängigkeit vom zugrunde liegenden Chipsatz, die diese Funktion unterstützen, gibt es derzeit jedoch nicht viele Geräte, die D-RTM anbieten, was unsere Verpflichtung behindert, eine hohe Sicherheitslatte für alle Windows-Geräte zu erhöhen und aufrechtzuerhalten.
Es kann mehr getan werden, um den Sicherheitsstatus aller Windows-Geräte zu verbessern, einschließlich solcher ohne D-RTM. Um diese Lücke zu schließen, hat Microsoft begonnen, mit Partnern zusammenzuarbeiten, um die Kompatibilitätsprobleme zu beheben, die verhindert haben, dass Speicherschutz in UEFI-Firmware angewendet wird, indem eine Reihe von Open-Source-SMM-Sicherheitsverbesserungen entwickelt wurde, um OEMs zusätzliche Flexibilität zu bieten.
Um diese Verpflichtung zur Firmwaresicherheit widerzuspiegeln, haben wir einen neuen Ansatz identifiziert, um sicherzustellen, dass Geräte die Firmwareschutzanforderungen von PCs mit geschützten Kernen erfüllen können.
ÜBERSICHT ÜBER FASR
Für PCs mit geschützten Kernen ohne hardwarebasierte D-RTM-Funktionen müssen wir einen kleinen Satz von Firmwarekomponenten definieren, die eine reduzierte Angriffsfläche darstellen und im Betriebssystem nachgewiesen werden können. Dieser Ansatz wird als Firmware Attack Surface Reduction (FASR) bezeichnet. Damit DIE FASR-basierte Firmware auf PCs verschiedener Anbieter skaliert werden kann, musste ein neuer Ansatz für den Firmwarestartprozess definiert werden.
FASR unterstützt zwei Startpfade:
Zertifizierter Startpfad:
Nur Code, der von Microsoft vertrauenswürdig, signiert und integriert ist, darf ausgeführt werden.
Eine Manipulation des Startpfads kann vom Betriebssystem erkannt werden.
Die folgende Abbildung zeigt den FASR S-RTM-Startflow im zertifizierten Startpfad. Dieser Startpfad verhindert, dass unerwarteter Plattformfirmwarecode ausgeführt wird. Es verwendet jedoch einige plattformspezifische Daten, die vom benutzerdefinierten Startpfad bereitgestellt werden. Das folgende Diagramm zeigt den FASR-Startflow im zertifizierten Startpfad.
Benutzerdefinierter Startpfad: Der gesamte Plattformfirmwarecode kann ausgeführt werden. Startkritische Informationen für einen bestimmten OEM/eine bestimmte Plattform werden im benutzerdefinierten Startpfad in Daten konvertiert und vom zertifizierten Startpfad verwendet, um das System für diesen Startpfad ordnungsgemäß zu konfigurieren. Das folgende Diagramm zeigt den FASR-Startflow im benutzerdefinierten Startpfad.
Ein FASR-Gerät, das für die Konformität von Secured-Core-PCs aktiviert ist, verwendet standardmäßig den zertifizierten Startpfad, es sei denn, es ist ein Ereignis aufgetreten, das dazu führt, dass der Start zu einem frühen Zeitpunkt des Firmwarestartvorgangs zum benutzerdefinierten Startpfad wechselt. Beispiele für solche Ereignisse sind ein Firmwareupdate, der Benutzer hat eine Firmwarebenutzeroberfläche angefordert, oder der Benutzer hat sich entschieden, "Secured-Core-PC" zu deaktivieren, was bedeutet, dass er immer im benutzerdefinierten Startpfad gestartet wird, bis er wieder aktiviert wird.
Beachten Sie, dass der benutzerdefinierte Start verwendet werden kann, 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 Secured-Core-PC-kompatibel.
Um die Sicherheitstechnologien hinter FASR besser zu verstehen, möchten wir ihnen einen kurzen Überblick über den Windows-Startprozess geben.
Windows-Startprozess
Vertrauensbasis
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, wenn der Start fortschreitet. Jeder Codesatz überprüft den nächsten Codesatz, der eine Vertrauenskette bildet. Wenn die UEFI-Firmware die Kontrolle erhält, folgt sie dem Secure Boot-Standard der Überprüfung von Softwaresignaturen, um die Vertrauenskette bis zum Betriebssystem fortzusetzen. Anschließend setzt das Windows-Startladeprogramm die Vertrauenskette mit dem vertrauenswürdigen Start fort, wodurch jede andere Betriebssystemkomponente im Startprozess überprüft wird, bevor sie geladen wird.
Im Allgemeinen versuchen Angreifer, so früh wie möglich die Kontrolle im Startprozess zu erlangen, bevor Sicherheitsfeatures und Sperren aktiviert werden, die zum Schutz des Systems beitragen. Wenn das System aus dem Zurücksetzen geholt wird, muss der anfängliche Codesatz in einer Vertrauensstellung verankert werden. Die Hardwareüberprüfungstechnologie, die die Rolle für diese frühe Codeüberprüfung erfüllt, wird als Vertrauenswurzel bezeichnet. Obwohl die genauen Details je nach Hardwareanbieter variieren, basieren alle Vertrauenswurzeln in der Regel auf unveränderlicher Hardware oder ROMs im SOC.
Kontrollierter Start
Der sichere Start, der in einem Vertrauensstamm verankert ist, stellt sicher, dass die digitale Signatur der gesamten Firmware überprüft wird. Es ist jedoch auch wünschenswert, einen Datensatz zu haben, der genau zeigt, welche Firmware ausgeführt wurde. Das Windows-Hardwarekompatibilitätsprogramm erfordert, dass alle Windows 10 und Windows 11 PCs einen Chip enthalten, der als Trusted Platform Module (TPM) bezeichnet wird. Das TPM enthält Speicherspeicherorte, die als Plattformkonfigurationsregister (Platform Configuration Registers, PCRs) bezeichnet werden. Jede PCR enthält den Hash für einen Typ von Code und/oder Daten, die während des Starts geladen werden, z. B. Firmwarecode auf dem nicht flüchtigen Speichergerät (z. B. SPI-Flash), Options-ROMs von PCI-Geräten oder das Betriebssystem-Startladeprogramm. Die Größe eines Werts, der in einer PCR gespeichert werden kann, wird durch die Digestgröße des unterstützten Hashingalgorithmus bestimmt. Beispielsweise kann eine SHA-1-PCR 20 Bytes speichern, während eine SHA-2-PCR 32 Bytes speichern kann. Mehrere PCRs, die demselben Hashingalgorithmus zugeordnet sind, werden als Bank bezeichnet. Die TCG-PC-Client-TPM-Profilspezifikation definiert die Aufnahme von mindestens einer PCR-Bank mit 24 Registern.
Wenn ein TPM vorhanden ist, kann jede Firmwarekomponente auch die entsprechende PCR 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 ist, wobei der aktuelle PCR-Wert verwendet wird, der mit dem neuen Code oder dem neuen Datenargument als Eingabe verkettet ist. Das Ergebnis ist, dass PCRs nach dem Startvorgang überprüft werden können, um zu bestimmen, was ausgeführt wurde. Dadurch kann Software im Betriebssystem erkennen, ob sich der Startvorgang vom vorherigen Startvorgang unterscheidet. In einer sicherheitsrelevanten Umgebung kann das Betriebssystem über den genauen Satz von Codemessungen informiert werden, die in bestimmten PCRs erwartet werden, um die Ausführung von unerwartetem Firmwarecode zu erkennen. Da die ersten 16 PCRs in einer Bank nur durch Zurücksetzen des gesamten TPM zurückgesetzt werden können, sind sie vertrauenswürdig und der bevorzugte Speicherort für wichtige Messungen im TPM.
Vertrauensbasis für die Messung
Nachdem wir nun die Rolle eines Vertrauensstamms und die Verwendung des gemessenen Starts untersucht haben, werden wir uns zwei gängige Ansätze zum Einrichten einer Vertrauensbasis für die Meldung einer Messkette an das TPM ansehen: statisch und dynamisch.
Ein statischer Vertrauensstamm für die Messung (S-RTM) richtet die Vertrauensstellung beim Zurücksetzen des Systems ein und erfordert, dass die Vertrauensstellung während des gesamten Startprozesses beibehalten wird. Wenn die Vertrauensstellung zu einem beliebigen Zeitpunkt im Startvorgang gefährdet ist, ist sie bis zum Zurücksetzen des Systems unwiederbringlich. Das folgende Diagramm veranschaulicht, wie S-RTM im zertifizierten Startpfad verwendet wird.
Im Gegensatz dazu vertraut Dynamic Root of Trust for Measurement (D-RTM) nur einem kleinen Teil des Firmwarecodes der frühen Chipsatzinitialisierung sowie einem Hardware-Agent, der verwendet wird, um die Vertrauensstellung während des Startvorgangs dynamisch wie herzustellen. Das System kann zunächst mit nicht vertrauenswürdigem Firmwarecode gestartet werden, aber – kurz nach dem Start – wird in einen vertrauenswürdigen Zustand zurückgesetzt, indem es die Kontrolle über alle CPUs übernimmt und sie in einen bekannten und gemessenen Pfad zwingt. 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, erfordert jedoch Software, um den Während des gesamten Startvorgangs ausgeführten Code besser zu berücksichtigen. D-RTM erfordert spezielle Hardwarefunktionen, ermöglicht es der Software jedoch, während der Lebensdauer des Systems dynamisch in einen vertrauenswürdigen Zustand zu starten.
Windows Secured-Core-PCs haben einen D-RTM in Secure Launch verwendet, um der vielzahl von Systemherstellern die Flexibilität zu ermöglichen, einzigartige Features und Erfahrungen 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 Wiederherstellen einer bekannten Systemumgebung.
In der Vergangenheit konnte S-RTM in mehr Geräten implementiert werden, da es nicht von speziellen Hardwarefunktionen abhängig war, um den Sicherheitsstatus des Systems zu überprüfen, aber das Betriebssystem verfügte nicht über eine zuverlässige Methode, um zu bestätigen, dass es den auf einem bestimmten Windows-Gerät gemeldeten Messungen mit S-RTM vertrauen konnte.
Verbesserungen der Firmwaresicherheit
Minimieren der Firmwarekomponenten im Startpfad des Betriebssystems
Eine Möglichkeit, S-RTM-Messungen zu vertrauen, besteht darin, die für die Ausführung zulässigen Firmwarekomponenten auf einen minimalen Satz zu reduzieren. Wenn alle Geräte, die S-RTM verwenden, denselben Satz von Firmwarekomponenten verwenden, müsste das Betriebssystem nur einem einzelnen Satz erwarteter PCR-Werte für diese bekannten und vertrauenswürdigen Komponenten vertrauen. Bei diesem SRTM-basierten Ansatz kann davon ausgegangen werden, dass ein Gerät die Firmwareschutzanforderungen von Secured-Core-PCs erfüllt hat, wenn der Satz der Startfirmware überprüft wird, dass er nur von Microsoft signierte Software enthält, die von Windows bestätigt werden kann. Um besser zu verstehen, wie sich diese Firmwarekomponenten von denen bei einem normalen PC-Start unterscheiden, sehen wir uns den Startvorgang vor und nach an.
Aufgrund der Flexibilität und des umfangreichen Features der modernen PC-Firmware führt der Code, der vor dem Betriebssystem ausgeführt wird, zu einer erhöhten Angriffsfläche. Das folgende Diagramm zeigt ein Beispiel für einen herkömmlichen S-RTM-Startflow.
Die Hauptaufgaben der Firmware während des Startvorgangs können erheblich vereinfacht werden, um:
Plattformspezifisch: Funktionalität, die nur für den spezifischen Hardwareentwurf der Plattform gilt.
Nicht plattformspezifisch: Funktionalität, die branchenüblich ist und für andere Hardware üblich ist.
Eine relativ kleine Teilmenge moderner Firmware ist in der Regel plattformspezifisch. Ein Großteil des Firmwareinfrastrukturcodes, der allgemeine Aufgaben wie die Zuweisung von Arbeitsspeicher, das Senden von Firmwaretreibern, die Behandlung von Ereignissen usw. ausführt, ist zwischen allen (oder den meisten) UEFI-basierten Systemen identisch. Die Firmware-Binärtreiber für diese Aufgaben können PCs wiederverwendet werden. Darüber hinaus ermöglichen branchenübliche Hardwarespezifikationen und Schnittstellen gängige Firmwaretreiber die Initialisierung von Festplatten, USB-Controllern und anderen Peripheriegeräten. Die binären Firmwaretreiber für diese Hardware können auch PCs wiederverwendet werden. Zusammenfassend lässt sich sagen, dass PCs mit einem sehr minimalen Satz gängiger Firmwaretreiber gestartet werden können.
Die Reduzierung der Gesamtzahl der während des Startvorgangs geladenen Firmwaretreiber kann zu anderen Vorteilen führen:
Verbesserte Startzeit
Verringerte Anbieterkoordination für Updates
Reduzierte Fehlerbelichtung
Verringerte Angriffsfläche
Überprüfung des FASR-Startpfads und Konformität mit gesicherten Kernen
Damit ein FASR-System die Firmwareschutzanforderungen von Secured-Core-PCs erfüllt, muss es im zertifizierten Startpfad gestartet sein. Die FASR-Firmware erleichtert dies, indem dem Betriebssystem ein von Microsoft signiertes Manifest namens FASR-Manifest (gemessen in das TPM) bereitgestellt wird, das die erwarteten PCR-Werte für die Startsequenz des Moduls auf dem zertifizierten Pfad enthält. Dies kann mit der tatsächlichen Startsequenz verglichen werden, die im zertifizierten Pfad aufgetreten ist. Wenn diese Messungen übereinstimmen, wird davon ausgegangen, dass das System die Firmwareschutzanforderungen des Secured-Core-PC-Programms erfüllt hat. Jede Abweichung von der erwarteten, zertifizierten Startpfadsequenz führt zu unerwarteten Messungen in den PcRs (Platform Configuration Registers) des TPM, die vom Betriebssystem erkannt werden.
Darüber hinaus gibt Windows hypervisorgeschützte Geheimnisse nur nach erfolgreicher Überprüfung des signierten FASR-Manifests mit den während des aktuellen Starts aufgezeichneten Messungen frei. Wenn bei einem zertifizierten Startpfad oder einem Kapselupdate das FASR-Manifest nicht vorhanden ist, die Signaturüberprüfung fehlschlägt oder ein PCR-Konflikt auftritt, und die VSM-Geheimnisse werden nicht entsiegelt oder migriert.
Wie DIE FASR-Firmware Speicherschutz und SMM behandelt
Nachdem nun eine einzelne von Microsoft signierte Binärdatei mit einem minimalen Satz von Funktionen definiert wurde, kann sie die grundlegenden, aber fehlenden Firmwaresicherheitsschutze enthalten, die Microsoft mit Partnern auf den Markt bringt. Der zertifizierte Startpfad muss mindestens die folgenden Anforderungen erfüllen:
Code liest/schreibt nicht in NULL/Seite 0
Bildcode und Datenabschnitte werden getrennt
Bildabschnitte werden an einer Seitengrenze (4 KB) ausgerichtet
Daten werden nur zu Datenspeichertypen und Code zu Codespeichertypen zugeordnet.
Codeimages werden nicht aus Code geladen, der als UEFI-Binärdateien verteilt wird (nur die angegebenen Verteiler).
Code bleibt innerhalb der Grenzen von zugeordneten Speicherpuffern mit Schutzseiten um Seitenzuordnungen
Stapelüberlauf kann erkannt werden
Code wird nicht aus dem Stapel ausgeführt.
Die /NXCOMPAT-DLL-Eigenschaft ist festgelegt, um NX-Schutz zu aktivieren.
Options-ROMs, UEFI-Anwendungen und UEFI-Treiber von Drittanbietern wurden häufig nicht anhand dieser Anforderungen erstellt oder überprüft. Daher würden sie nicht im zertifizierten Startpfad ausgeführt. Der benutzerdefinierte Startpfad kann optional auswählen, um die erforderliche Schutzstufe zu senken, aber dieser Startpfad wird vom Betriebssystem nicht als geschützter Kern-PC-konform betrachtet.
Systemverwaltungsmodus (SMM)
SMM ist ein spezieller Prozessorbetriebsmodus in der x86-Architektur. Dies stellt eine einzigartige Herausforderung für die Systemsicherheit dar, da der in der SMM-Umgebung ausgeführte Code für das Betriebssystem undurchsichtig ist und in der Regel auf der höchsten Berechtigungsstufe (manchmal auch als "Ring -2" bezeichnet) jeder Software auf dem Hostprozessor ausgeführt wird. Nach der Eingabe konfiguriert SMM seine eigene Umgebung, indem die Seitentabelle, die Interrupt Dispatch Table (IDT) und andere Systemstrukturen eingerichtet werden. Daher stellt SMM eine erhebliche Angriffsfläche dar, die durch bösartigen Code genutzt werden könnte, um den durch virtualisierungsbasierte Sicherheit (VBS) aktivierten Betriebssystemschutz zu kompromittieren oder zu umgehen. Um die von SMM ausgehende Gefahr zu minimieren, können die Funktionen in SMM wie folgt konzeptionell in die SMM-Kerninfrastruktur und die SMM-Treiber aufgeteilt werden:
SMM-Kern: Code, der allen SMM-Implementierungen gemeinsam ist, die Architektur- und Infrastrukturaufgaben ausführen
SMM-Treiber: Code, der zum Ausführen einer plattformspezifischen Aufgabe in SMM geschrieben wird
Einige wichtige Momente im SMM-Lebenszyklus sind die folgenden:
Wenn die SMM-Basis (oder der Kern) eingerichtet wird– die SMM-Initial Program Load (IPL)
Beim Laden von SMM-Treibern – SMM-Treiberverteilung genannt
Wenn der Eintrag zu SMM erfolgt – über einen Systemverwaltungsunterbrechung (System Management Interrupt, SMI)
SMM Initial Program Load (IPL)
Die CPU verfügt über spezielle Features, die SMM-Code seine hohe Berechtigung gewähren und ihn schützen. Beispielsweise wird ein Mechanismus zum Eingeben von SMM über Software- oder Hardwareereignisse definiert, eine CPU-Anweisung wird verwendet, um von SMM zurückzugeben, und mehrere Register sind definiert, um den Zugriff zu steuern und die Konfiguration von SMM zu sperren. Viele dieser Steuerregister werden durch den SMM-IPL-Code konfiguriert, um den Zugriff auf den Speicherbereich zu beschränken, in dem SMM-Code und -Daten gespeichert werden (als Systemverwaltungs-RAM oder SMRAM bezeichnet).
Da sich der SMRAM-Bereich im Hauptspeicher (DRAM) befindet, kann er erst eingerichtet werden, wenn DRAM während des Startvorgangs aktiviert ist. DRAM-Aktivierungsverfahren variieren je nach Siliconanbieter, aber einige Megabyte code können direkt aus dem CPU LLC-Cache ausgeführt werden (einschließlich des Codes, der DRAM initialisiert), bevor der Hauptspeicher verfügbar ist.
DIE FASR-Firmware bringt den SMM-IPL-Punkt früher beim Start als die meisten anderen Systeme. Dies verringert die Möglichkeit, dass ein Angreifer diesen Prozess unterminieren und die Kontrolle über das System übernehmen kann, bevor SMM eingerichtet wird. Um diese und andere Verbesserungen an SMM in DER FASR-Firmware besser zu verstehen, müssen wir mehr über den Firmwarestartprozess erfahren.
Start der Plattforminitialisierung (PI) in UEFI Firmware
Die 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 andere Spezifikation namens Platform Initialization (PI) Specification definiert die Art und Weise, wie Firmwaretreiber erstellt werden, und erläutert den Startprozess selbst. Auf einer allgemeinen Ebene kann die UEFI-Spezifikation als eine der Standardisierungen betrachtet werden, die es einem einzelnen Windows-Image ermöglicht, mit so vielen verschiedenen Geräten zu arbeiten, und die PI-Spezifikation kann als eine der Standardisierungen betrachtet werden, die es ermöglicht, so viele Firmwareimages von verschiedenen Hardwareanbietern zusammenzuarbeiten. Beide Spezifikationen werden vom UEFI-Forum verwaltet.
Die PI-Spezifikation definiert Startphasen und welche Treiber in die Startphasen geschrieben werden. Während des Firmwarestarts wird jede Phase an die nächste phase weitergeleitet, 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 wie folgt zusammengefasst werden:
SEC: Erhalten Sie die Kontrolle über den CPU-Reset-Vektor und wechseln Sie von der Assembly zu C-Code, um PEI zu laden.
PEI: Initialisieren des Systemzustands zum Laden von DXE und Initialisieren von DRAM
DXE: Ausführen der verbleibenden Systeminitialisierung, einschließlich der Bereitstellung der Unterstützung, die BDS zum Laden eines Betriebssystems benötigt
BDS: Ermitteln sie die Startoption für den aktuellen Start (z. B. Betriebssystem-Bootloader), und versuchen Sie, diese Option zu starten.
Betriebssystem – Der Betriebssystemkern
Schützen der SMM-Initial Program Load (IPL)
Die herkömmliche Firmware mit UEFI PI-Spezifikation lädt die SMM IPL in der DXE-Startphase. DIE 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 die Verlagerung des SMM IPL von DXE auf PEI wird die gesamte DXE-Phase (die eine viel größere und reichhaltigere Umgebung als PEI ist) aus dem TCB entfernt. Das folgende Diagramm zeigt die zuvor im UEFI-Startvorgang verschobene SMM-IPL.
Der PEI- und DXE-Code werden bei Ring 0 ausgeführt und nicht (mit wenigen Ausnahmen) im Betriebssystem beibehalten. SMM-Code wird mit einer viel höheren Berechtigung als Ring 0 (und dem Hypervisor) ausgeführt und bleibt im Betriebssystem erhalten, sodass die Gesamte angriffsfläche des Systems verringert wird, wenn eine DXE-Sicherheitslücke keine Auswirkungen auf die Einrichtung von SMM hat. Da SMM außerdem früher im Startvorgang gestartet wird, können die Zum Schutz von SMM festgelegten Sperrbits früher beim Start aktiviert werden, wodurch das Fenster eines Angreifers zur Kompromittierung von SMM weiter minimiert wird.
Schützen des Versandprozesses des SMM-Treibers
Innerhalb der PI-Spezifikation werden zwei SMM-Modi definiert: Traditionelle MM und eigenständige MM. Herkömmliche MM entspricht dem SMM-Softwaremodell, das in der Vergangenheit in PI-kompatibler Firmware verwendet wurde, was den Großteil der UEFI-Firmware in der Branche darstellt. Eigenständiger MM-Modus ist ein relativ neuer Modus, der das historische Modell überarbeitet, um die Sicherheit der SMM-Umgebung zu verbessern und häufige Fehler bei herkömmlichen MM-Implementierungen zu verhindern, die im Laufe der Jahre zu zahlreichen Portabilitäts- und Sicherheitsproblemen geführt haben.
DIE FASR-Firmware wird ausschließlich im eigenständigen MM-Modus ausgeführt. Dadurch kann die FASR-Firmware einen disziplinierten Ansatz für die Softwareausführung in SMM verfolgen. So viele SMM-basierte Sicherheitsrisiken sind heute auf schlechte Methoden zurückzuführen, die in SMM-Code in herkömmlichem MM zulässig sind und einfach in eigenständigem MM entfernt werden können. Auf hoher Ebene geschieht dies, weil ein SMM-Treiber im herkömmlichen MM-Modell zweimal vom DXE-Dispatcher im Ring 0 und erneut vom SMM-Dispatcher in SMM verteilt wird. Dies bietet dem in der DXE-Umgebung ausgeführten Treibercode ausreichend Gelegenheit, Zeiger auf Ressourcen außerhalb von SMRAM zwischenzuspeichern, auf die sie nach der Rückkehr des Einstiegspunkts nicht mehr zugreifen sollten. Angriffe, die vom SMM-Code abhängen, um Code außerhalb von SMM aufzurufen, werden häufig als "SMM-Legendenangriffe" bezeichnet.
Schützen des Eintrags in SMM
Daten werden über eine Struktur namens "Kommunikationspuffer" an einen SMI-Handler übergeben. Der SMI-Handler ist dafür verantwortlich, zu überprüfen, ob die Daten bestimmte Anforderungen an ihrem Einstiegspunkt erfüllen. Die Windows SMM-Sicherheitsminderungstabelle (Windows SMM Security Mitigation Table, WSMT) ist ein Mechanismus, der verwendet wird, um die Bedrohung zu minimieren, die nicht überprüfte SMI-Handler für virtualisierungsbasierte Sicherheit im Betriebssystem darstellen. Microsoft hat Code zum TianoCore-Projekt beigetragen, um die Überprüfung des Kommunikationspuffers zu verbessern. Zusätzlich zur Nutzung dieser beiden Techniken implementiert FASR-Code auch strenge Speicherzugriffsschutze, sodass SMM-Code nur auf explizit zulässige Speicherbereiche zugreifen kann.
Verwaltungsmodus-Supervisor (MM Supervisor)
Der SMM-Kerncode ist üblich und wird mit minimalen bis keiner Änderung zwischen den Systemen freigegeben. Die von SMM auferlegte Angriffsfläche kann durch die Einführung der Rechtetrennung in die SMM-Umgebung erheblich reduziert werden. Aus diesem Grund enthält die FASR-Firmware einen SMM-Supervisor, der in eigenständigem MM ausgeführt wird. Dies führt zu einer klar definierten SMM-Umgebung mit einem minimalen TCB, deren Berechtigungsstufen bei der Erstellung erzwungen werden. Der MM Supervisor legt Einschränkungen für E/A-Portzugriffe, MSR-Zugriffe (Model Specific Register), MMIO-Zugriff, CPU-Speicherstatuszugriff und zulässige Anweisungen in der SMM-Umgebung fest. Eine SMM Supervisor-Richtlinie wird verwendet, um die genauen Details zu konfigurieren, welche Hardwareressourcen eingeschränkt werden sollen, und diese genauen Details können sich je nach Siliciumgeneration ändern.
Die Richtlinie wurde kürzlich zu einem Deny-by-Default-Ansatz übergegangen, der die Hardwareressourcen, die für Code außerhalb des SMM-Supervisors verfügbar sind, erheblich reduziert. Dieser Supervisor arbeitet ohne Hardwareabhängigkeit von Hardwarefunktionen, die bei modernen PCs nicht üblich sind.
Der MM-Supervisor wird in FASR als Open-Source-Instanz verwendet und ist im Project Mu MM Supervisor Repository verfügbar.
FASR-Systemkonformität mit den Anforderungen für gesicherte Kern-PCs
Die folgende Tabelle zeigt die allgemeinen Sicherheitspfeiler oder Ziele von Secured-Core-PCs und wie FASR-Systeme, die im zertifizierten Pfad gestartet werden, die Anforderungen von Secured-Core-PCs erfüllen können:
| Sicherheitsvorteile | Sicherheitsfeatures auf PCs mit gesichertem Kern |
|---|---|
| Erstellen eines hardwaregestützten Vertrauensstamms | Sicherer Start |
| Trusted Platform Module 2.0 | |
| Direct Memory Access (DMA)-Schutz | |
| Schutz vor Angriffen auf Firmwareebene (siehe Hinweis unten) | Systemüberwachung Secure Launch (D-RTM) oder S-RTM (FASR FW) |
| SMM-Isolation (System Management Mode) oder eigenständige MM mit MM Supervisor (FASR FW) | |
| Schützen Sie das Betriebssystem vor der Ausführung von nicht verifiziertem Code | Speicherintegrität (auch bekannt als HVCI) |
| Bereitstellen einer erweiterten Identitätsüberprüfung und -schutz | Windows Hello |
| Schützen wichtiger Daten bei Verlust oder Diebstahl von Geräten | BitLocker-Verschlüsselung |
Wenn das System nicht über erweiterte Sicherheitsfunktionen zur Unterstützung von D-RTM verfügt, können die Firmwareschutzanforderungen mit einer Kombination aus 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 getätigt hat, um die wachsende Zahl von Firmwareangriffen zu beheben, die heute in der 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, die wiederum dem breiteren Ökosystem und der gesamten Industrie zugute kommen.
Das Hauptziel der Initiative "Secured-Core-PC" besteht darin, sicherzustellen, dass Kunden Zugriff auf einige der fortschrittlichsten Sicherheitsfunktionen haben, die für Windows-PCs verfügbar sind. Mit einigen dieser Firmwareänderungen sind wir diesem Ziel einen Schritt näher gekommen und haben die Firmwareschutzanforderungen von Secured-Core-PCs aktualisiert, um diese Einbeziehung widerzuspiegeln. Weitere Informationen zu Secured-Core-PCs finden Sie hier.