.webp)
Only two months have passed since our Black Hat talk where we spoke about a bunch of discovered vulnerabilities. Our presentation at Black Hat revealed 12 serious vulnerabilities affecting enterprise devices industry-wide. The Binarly security research team continues to find evidence of repeatable failures in the firmware development ecosystem, exposing critical vulnerabilities that impact the entire industry rather than just a single vendor.
Three weeks after our Black Hat talk, we realized many disclosed vulnerabilities remain unpatched on millions of enterprise devices worldwide. After notifying impacted parties we released a two blog posts to raise industry awareness:
Binarly’s researchers are regularly finding and coordinating the disclosure of firmware vulnerabilities with more than 68 high-impact issues addressed since summer 2021. Based on Binarly telemetry data, the industry continues to struggle with memory corruption vulnerabilities in firmware that have a major security impact as shown on 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. Approximately 20% of firmware updates contain at least two or three known vulnerabilities (previously disclosed), according to Binarly Platform data (based on enterprise-grade vendors study)
At the end of September, Binarly presented at the inaugural LABScon event to showcase our groundbreaking work on “Breaking Firmware Trust From Pre-EFI: Exploiting Early Boot Phases”. We released the efiXplorer v5.0 [LABScon Edition] with new features to analyze ARM-based firmware files.
We also disclosed the discovery and mitigation of seven (7) new vulnerabilities impacting enterprise devices industry-wide. These vulnerabilities augment our previous research from Black Hat USA to demonstrate additional gaps in the firmware supply chain.
These repeatable failures will present severe exposure to risk, for two reasons:
At LABScon, Binarly chief executive Alex Matrosov discussed the discovery of multiple high-impact vulnerabilities related to Insyde reference code. Such vulnerabilities usually take longer in the disclosure process because they impact multiple parties industry-wide. But the right collaboration between the Insyde PSIRT team and Binarly helped to reduce the disclosure timeline from the usual 6-8 months to less than 90 day before the official public disclosure date.
“Insyde Software prides itself on the timeliness of its response to all security-related matters,” said Tim Lewis, CTO and head of Insyde’s Office of Security & Trust. “Collaborating with Binarly after their discovery to understand the nature and severity of these issues was paramount to our ability to have a resolution well before public disclosure,” added Lewis
The seven new vulnerabilities disclosed at LABScon are detailed below:
As we can see from the figure, the most common vulnerabilities and vulnerable code primitives are still related to arbitrary code execution leading by SMM call-out bugs or different types of memory corruption issues. Let’s dive deeper into the technical details with a detailed analysis of the root cause of these vulnerability types
So the first common issue is a classical SMM call-out vulnerability via EFI_BOOT_SERVICES table which is located outside of SMRAM, hence its contents (pointers to functions) could be controlled by an SMI handler caller (a possible attacker). BRLY-2022-017 found in FwBlockServiceSmm (provides helper functions to assist flash devices workflows) module is a perfect example of such an issue:
In some cases, as BRLY-2022-022 in UsbLegacyControlSmm module (legacy interface for USB devices communication), the vulnerable code fragment is not reachable during runtime, because of ExitBootServicesEvent has happened:
However it doesn’t mean the vulnerability is not exploitable. This code still could be triggered during boot. In case an attacker gains arbitrary code execution in DXE phase, this vulnerability could be exploited to escalate privileges directly to SMM (ring -2).
Such vulnerable code primitives are pretty common and in many cases considered by device vendors less impactful compared to vulnerabilities exploitable from the operating system layer. But such vulnerabilities are pretty impactful from the perspective of the supply chain since they usually remain unpatched for a longer period of time. In some cases, they stay unpatched forever!
We never talk much about a less severe (Medium, Low) class of UEFI firmware vulnerabilities, however the importance of those should also be stressed, especially if the same code pattern used industry wide in different SMM modules: FwBlockServiceSmm and FvbServicesRuntimeDxe (actual implementation of Firmware Volume Block (FVB) protocol).
The above showed code pattern process the following input arguments, specified in SMM Communication Buffer by an SMI caller (a possible attacker):
addr – main pointer for the operation, retrieved as *((_QWORD *)CommBuffer + 2));
size – size of data for the operation, located at (_QWORD *)CommBuffer + 3);
dest – destination buffer address for the operation (if applicable), the rest of SMM Communication Buffer located at (__int64)(CommBuffer + 0x20).
Obviously, this code fragment allows an attacker to dump memory from SMRAM (SMM memory leak vulnerability), which in turn could help to reconstruct critical objects location inside SMM memory, as an example for bypassing existing runtime mitigations against exploitation of SMM vulnerabilities. It can also be used to read or dump the whole SMRAM memory region for further research.
Here we can see another perfect example of an SMM memory corruption vulnerability, which allows writing a predictable value from ResValue to a location pointed by Ptr.
The Ptr is obtained via the NVRAM EFI variable IhisiParamBuffer {92e59835-5f42-4e0b-9a84-47c7810ea806}:
Such a memory write primitive could be used to corrupt critical structures in SMRAM for influencing on code logic of other SMI handlers in a way to bypass mitigations or hijack execution flow. Combined with read primitives from BRLY-2022-018 or BRLY-2022-025, this becomes a very dangerous combination of vulnerabilities that allows full control with both read and write exploitation primitives.
But frankly speaking the addresses of some drivers can be obtained without read code primitive (such as PiSmmCpuDxeSmm) and SMRAM write in this case does not require SMRAM read to effectively exploit.
We can’t afford to walk away without sharing the details on a ‘do-whatever-you-want’ class of bugs in SMM, which we internally name SMM memory corruptions allowing to write-what-where. The fact the following code pattern is used in multiple different modules (FwBlockServiceSmm, FvbServicesRuntimeDxe) industry wide only adds flavor to this case.
addr and dest input arguments for this code are specified by an SMI caller (a possible attacker) via SMM Communication Buffer. The encore observation: there are multiple quite similar memory corruptions with the pattern SetMem(addr, 1, const_byte) in the same SMI handler.
We are thankful for the Insyde PSIRT team collaboration during the coordinated disclosure process and appreciate fixing carefully all discovered vulnerabilities. The Insyde security advisories were released alongside our LABScon presentation.
AS USUAL:Binarly team provides FwHunt rules to detect vulnerable devices at scale and help the industry recover from firmware security repeatable failures.
FwHunt Community Scanner: https://github.com/binarly-io/fwhunt-scan
FwHunt detection rules: https://github.com/binarly-io/FwHunt/tree/main/rules
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)
