Safeguarding UEFI Ecosystem: Firmware Supply Chain is Hard(coded)

The presentation discusses the vulnerabilities in UEFI firmware and the current state of mitigation and hardening technologies.

• UEFI firmware is portable and runs on many platforms, making it interesting and dangerous for attackers
• CVE-2021-2016 is an example of a vulnerability found in UEFI firmware
• Mitigation and hardening technologies are not mandatory and not enabled by default
• There is a lack of various memory protection enforcement in UEFI firmware
• Some mitigation technologies are not compatible with each other
• The pre-efficient phase known as PAY does not support any kind of mitigation based on the guard paging
• HIP guard feature could increase memory consumption and cause memory out of resources

The presentation highlights the vulnerability in UEFI firmware where an attacker can exploit the firmware performance table pointer, which is fully controllable by the attacker, and overwrite any portion of the memory. The exploit is not detected by any TPMs, making it very attractive to attackers. The current state of mitigation and hardening technologies is not great, as they are not mandatory and not enabled by default. Additionally, some mitigation technologies are not compatible with each other, and the pre-efficient phase known as PAY does not support any kind of mitigation based on the guard paging. HIP guard feature could increase memory consumption and cause memory out of resources.

The UEFI ecosystem is very complicated in terms of supply chain security where we have multiple parties involved in the firmware code development like Intel/AMD with its reference code, or AMI, Phoenix and Insyde with its core frameworks for system firmware development. The hardware platform vendor contributes less than 10% to the UEFI system firmware code base from all the code shipped to the customers. The reality is vulnerabilities can be discovered not just in the platform vendor codebase, but inside the reference code. This impact can be worse reflecting on the whole ecosystem. The patch cycles are different across vendors and these vulnerabilities can stay unpatched to endpoints for 6-9 months. Moreover, they can be patched differently between vendors making fix verification difficult and expensive. This research resulted from an internal security review for some of the NVIDIA hardware and few edge computing platforms provided by partners. We found several issues. Some issues related to Intel EDKII (reported to Intel in September 2020). Additional issues for legacy protocols like SmiFlash, which is sometimes still available even on relatively new hardware. These are subject to attacker influence through NVRAM or SPI flash, allowing attackers to gain persistence. One issue particularly exciting to us due to its sustainable path of exploitation and impact of arbitrary code execution in the PEI phase. Our researchers developed a PoC where arbitrary code execution on PEI phase transfers a payload to SMM and survives the DXE phase. This powerful exploit path can be used to install a persistent implant in the system firmware compromising all Secure Boots.