Researchers from firmware protection company Binarly have discovered critical vulnerabilities in the UEFI firmware from InsydeH2O used by multiple computer vendors such as Fujitsu, Intel, AMD, Lenovo, Dell, ASUS, HP, Siemens, Microsoft, and Acer.
UEFI (Unified Extensible Firmware Interface) software is an interface between a device’s firmware and the operating system, which handles the booting process, system diagnostics, and repair functions.
In total, Binarly found 23 flaws in the InsydeH2O UEFI firmware, most of them in the software's System Management Mode (SMM) that provides system-wide functions such as power management and hardware control.
SMM’s privileges exceed those of the OS kernel, so any security issues in this space can have severe consequences for the vulnerable system.
More specifically, a local or remote attacker with administrative privileges exploiting SMM flaws could perform the following tasks:
- Invalidate many hardware security features (SecureBoot, Intel BootGuard)
- Install persistent software that cannot be easily erased
- Create backdoors and back communications channels to steal sensitive data
The 23 flaws are tracked as: CVE-2020-27339, CVE-2020-5953, CVE-2021-33625, CVE-2021-33626, CVE-2021-33627, CVE-2021-41837, CVE-2021-41838, CVE-2021-41839, CVE-2021-41840, CVE-2021-41841, CVE-2021-42059, CVE-2021-42060, CVE-2021-42113, CVE-2021-42554, CVE-2021-43323, CVE-2021-43522, CVE-2021-43615, CVE-2021-45969, CVE-2021-45970, CVE-2021-45971, CVE-2022-24030, CVE-2022-24031, CVE-2022-24069.
Of the above, CVE-2021-45969, CVE-2021-45970, and CVE-2021-45971 in the SMM are rated with critical severity, receiving a 9.8 score out of 10.
Ten of the discovered vulnerabilities could be exploited for privilege escalation, twelve memory corruption flaws in SMM, and one is a memory corruption vulnerability in InsydeH2O's Driver eXecution Environment (DXE).
“The root cause of the problem was found in the reference code associated with InsydeH2O firmware framework code,” explains Binarly’s disclosure report.
“All of the aforementioned vendors (over 25) were using Insyde-based firmware SDK to develop their pieces of (UEFI) firmware,” the company notes. At the moment, the U.S. CERT Coordination Center confirmed three vendors with products affected by the security issues found in the InsydeH2O firmware: Fujitsu, Insyde Software Corporation, and Intel (only CVE-2020-5953)
Addressing the problems
Insyde Software has released firmware updates to fix all identified security vulnerabilities and published detailed bulletins to assign severity and description for every flaw.
However, these security updates need to be adopted original equipment manufacturers (OEMs) and pushed to affected products.
The entire process will take a considerable amount of time for the security updates to reach end-users. It is unlikely that all issues will be addressed in all impacted products, though, because some devices have reached end-of-life and are no longer supported, while others may become obsolete before a patch is ready for them.
At the time of writing, only Insyde, Fujitsu, and Intel have confirmed themselves as affected by the flaws, while Rockwell, Supermicro, and Toshiba were confirmed as not impacted. The rest are investigating.
Binarly credits Fujitsu’s incident response team for its quick reaction when receiving the vulnerability reports, and its hands-on approach in helping to scope them correctly.
If you would like to scan your system for the existence of the above flaws, Binarly has published these FwHunt rules on GitHub to assist with detection.
Comments
fromFirefoxToVivaldi - 2 years ago
The operating system should not be able to interact with UEFI in any way. UEFI should only be upgrade'able directly from within itself, with a pendrive with a new BIOS image. The current state of affairs is cancerous. Just because someone decided that people should be able to do such things as change default F1-F12 behaviour, numlock state, overclocking options, etc. from the system instead of from UEFI, we have to deal with vulnerabilities.
Similarly, UEFI should not be able to interact with the OS beyond providing performance pointers and temperature data.
GeroldM - 2 years ago
We are so in agreement about this.
Guess the biggest part of the blame can be put at the group of users we call: gamers.
A very vocal group that wishes to update anything and everything from the 'comfort' of their operating system, if that means they can get 0.5 frame per second more from their hardware.
Now the UEFI/BIOS is just part of the update cycle.
Back in the days where you needed to this manually on the computer itself (with a pendrive or even a floppy) you had far less worries about such low-level attacks. And you took the time to read what the update entailed, before applying patches willy-nilly.
Now, I don't like to live in the past and everything wasn't better way back when. But this type of attack vector should never have existed in the first place.
wackoinWaco - 2 years ago
I have an Asus laptop and I have enabled Core Isolation. Will this mitigate this potential attack?