.webp)
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.
In addition, Microsoft has patched several vulnerabilities like CVE-2023-21560 that document only Bitlocker encryption bypasses but because Bitlocker encryption bypasses involve bootloaders, these issues bypass secure boot as well. In terms of architecture and security design, ARM and x86 MS bootloaders have almost identical code. This shows the complexity of the supply chain with just a single vendor’s code.
What if we have reference code vulnerabilities spread across the entire industry?
Just last week, the Quarkslab research team published details on two memory corruption vulnerabilities in the TPM 2.0 reference implementation code. The combination of these vulnerabilities (CVE-2023-1017 and CVE-2023-1018) can lead to predictable arbitrary code execution on Trusted Platform Modules (TPMs). These vulnerabilities affect the entire industry, not just a single vendor. The issue involves third-party components (TPM chips, fTPMs and vTPMs) that are usually controlled by TPM manufacturers, making fixing these vulnerabilities a nightmare for vulnerable device manufacturers.
Since most TPM chips are developed by third-party vendors, the device manufacturers' updates to these vulnerabilities will be dependent on the TPM chip owner and their update schedule.
To help corporate defenders, our friends at Immune developed an open-source tool called tpm-vuln-checker for the detection of the recently disclosed TPM vulnerability CVE-2023-1018.
(Screenshot shows TPM vulnerability detection at scale with tpm-vuln-checker tool).
The TPM firmware is not unique and contains vulnerabilities like any other but they are more difficult to discover since the firmware files aren’t accessible without vendor NDAs. Even TPM updates tools are not perfect.
In the past, the Binarly REsearch team called attention to the complexity of the OpenSSL dependencies in UEFI-based firmware, showing examples of supply chain failures when InfineonTpmUpdateDxe contained code known to be vulnerable for at least eight (8) years. Keep in mind, the InfineonTpmUpdateDxe module is responsible for updating the firmware of TPM on the Infineon chip.
Supply chain complexity growth only complicates firmware vulnerability disclosures. Most importantly, it complicates two major things: the scope of the impacted devices, the development of effective security fixes, and their delivery to endpoints.
The Binarly REsearch team has produced research to expose these repeatable failures on different types of UEFI firmware. Within one year, we disclosed 228 high-impact vulnerabilities and with multiple parties to help the industry mitigate risk from the massive amount of firmware vulnerabilities:
The figure below summarizes the extent and industry-wide impact of the UEFI firmware vulnerabilities disclosed in 2022.
A record number of high-impact vulnerabilities (228) were disclosed by the Binarly REsearch team in UEFI system firmware. By design, most of these vulnerabilities bypass Secure Boot and allow attackers to persist at the firmware level. The biggest portion of disclosed vulnerabilities is related to memory corruption issues. And from the beginning of the year, we reported 20+ more vulnerabilities to the device vendors. That demonstrates that such classes of vulnerabilities are widespread and require a more firmware-specific approach for automation like we discussed in one of the previous blogs “efiXplorer: Hunting UEFI Firmware NVRAM Vulnerabilities”.
Based on Binarly REsearch disclosures, the median disclosure timeline is between six and eight months. In some cases, the vendors have patched Binarly reported vulnerabilities with a timeline of more than a year. Some vendors fail to patch supported devices even after vulnerabilities are publicly disclosed. One example was HP after our Black Hat USA presentation in a few weeks we figured out that most of the reported issues still stay unfixed. Another interesting discovery was with Lenovo’s LEN-94952 security update case where some of the vulnerable product lines didn’t receive an update with security fixes.
Later on, Binarly REsearch team follow up on this research with new discoveries disclosed in Insyde UEFI firmware reference code and presented at Ekoparty. In total, we disclosed 22 high-impact vulnerabilities for this research focused to demonstrate the repeatable failures.
Three new vulnerabilities BRLY-2022-19/CVE-2022-36337, BRLY-2022-20/CVE-2022-35407 and BRLY-2022-21/CVE-2022-35897 were disclosed in November last year to address the large numbers of vulnerabilities discovered previously for the LABcon research but responsible disclosure timeline didn’t make it by the time of the presentation. Unfortunately, these vulnerabilities are related to reference code and even a few months after the disclosure date we can see these vulnerabilities unfixed on many enterprise devices.
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).
Recently Intel released “2022 Product Security Report” where it is visible the impact Binarly team did on the industry. Binarly REsearch disclosed more than 50% of all the vulnerabilities disclosed in Intel NUC devices for the last year. We disclosed 13 high-impact vulnerabilities and the impact of many of them was demonstrated at the security conferences.
In general, the number of firmware vulnerabilities unfortunately is not going down and only increasing every year. The complexity of the firmware only increases, we had a BIOS image size 8Mb in 2013 which grew to 16Mb in 2015 and nowadays the storage size grew to 32Mb for client computers and up to 256Mb for servers. The code complexity opens new attack surfaces, creates more third-party dependencies, and increases complexity for the functional support and security fixes delivery overall. The modern UEFI firmware is a real-time operating system running below the main OS. The complexity and the size of the UEFI-based firmware are way bigger compared to modern Linux or Windows OS kernels. But we still don’t have specialized tools to conduct automated security reviews focused on firmware specifics of such extensive codebases.
Currently, there are no static analysis tools that focus especially on firmware security since firmware applications have a lot of code specifics that do not exist in operating system applications but open wide attack surfaces. This is exactly the reason why the Binarly team started working on the next-generation tool to address firmware-specific security issues at scale.
Scalable vulnerability analysis requires automation. Binarly REsearch team is committed to research on identifying problems and providing useful tools for security researchers and product security teams to help fix these repeatable firmware security failures for the industry.
.svg)
