The supply-chain for firmware development is vast, convoluted, and growing out of control: patching security vulnerabilities can take up to two years. For cybercriminals, it’s a veritable playground.
BLACK HAT ASIA 2022 — When it comes to developing the firmware that powers computing devices, the ecosystem consists of complex supply chains that have multiple contributors. For any given device, the firmware could be made up of a hodgepodge of components from different sources. And that means that when it’s time to address security vulnerabilities, it’s far from a straightforward process to get a patch out to the public.
During a panel discussion session at Black Hat Asia on Thursday, entitled “The Firmware Supply-Chain Security Is Broken: Can We Fix It?”, Kai Michaelis, co-founder, and CTO at Immune GmbH, outlined what he called the overgrown supply-chain “tree,” out of which grows onerous code reviews, and lengthy patching processes when a bug is found.
In fact, six to nine months for patches to roll out is the average, according to the panelists — with two years being not uncommon. And that means the supply chain represents a wide attack surface that’s ripe for compromise, they warned. Given that vulnerable firmware threatens the safety of the operating system and any applications, the potential for cyber attackers to find exploitable vulnerabilities is a serious concern.
The final firmware that vendors incorporate into their hardware is a multi-sourced affair, explained Michaelis. Stakeholders can include various component vendors, a few open source repositories, reference implementations, original design manufacturers, independent BIOS vendors, and finally, the original equipment manufacturers (OEMs) that create and sell the final product to channel partners and end-users.
Further complicating matters is the fact that subsystem vendors might be sitting in the middle of the code tree, itself combining elements from multiple component manufacturers into a single offering.
The unfortunate end result is that when a vulnerability is reported, OEMs often have multiple “branches” from which patches and updates flow — and they usually have no visibility of each other.
“It’s a tree of suppliers and updates with little coordination between them, and the OEM has to ingest all of it,” Michaelis said. “For vendors, packaging updates is a fairly manual process, and then consumers need to actually install those updates. In all, the patching process as it stands can be measured in months to years.”
One of the main issues that Michaelis flagged is the fact that when bugs are found, they may be benign in and of themselves. However, when combined with additional vulns in other parts of the firmware, the flaws become weaponizable and could allow attacks on value-added reseller (VAR) partners — and from there, end-users.
“Convincing a vendor to patch what it believes is a harmless flaw is not easy,” he said. “And even if there is a patch, it takes so long for it to get downstream that an attacker could easily find another vulnerability to combine with it in the meantime. So this is the problem: Bugs exist in isolation because vendors don’t talk to each other, and bugs have a long shelf life.”
There are at least three other aspects that make matters even worse: One, end-of-life (EoL) devices often don’t get updates; two, each vendor follows its own patch cycle; and three, sometimes vendors offer silent updates without issuing an advisory, which can discourage OEMs from incorporating patches.
Repeating the Same Mistakes
Alex Matrosov, founder and CEO at Binarly, explained during the panel that like in the software supply chain, firmware bugs can also be spread and re-imported even after they’ve been patched, resulting in what he called “repeatable failures.”
For instance, a bug recently disclosed in one of the components in the Intel M15 laptop kit (CVE-2022-27493) is a classic out-of-bounds write flaw stemming from system-management mode (SMM) memory corruption — but not as what it seems.
“It’s actually a 2019 bug found in the AMI codebase that we’ve now discovered in 2022 firmware,” Matrosov explained. “This vulnerability was fixed, but the fixed version was not included by the device vendor. It’s a very vulnerable component and has been known for years as a suitable attack vector, and it should be removed.”
In another example, vulnerable code in an EDK open-source library called Security Pkg was removed in EDK II in 2018. However, somehow it found its way into 2022 firmware affecting several OEMs, via another library. “The risk was exponentially compiled,” Matrosov said. Read more:https://bit.ly/3PuhW3U
You can also read this: NIST Issues Guidance for Addressing Software Supply-Chain Risk