In the InsydeH2O framework, used by many manufacturers to create UEFI firmware for their equipment (the most common implementation of the UEFI BIOS), 23 vulnerabilities have been identified that allow code to be executed at the SMM (System Management Mode) level, which has a higher priority (Ring -2) than the hypervisor mode and zero protection ring, and having unlimited access to all memory. The issue affects UEFI firmware used by manufacturers such as Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel, and Bull Atos.
Exploitation of vulnerabilities requires local access with administrator rights, which makes problems in demand as second-tier vulnerabilities, applied after exploiting other vulnerabilities in the system or using social engineering methods. Access at the SMM level allows you to execute code at a level that is not controlled by the operating system, which can be used to modify firmware and leave hidden malicious code or rootkits in SPI Flash that are not detected from the operating system, as well as to disable verification at the boot stage (UEFI Secure Boot , Intel BootGuard) and attacks on hypervisors to bypass mechanisms for checking the integrity of virtual environments.
Vulnerabilities can be exploited from the operating system using unverified SMI (System Management Interrupt) handlers, as well as at the stage before the operating system is executed during the initial stages of booting or returning from hibernation. All vulnerabilities are caused by memory problems and are divided into three categories:
- SMM Callout - execution of your code with SMM rights by redirecting the execution of SWSMI interrupt handlers to code outside of SMRAM;
- Memory corruption that allows an attacker to write their data to SMRAM, a special isolated memory area in which code with SMM rights executes.
- Memory corruption in code running at the DXE (Driver eXecution Environment) level.
To demonstrate the principles of organizing an attack, an example of an exploit has been published that allows, through an attack from the third or zero protection ring, to gain access to the DXE Runtime UEFI and execute your code. An exploit manipulates a stack overflow (CVE-2021-42059) in the UEFI DXE driver. During the attack, an attacker can place his code in a DXE driver that remains active after restarting the operating system, or make changes to the NVRAM area in SPI Flash. During execution, malicious code can make changes to privileged memory areas, modify EFI Runtime services, and affect the boot process.
Source: opennet.ru