Im InsydeH2O-Framework, das von vielen Herstellern zur Erstellung von UEFI-Firmware für ihre Geräte verwendet wird (die am weitesten verbreitete Implementierung von UEFI BIOS), wurden 23 Schwachstellen entdeckt, die eine Codeausführung im SMM (System Management Mode) ermöglichen, der eine höhere Priorität (Ring -2) hat als der Hypervisor-Modus und das Nullschutzring, mit uneingeschränktem Zugriff auf den gesamten Speicher. Das Problem betrifft die UEFI-Firmware, die von Herstellern wie Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel und Bull Atos verwendet wird.
Um Schwachstellen auszunutzen, ist lokaler Zugriff mit Administratorrechten erforderlich, was diese Probleme zu Second-Level-Schwachstellen macht, die nach der Ausnutzung anderer Schwachstellen im System oder durch Verwendung von Social Engineering-Methoden angewendet werden. Zugriff auf SMM-Ebene ermöglicht das Ausführen von Code auf einer Ebene, die nicht von dem Betriebssystem kontrolliert wird, was für das Modifizieren von Firmware und das Hinterlassen von verstecktem Malware-Code oder Rootkits im SPI Flash verwendet werden kann, die von dem Betriebssystem nicht erkannt werden, sowie zum Deaktivieren der Überprüfung während des Bootvorgangs (UEFI Secure Boot, Intel BootGuard) und Angriffe auf Hypervisoren, um die Integritätsprüfmechanismen virtueller Umgebungen zu umgehen.
Die Ausnutzung von Schwachstellen kann aus dem Betriebssystem mithilfe nicht verifiziertem SMI-Handler (System Management Interrupt) erfolgen, sowie in der Phase vor der Ausführung des Betriebssystems während der frühen Boot-Phase oder beim Aufwachen aus dem Schlafmodus. Alle Schwachstellen werden durch Probleme im Umgang mit dem Speicher verursacht und in drei Kategorien unterteilt:
- SMM Callout — Ausführung Ihres Codes mit SMM-Rechten durch Umleitung der Interrupt-Handler-Ausführung von SWSMI auf Code außerhalb von SMRAM;
- Speicherschäden, die es einem Angreifer ermöglichen, seine Daten in SMRAM, einen speziellen isolierten Speicherbereich, der Code mit SMM-Rechten ausführt, zu schreiben.
- Speicherschäden im Code, der auf DXE (Driver eXecution Environment) Ebene ausgeführt wird.
Zur Demonstration der Angriffsprinzipien wurde ein Exploit-Beispiel veröffentlicht, das es ermöglicht, durch einen Angriff aus der dritten oder nullten Schutzebene auf DXE Runtime UEFI zuzugreifen und eigenen Code auszuführen. Der Exploit manipuliert einen Stack-Überlauf (CVE-2021-42059) im UEFI DXE-Treiber. Während des Angriffs kann der Angreifer seinen Code im DXE-Treiber platzieren, der nach einem Neustart des Betriebssystems aktiv bleibt, oder Änderungen im NVRAM-Bereich im SPI Flash vornehmen. Im Verlauf der Ausführung kann der Code des Angreifers Änderungen in privilegierten Speicherbereichen vornehmen, EFI Runtime-Dienste modifizieren und den Bootprozess beeinflussen.
Quelle: opennet.ru
