The Binarly REsearch team investigates vulnerable image parsing components across the entire UEFI firmware ecosystem and finds all major device manufacturers are impacted on both x86 and ARM-based devices.

Binarly researchers find that Boot Guard key misuse is a recurring problem and affects the entire computing software supply chain.

Behind the screens: An overview of hidden attack surfaces in powerful BMC chip infrastructure.

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.

The Binarly security research team conducts a comprehensive analysis of the recent Intel and MSI source code leaks to model the potential impact.

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.

In my recent blog post on the BlackLotus UEFI bootkit, we discussed how big a problem the firmware supply chain poses to Microsoft Windows bootloaders, showing how the BatonDrop (CVE-2022-21894) vulnerability can bypass both device attestation and secure boot.

My experience with the analysis and detection of rootkits and bootkits goes back more than 20 years. In the early 2000s, the main challenge was dealing with infected machines when rootkits and bootkits modified the operating system kernel to conceal malicious components. It was such a fun time reverse engineering advanced threats in the good old days that I co-wrote "Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats," a book full of the most interesting stories of our time going down the rabbit hole of advanced malware.

In today's disclosure we opened Pandora's box of ARM devices with UEFI firmware vulnerabilities impacting enterprise vendors. As far as we know, this is the first major vulnerability disclosure related to UEFI firmware on ARM. The big part of vulnerabilities disclosed today related to Qualcomm’s reference code for Snapdragon chips. The vulnerabilities in reference code are usually one of the most impactful since they tend to affect the whole ecosystem and not just a single vendor. Due to the complexity of the UEFI firmware supply chain, these vulnerabilities often create additional impact. UEFI's unified specification not only brings consistency to the firmware development process, but also to the attack surface. This consistency creates cross-platform attacks, so many attack vectors from the x86 ecosystem will also be available on ARM, though exploitation specifics will differ.

Last month, our friends at ESET discovered a few interesting security vulnerabilities in Lenovo devices that allow attackers to bypass Secure Boot and execute malicious code on the device.

The technology industry is in the midst of active discussions about the use of “software bill of materials” (SBOMs) to address supply chain security risks. In order to implement supply chain security practices, there must be better transparency on software dependencies. Previously, any piece of software shipped as black-box without providing any information related to software dependencies and third-party components. Firmware has largely been looked at the same way. In an earlier blog post, Binarly team discussed the multiple levels of complexity in the UEFI firmware ecosystem and supply chain taxonomy (The Firmware Supply-Chain Security Is Broken: Can We Fix It?).

Over the past two years, attacks on multiple targets in the semiconductor industry have consistently led to leaks of firmware source code. A compromised developer device could potentially give an attacker access to the source code repository, adding a major gap in the security of the software supply chain.

In a previous blog covering one of Binarly’s presentations at the Black Hat 2022 conference, we discussed in detail our research on attacks that disable Windows Management Instrumentation (WMI) and blind an entire class of endpoint security solutions. We introduced a template for attacks, dubbed ‘one-bit change attack’, on objects residing inside the WMI service address space. We also demonstrated another way to disable WMI by isolating the WMI service from the rest of the operating system through a sandboxing attack.

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.

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.

The Binarly security research team has had a busy year finding, documenting and helping to fix high-impact vulnerabilities affecting multiple enterprise vendors. In this blog, we provide an in-depth look at some of the vulnerabilities we discussed at the Black Hat 2022 conference affecting HP EliteBook devices.

Speculative execution mitigations have been discussed for some time, but most of the focus has been at the operating system level in order to adopt them in software stacks. What is happening at the firmware level? When it comes to applying these mitigations, how does the industry take advantage of them, and who coordinates their adoption specifically into the firmware? These are all good questions, but unfortunately no positive news can be shared.

Almost a year ago, while describing our company mission and the limitations of available solutions for detecting firmware threats, we discussed our initial vision around binary code inspection for detecting firmware threats and vulnerabilities (See: Why Firmware Integrity Is Insufficient For Effective Threat Detection And Hunting).

A month ago, Binarly’s security research team managed the coordinated disclosure of 16 high impact vulnerabilities in HP devices and 23 additional security defects impacting major enterprise vendors. In less than a year, Binarly disclosed 42 high severity vulnerabilities haunting the UEFI firmware ecosystem, all serious enough to cause arbitrary code execution in System Management Mode (SMM).

Today, Binarly’s security research lab announced the discovery and coordinated disclosure of 16 high-severity vulnerabilities in various implementations of UEFI firmware affecting multiple enterprise products from HP, including laptops, desktops, point-of-sale systems, and edge computing nodes.

In our previous blog “The Firmware Supply Chain Security is broken Can we fix it”, we delved deep into the challenges of the firmware ecosystem by introducing the supply chain "race condition" paradigm.

After uncovering FinSpy several months ago, an APT threat targeting UEFI bootloaders, in the morning of January 20th 2022, Kaspersky Lab has released a new report on their latest discovery, a very interesting UEFI firmware threat dubbed MoonBounce.

At the beginning of December, Binarly was very active in spreading the word about the problems in the firmware supply chain ecosystem at multiple security conferences. Alex Matrosov, the Binarly CEO, gave a keynote entitled “The Evolution of Threat Actors: Firmware is the Next Frontier” at AVAR conference in which he focused on the evolving threats coming from historically overlooked places below the operating system.

As experts in firmware security, the Binarly team is frequently asked why endpoint solutions can’t detect threats originating below the operating system such as firmware implant payloads. Unfortunately, the problem requires a more complex approach and the modern architecture of Endpoint Detection & Response (EDR) solutions are weak against generic attack patterns.

In our previous two blogs, Firmware Supply Chain is Hard(coded) and Attacking (pre)EFI Ecosystem, we described in detail four high severity vulnerabilities that impacted the UEFI system firmware and put a large number of enterprise devices at high risk.

At Black Hat USA 2021, Binarly CEO Alex Matrosov jointly presented with Nvidia security researchers Alex Tereshkin and Adam 'pi3' Zabrocki their findings in the “Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)” talk, highlighting five high severity vulnerabilities that affected the whole UEFI ecosystem.

At Black Hat USA 2021, Binarly CEO Alex Matrosov jointly presented with Nvidia security researchers Alex Tereshkin and Adam 'pi3' Zabrocki their findings in the “Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)” talk, highlighting five high severity vulnerabilities that affected the whole UEFI ecosystem.

Currently, integrity checking is the standard methodology for firmware security validation and threat detection. This article details the different scenarios where firmware integrity is necessary, but insufficient from the threat analysis and incident response perspective.

This blog post describes my joint research with Alexandre Gazet that culminated with us presenting the “Breaking Through Another Side: Bypassing Firmware Security Boundaries from Embedded Controller” (slides) talk at BlackHat 2019 Conference in Las Vegas. Our REsearch focused on the Embedded Controller security and Intel BIOS Guard technology implementation in Lenovo Thinkpad BIOS and took around 5 month of our spare time.

At the last Black Hat event in Vegas, I presented the first publicly known concept of an attack on a specific implementation of Intel Boot Guard technology - technology that is mostly undocumented. While I was working on this research one thought bothered me: the specification of a technology can be almost perfect, but after all, the implementation part is done by third-parties and it is challenging to maintain proper level security in this case. Intel Boot Guard is an excellent example of a complex technology where there are places where making a small mistake allows an attacker to bypass the security of the entire technology.