Im InsydeH2O-Framework, das von vielen Herstellern zum Erstellen von UEFI-Firmware für ihre Geräte verwendet wird (die häufigste Implementierung des UEFI-BIOS), wurden 23 Schwachstellen identifiziert, die die Ausführung von Code auf der SMM-Ebene (System Management Mode) ermöglichen höhere Priorität (Ring -2) als der Hypervisor-Modus und ein Null-Ring-Schutz sowie uneingeschränkter Zugriff auf den gesamten Speicher. Das Problem betrifft UEFI-Firmware, die von Herstellern wie Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel und Bull Atos verwendet wird.
Die Ausnutzung von Schwachstellen erfordert einen lokalen Zugriff mit Administratorrechten, weshalb die Probleme als Schwachstellen der zweiten Stufe beliebt sind, die nach der Ausnutzung anderer Schwachstellen im System oder dem Einsatz von Social-Engineering-Methoden genutzt werden. Durch den Zugriff auf der SMM-Ebene können Sie Code auf einer Ebene ausführen, die nicht vom Betriebssystem kontrolliert wird. Dies kann dazu verwendet werden, Firmware zu ändern und versteckten Schadcode oder Rootkits im SPI-Flash zu belassen, die vom Betriebssystem nicht erkannt werden um die Überprüfung beim Booten zu deaktivieren (UEFI Secure Boot, Intel BootGuard) und Angriffe auf Hypervisoren, um Mechanismen zur Überprüfung der Integrität virtueller Umgebungen zu umgehen.
Die Ausnutzung von Schwachstellen kann vom Betriebssystem aus mit nicht verifizierten SMI-Handlern (System Management Interrupt) sowie in der Vorausführungsphase des Betriebssystems während der Anfangsphasen des Bootens oder der Rückkehr aus dem Ruhemodus erfolgen. Alle Schwachstellen werden durch Speicherprobleme verursacht und sind in drei Kategorien unterteilt:
- SMM-Callout – Ausführung Ihres Codes mit SMM-Rechten durch Umleitung der Ausführung von SWSMI-Interrupt-Handlern an Code außerhalb des SMRAM;
- Speicherbeschädigung, die es einem Angreifer ermöglicht, seine Daten in SMRAM zu schreiben, einen speziellen isolierten Speicherbereich, in dem Code mit SMM-Rechten ausgeführt wird.
- Speicherbeschädigung im Code, der auf der DXE-Ebene (Driver eXecution Environment) ausgeführt wird.
Um die Prinzipien der Organisation eines Angriffs zu demonstrieren, wurde ein Beispiel für einen Exploit veröffentlicht, der es ermöglicht, durch einen Angriff aus dem dritten oder nullten Schutzring Zugriff auf das DXE Runtime UEFI zu erhalten und Ihren Code auszuführen. Der Exploit manipuliert einen Stapelüberlauf (CVE-2021-42059) im UEFI DXE-Treiber. Während des Angriffs kann der Angreifer seinen Code im DXE-Treiber platzieren, der auch nach einem Neustart des Betriebssystems aktiv bleibt, oder Änderungen im NVRAM-Bereich des SPI-Flashs vornehmen. Während der Ausführung kann Angreifercode Änderungen an privilegierten Speicherbereichen vornehmen, EFI-Laufzeitdienste modifizieren und den Startvorgang beeinflussen.
Source: opennet.ru