Acer Firmware Flaw Lets Attackers Bypass Key Security Feature
The manufacturer is working to fix a vulnerability — similar to a previous problem in Lenovo laptops — that allows threat actors to modify or disable Secure Boot settings to load malware.
November 29, 2022
Acer is working to fix a firmware flaw affecting five of its laptop models. An exploit could allow attackers to disable a machine's Secure Boot settings to bypass key security measures and load malware, researchers have found.
ESET Research researcher Martin Smolar discovered the flaw, tracked as CVE-2022-4020, in the HQSwSmiDxe DXE driver on some versions of consumer Acer Aspire and Extensa notebooks. An attacker with elevated privileges can use the flaw to modify UEFI Secure Boot settings via an NVRAM variable, ESET disclosed in a series of tweets posted Nov. 28.
"#CVE-2022-4020 is found in the DXE driver HQSwSmiDxe, which checks for the 'BootOrderSecureBootDisable' NVRAM variable," according to ESET. "If the variable exists, the driver disables Secure Boot."
Secure Boot is a security feature of the Unified Extensible Firmware Interface (UEFI) 2.3.1 designed to detect tampering with boot loaders, OS files, and unauthorized option ROMs by validating their digital signatures. The feature blocks any malicious activity before it can infect the system.
By exploiting the flaw, threat actors can bypass this feature and run whatever code they want on the machine, malware or otherwise, even achieving persistence in a case in which an OS is reinstalled, the researchers said.
Different Manufacturer, Similar Security Vulnerability
Specifically, CVE-2020-4020 affects Acer Aspire A315-22, A115-21, and A315-22G, and Extensa EX215-21 and EX215-21G notebooks. The flaw creates a similar opportunity for attackers to the one caused by vulnerabilities tracked as CVE-2022-3430, CVE-2022-3431, and CVE-2022-3432 that ESET researchers found in early November in various Lenovo Yoga IdeaPad and ThinkBook devices, and subsequently detailed extensively in a series of tweets.
As in that case, ESET also reported the vulnerability to the computer manufacturer for remediation. Acer quickly responded on Nov. 29 with a security update corroborating Smolar's findings and stressing the serious nature of the flaw.
"By disabling the Secure Boot feature, an attacker can load their own unsigned malicious bootloader to allow absolute control over the OS loading process," the company said. "This can allow them to disable or bypass protections to silently deploy their own payloads with the system privileges."
Acer is working on a BIOS update to resolve the issue that it will post on the Acer Support site, and recommends that affected users update their BIOS, once available, to the latest version to resolve the problem. The patch also will be included as a critical Windows update, the company said.
Common NVRAM Variable Problem
In both the Lenovo and Acer scenarios, attackers can exploit the Acer bug by creating special NVRAM variables, the actual value of which is not important—the existence of the variable itself is the only thing an affected firmware driver checks, the researchers noted.
NVRAM variables define a name for the boot option that can be displayed to a user. The variable also contains a pointer to the hardware device and to a file on that hardware device that contains the UEFI image to be loaded.
This problem appears to be quite well known, with researchers already advising against firmware developers storing security-sensitive components in these variables. Firmware security engineer Nikolaj Schlej even tweeted a plea to firmware developers in October to "stop using common NVRAM as trusted storage" because of the security problem it poses.
"It is indeed really tempting to use NVRAM or CMOS SRAM for storing triggers for various things, but both need to be assumed being under full attacker control," he said in a response to his own tweet. "Even volatile NVRAM variables aren't completely safe because there is still a chance of incorrect attribute check."
In the case of the Lenovo flaws, it does appear that developers already were aware of the issue before it made its way into the company's laptops, as some of the affected components were only meant to be used during manufacturing and were mistakenly included in production, according to ESET.
About the Author
You May Also Like