.webp)
The Binarly REsearch team disclosed three high-severity vulnerabilities to AMD in December 2022, with confirmed industry-wide downstream impact. It’s normal for vulnerabilities in reference code to live in the supply chain for long periods of time, even after the fixes are released. In these cases, the silicon vendor did not assign the CVEs to the internal discoveries and released silent fixes to some vendors. Binarly’s researchers discovered these CVE-2023-20558/BRLY-2022-044 and CVE-2023-20559/BRLY-2022-042 independently and disclosed them to AMD’s security response team. A fourth vulnerability, BRLY-2022-045 (8.5 High), is still unfixed due to the complexity of the issue and its impact. AMD expects to release a patch later this year.
We independently discovered the BRLY-2022-043 (7.5 High) SMM callout vulnerability (there were no public technical details available and no patch on the target system) and reported it to AMD. However, it appears to be a rediscovery of CVE-2021-26317, a bug that was previously reported to AMD PSIRT by Jiawei Yin. Because the AMD website is scarce on details of the problem, we are publishing a more detailed advisory.
CVE-2021-26317/BRLY-2022-043 (CWE-829) – HIGH – Failure to verify the protocol in SMM may allow an attacker to control the protocol and modify SPI flash resulting in a potential arbitrary code execution.
Let's look at the code of the problematic SMI handler:
Where AMD_CPM_TABLE_SMM_PROTOCOL will be located with gBS->LocateProtocol():
AMD_CPM_TABLE_SMM_PROTOCOL installation routine located at AmdCpmInitSmm module:
From the screenshot above we can see that a copy of the protocol AMD_CPM_TABLE_PROTOCOL in SMRAM will be installed with gBS->InstallProtocolInterface() service. That’s why the vulnerable code patterns for BRLY-2022-043 (as well as for BRLY-2022-042 and BRLY-2022-044) cannot be exploited from the operating system. But an attacker capable of executing code in any DXE driver could exploit this vulnerability successfully to gain SMM privileges over code execution.
It is worth mentioning that creation of the SMRAM-copy of some protocols used in DXE is a commonly used mitigation to protect from SMM call-outs in runtime. However the best practice is to create a copy and install this copy as an SMM protocol via EFI_SMM_SYSTEM_TABLE2->SmmInstallProtocolInterface(). This would allow avoiding usage of gBS (EFI_BOOT_SERVICES) inside other SMM modules to locate this protocol when it is required. Hence, avoiding creation of the opportunity to an SMM call-out. However the developers of this code decided to do exactly the opposite. The code that uses this SMRAM-copy of the protocol has to locate it first via gBS->LocateProtocol().
When a vendor’s PSIRT team provides feedback regarding rediscovery for already fixed vulnerabilities, we always ask to provide associated CVE numbers and public advisories to confirm these problems are fixed and maybe it’s only related to a specific device. But if there is no public information to confirm these vulnerabilities with existing CVEs, then we count these vulnerabilities as new ones. We understand that sometimes it happens when the work of external researchers overlaps with the internal product security team, and that's exactly why it's essential to have a public track record of internal findings as well. As a result, the supply chain will be more consistent, and ecosystem partners will be able to fix serious vulnerabilities more quickly. The most critical component of the supply chain security success is transparency. Without transparency, supply chain problems will always be repeatable failures.
Following industry best practices and creating the public track record for these vulnerabilities will help all parties that use AMD reference code to apply fixes. If there is no associated public track record, the plan could be to treat these vulnerabilities as new and credit both external and internal product security researchers for these independent discoveries.
Supply chain complexity growth only complicates the firmware vulnerability disclosure process. When vendors release silent fixes, these are not showing up as anything urgent to many device vendors and sometimes remain unpatched indefinitely. These examples show that at least 12 months of vulnerabilities are still present at scale.
A great example of a supply chain issue related to AMD reference code vulnerability CVE-2021-39298/BRLY-2021-004 has a long story of discovery and multiple rediscoveries after a year of original disclosure to HP and public disclosure on March 8th of 2022 (“Repeatable Firmware Security Failures: 16 High Impact Vulnerabilities Discovered In HP Devices”). It appears BRLY-2021-004 was initially fixed only by HP and not reported to AMD since we were not aware at the time of the disclosure of the issue related to AMD reference code. Additional investigation connects this code to AMD's firmware driver (AgesaSmmSaveMemoryConfig), which is widely spread across the entire device ecosystem.
All three vulnerabilities in AMD reference code are related to the SMM Callout class of vulnerabilities. These attacks have been known for ages but still create many problems for the entire UEFI firmware ecosystem. One of the main reasons for such repeatable failures is the limitations of the common industry static analysis tools for code audit, which don’t support firmware-specific vulnerabilities and require additional customization. But the lack of knowledge base creates challenges for the security teams to scope and understand the whole scope of such attacks and vulnerabilities (“Scalable Vulnerability Analysis Requires Automation”).
This is exactly the reason why the Binarly team designed and created a next-generation tool to address firmware-specific security issues at scale.
CVE-2021-39298/BRLY-2021-004 (CWE-829) -- HIGH -- A potential vulnerability in AMD System Management Mode (SMM) interrupt handler may allow an attacker with high privileges to access the SMM resulting in arbitrary code execution which could be used by malicious actors to bypass security mechanisms provided in the UEFI firmware.
The BRLY-2021-004, BRLY-2022-042, BRLY-2022-043, and BRLY-2022-044 are excellent examples of misuse of EFI_BOOT_SERVICES and EFI_RUNTIME_SERVICES because it is unsafe to run such code inside System Management Mode (SMM). An attacker capable of executing code in the unprivileged DXE runtime phase can exploit this vulnerability to escalate privileges to SMM.
CVE-2023-20558/BRLY-2022-044 (CWE-829) -- HIGH -- Insufficient control flow management in AmdCpmOemSmm may allow a privileged attacker to tamper with the SMM handler, potentially leading to an escalation of privileges.
CVE-2023-20559/BRLY-2022-042 (CWE-829) -- HIGH -- Insufficient control flow management in AmdCpmGpioInitSmm may allow a privileged attacker to tamper with the SMM handler potentially leading to escalation of privileges.
This vulnerability was patched by using SmmLocateProtocol() instead of LocateProtocol() and SmmInstallProtocolInterface() instead of InstallProtocolInterface().An example of a fixed module from AMD-based Lenovo firmware is shown below:
However, many Lenovo products have still not been patched:
Three products contain insecure AMD_CPM_TABLE_SMM_PROTOCOL installation code:
Vulnerability disclosures with industry-wide downstream impact are always complicated, especially when they apply to the firmware reverence code used by the entire silicon vendor ecosystem.
Binarly REsearchers have previously demonstrated repeatable failures in reference code for Intel, Qualcomm and AMD and all of these disclosures have impacted even newer devices months after the public disclosure dates. This confirms how the firmware supply chain is really broken and impacts every single device in the ecosystem. We need to rethink the entire approach to how we validate firmware security risks to gain more transparency and visibility into the threats coming from below the operating system.
.svg)
