.webp)
The Binarly security research team continues to find evidence of repeatable failures in the firmware development ecosystem, exposing critical vulnerabilities related to the ecosystem that impact the entire industry rather than just a single vendor.
In our latest research project, we provide an in-depth look at some of the vulnerabilities we discussed at the Black Hat 2022 conference affecting American Megatrends (AMI) based devices (the majority of enterprise device vendors). In previous posts, we covered the supply chain problems linked to Intel, AMD, Insyde and AMI vulnerabilities when the patch cycles from different vendors create security gaps that leave enterprise devices vulnerable for months (sometimes years) in the field. Just last week, we discussed the problems associated with HP devices and the recently disclosed vulnerabilities (“Binarly Finds Six High Severity Firmware Vulnerabilities In HP Enterprise Devices").
Take for example, BRLY-2022-009, which as of the publication of this blog still affects Dell, Fujitsu, Lenovo, and Star Labs enterprise devices as shown in the figure below.
In many cases, firmware is a single point of failure between all the layers of the supply chain and the endpoint customer device.
The complexity of the firmware supply chain leads to an almost infinite source of vulnerabilities. Unfortunately, most outsourcing companies developing firmware code for major device vendors do not have product security teams or sometimes even a single employee dedicated to mitigating security risks. The majority of security practices revolve around the compliance checklists with poorly configured code-level static analysis tools and running antivirus scans of the entire code base snapshot before release. This fundamental misunderstanding of design failures leads to an expansion of code complexity and keeps devices in a perpetual state of exposure.
The vulnerabilities in the figure below have high-severity impact and can be exploited not only to gain arbitrary code execution at PEI/SMM/DXE but also disable platform security features such as Intel BIOS Guard or Intel PPAM.
Supply chain complexity creates the most dangerous vulnerabilities related to reference code (like these in AMI code), that remain unpatched for far longer periods of time. We originally found these vulnerabilities in Intel M5 NUC devices and have been working with Intel and AMI PSIRT teams on coordinated disclosure to patch them before our Black Hat presentation in August 2022. To address the problems related to the NUC, Intel released an advisory (INTEL-SA-00712), but the CVE numbers registered by Intel didn't address the industry-wide problems and were specific to only Intel NUCs. AMI didn’t register the CVEs mentioning that they are not a CVE Numbering Authority (CNA). Due to the fact that a lot of vendors are not aware of these already publicly disclosed vulnerabilities or connect them to only Intel NUCs, a large number of enterprise devices remain unpatched.
We would like to express appreciation to the Intel and AMI security response teams for their collaboration and assistance during the disclosure process.
Quote from AMI PSIRT team: “AMI is committed to working closely with Binarly to leverage its innovative vulnerability detection technologies to strengthen the security of our products and firmware supply chain. We believe this collaboration is essential to protecting our customers and improving AMI's overall security posture. AMI looks forward to partnering with Binarly in this important effort.”
Quote from Intel PSIRT team: “Intel appreciates recent collaboration with Binarly involving their security research and notification of affected vendors.”
In order to address these high-severity vulnerabilities industry-wide before Black Hat, we started coordinated disclosures with CERT/CC VINCE (VU#158026: AMI APTIO V UEFI firmware). The VINCE platform is probably the best way to coordinate disclosures with multiple parties.
The active exploitation of some of the discovered vulnerabilities can’t be detected by firmware integrity monitoring systems due to limitations of the Trusted Platform Module (TPM) measurement. The remote device health attestation solutions will not detect the affected systems due to the design limitations in visibility of the firmware runtime (NVRAM related changes can be detected).
The impact of Pre-EFI (PEI) vulnerabilities has already been discussed in our previous blog. In general, Pre-EFI vulnerabilities can have a greater impact on platform security because of the more privileged environment.
Let’s dive deeper into the technical details and exploitation of Pre-EFI related vulnerabilities: S3Resume2Pei (BRLY-2022-009), PlatformInitAdvancedPreMem (BRLY-2022-027) and SbPei (BRLY-2022-014).
S3Resume2Pei: BRLY-2022-009/CVE-2022-36372
(CWE-123: Write-what-where Condition)
S3Resume2Pei is interesting since it relates to the modifications AMI made to the Intel EDK2 code reference code in the FirmwarePerformancePEI module. If Intel EDK2 reference code was vulnerable to the BRLY-2022-009, every EDK2-based firmware image would have been affected (basically every Intel-based device). You can see the difference between AMI and EDK2 code in the figure below.
In the AMI version of the code, the AcpiS3PerfomanceTable address is extracted from the memory pointed by the NVRAM variable value and can be modified by an attacker leading to the vulnerability. But the EDK2 code creates an AcpiS3PerfomanceTable address extracted from the ACPI which can’t be modified by an attacker due to the LockBox based mitigation.
The BRLY-2022-009 vulnerability is a clear example of how the complexity in the supply chain creates repeatable failures. In this case, vulnerable code which was discovered and reported (INTEL-SA-00343) by Binarly researcher Alex Ermolov several years ago (2020) and was still discovered in devices with the latest firmware version, despite the fact it was fixed a long time ago in Intel EDK2 reference code.
An attacker can corrupt the memory at a controllable address, as shown in the picture below.
Read the FPDT_Variable_NV variable from the dump of the BIOS region (e.g. 0x8ae9f398) and overwrite the address of AcpiS3PerformanceTable (first 4 bytes)
The exploitation will follow the next steps: 1. Get the value of FPDT_Variable_NV variable (S3PerformanceTablePointer) 2. Get AcpiS3PerformanceTable address from ACPI memory pointed by S3PerformanceTablePointer 3. Enable S3 sleep and wake up, go to S3 sleep 4. Arbitrary write at a controllable by attacker address
AMI introduced the following sanity checks to make it harder for an attacker to modify the pointer and execute arbitrary code. But an attacker can overwrite the memory to satisfy the following conditions thus bypassing these restrictions.
An attacker could create the conditions for validating the signature restriction by making this value pointing into the signature string in code or writing the signature just before the memory which is to be corrupted. In this PoC demo, all restrictions are met and successful exploitation is demonstrated.
Binarly does not plan to publish this PoC since this issue is widely available unpatched in the field. In the meantime, we're keeping the PoC code under embargo until CERT/CC VU#158026 is made public.
PlatformInitAdvancedPreMem: BRLY-2022-027/CVE-2022-28858
(CWE-121: Stack-based Buffer Overflow)
The aforementioned vulnerability is a typical stack buffer overflow since when reading the SaSetup and CpuSetup NVRAM variables the same DataSize variable is used as a pointer parameter to the GetVariable service. This is a classical double-GetVariable problem that causes arbitrary code execution during the early PEI phase. The pseudocode for the vulnerable function is shown below:
If the size of the SaSetup NVRAM variable is larger than 1072 bytes, then after the first call of the GetVariable() service, the DataSize stack variable will be overwritten with this size.After a second call of the GetVariable() service, a stack overflow may occur (the stack variable Data will be overflowed). An overflow of 24 bytes is enough to execute arbitrary code.One can argue this code cannot be exploitable because all Setup variables should be protected from being modified from the Runtime environment. That’s true, but not always - in our practice we encountered devices that don’t prevent Setup variables from being changed after the end of boot services. Moreover, this attack was possible on our target device (Intel NUC M15, firmware version: BC0071) due to incorrectly configured filtering in NvramSmm. During our Black Hat presentation we demonstrated the possibility of changing the values of the SaSetup and CpuSetup variables using a simple chipsec script.
The attack vector of changing protected variables opens the door to an attacker to disable important security features like Intel BIOS Guard or PPAM in some cases.
In the case of the BRLY-2022-027 vulnerability, we highlighted a pretty common type of misuse of GetVariable() service by using our efiXplorer tool to detect such classes of vulnerabilities automatically.
It should be noted that even if the SaSetup or CpuSetup variables are filtered, their values can still be modified by reflashing the NVRAM or through a vulnerability in the SMM.
SbPei: BRLY-2022-014/CVE-2022-32579
(CWE-123: Write-what-where Condition)
The pseudocode for the vulnerable function is shown below.
As we can see from the pseudocode, in the case of BOOT_ON_S3_RESUME boot mode, the PCD byte for token number 0xF2 will be written to the address specified in the NVRAM variable AmiCspGlobalNvsPtrVar.
A potential attacker can overwrite the value of the NVRAM variable AmiCspGlobalNvsPtrVar thus controlling the address where the fixed byte will be written (on the tested device, PcdPpi->Get8(0xF2) will return 0x01).Our experiments have shown that the value to be written can be controlled through the PcdProtocol->Set8() function. The modified PCD value is saved after reboot.
Exploitation steps shown PoC vide below: 1. Enable S3 Sleep mode 2. Change the NVRAM variable AmiCspGlobalNvsPtrVar value by hardware overwriting the SPI flash memory or through a vulnerability in SMM. 3. The new value is a pointer that you need to rewrite at the end of PEI phase 4. S3 sleep, wake up
During the process of coordinating this vulnerability with affected vendors, we encountered a claim that the issue is unexploitable on some systems shipped without S3 (Sleep Mode) support (like server platforms). Indeed we encountered such devices, however all of them had the implementation of S3 support in their firmware. Which means Sleep mode could always be enabled (!)
SmmSmbiosElog: BRLY-2022-016/CVE-2022-33209
(CWE-121: Stack-based Buffer Overflow)
The AepErrorLog, a similar NVRAM variable to SmmSmbiosElog that leads to heap overflow, was presented at Black Hat 2021 by Alex Matrosov (“Firmware_Supply_Chain_is_Hard(coded)”). Telemetry data gathering in firmware usually expose additional attack surfaces due to its complexity.
Find below an explanation of the vulnerability in the SmmSmbiosElog module:
The BRLY-2022-016 is a classic stack buffer overflow vulnerability in SMM code that can be used to modify protected NVRAM variables.
The following four functions are forwarded to the runtime through the ChildSwSmiHandler (9c72f7fb-86b6-406f-b86e-f3809a86c138):
In the SmbiosElog->SmbiosElogApi.ApiFunc1() function, the attacker can trigger a buffer overflow on the stack because the source buffer and its size are fully under attaker’s control.
In the following demo we demonstrate the possibility of modifying the value of the Setup variable using this vulnerability.
OverclockSMIHandler: BRLY-2022-003/CVE-2022-27493
(CWE-20: Improper Input Validation)
Bypassing the authentication for protected NVRAM variables opens the door to exploiting other issues. Another clear example of a supply chain problem is a vulnerability in the OverclockSMIHandler module that was reported a long time ago and fixed. However, the vulnerable module appeared in a recent firmware version on a modern Intel NUC M15 device. The module is executed only if the overclocking feature is enabled in the protected Setup variables. There are different ways to modify them in combination with the previous SmmSmbiosElog bug.
OverclockSMIHandler is the same type of problem as UsbRt when unsupported legacy code remains in an ecosystem for a long time after it’s out of support by vendor (“Repeatable Failures: AMI UsbRt - Six Years Later, Firmware Attack Vector Still Affect Millions Of Enterprise Devices”).
On the figure below the vulnerable code pattern shows the trigger:
During the exploitation of this memory corruption vulnerability an attacker has only one restriction: that the 2DB$ signature should be at the beginning of a buffer to be modified.
AMITSE: BRLY-2022-015/CVE-2022-34345
(CWE-20: Improper Input Validation)
The BRLY-2022-015 vulnerability in the DXE runtime module allows an attacker to execute code pointed to by an NVRAM variable. Due to this code running in a relatively late phase inside DXE, when SMRAM is already closed it doesn’t allow it to proceed with privilege escalation to SMM.
The vulnerable code breaks on two major steps (as shown in the picture below):1) Get the function pointer from the EsaVarPtr01 variable value.2) Execution of the function at the controlled address of GetPackageListHandle.
A potential attacker can create the NVRAM variable EsaVarPtr01 and specify the address of the GetPackageListHandle function inside the data of the aforementioned variable. Thus, an attacker can execute arbitrary code during the DXE phase.
It should be noted that the value of the variable EsaVarPtr01 cannot be set at runtime, but it can be set by physically modifying the SPI flash memory which allows an attacker create a persistence vector based only on NVRAM presence (similar to BRLY-2021-003).
The majority of the vulnerabilities discussed in this blog -- and their variants -- can be proactively detected by the Binarly Platform that leverages semantic properties and apply lightweight code checkers, as discussed in our previous blog (“Using Symbolic Execution to Detect UEFI Firmware Vulnerabilities”).
FwHunt rules for the AMI and Intel vulnerabilities discussed here are publicly available in our GitHub repository, and we encourage defenders and research partners to use these rules to scope, at scale, vulnerable devices in their enterprise infrastructure. Additionally, these rules are being pushed to the Linux Vendor Firmware Service (LVFS) to enhance the supply chain security and awareness in enterprise environments worldwide.
The fwhunt-scan detection results for all the issues mentioned above are shown below:
The Binarly team is constantly working to protect the firmware supply chain and reduce the attack surfaces of our customers industry-wide by delivering innovative technologies to the market. Based on our experience we understand that fixing vulnerabilities for a single vendor is not enough. As a result of the complexity of the firmware supply chain, there are gaps that are difficult to close on the manufacturing end since it involves issues beyond the control of the device vendors.
Are you interested in learning more about Binarly Platform or other solutions?Don't hesitate to contact us at fwhunt@binarly.io.
.svg)
