Intel late Sunday confirmed that proprietary UEFI code had been leaked in a potential serious security breach.
The Intel Alder Lake source code was leaked to 4chan and Github – as first reported by Tom’s Hardware – as a 6GB file containing sensitive tools and code for building and optimising BIOS/UEFI images.
Alder Lake refers to the company's 12th generation processors, which launched in November 2021.
Security researcher Mark Ermolov, who specialises in Intel chip security, said: “The Intel Boot Guard on the vendor's platforms can no longer be trusted” – after its private signing key was found among the leaked data.
Hardware security experts say the code – now it is out in the open – will be reviewed extensively for potential zero day vulnerabilities that allow attackers to exploit it. Intel has flagged to the community that all the leaked code is covered under its bug bounty programme, in the hope that security researchers will do the right thing.
Intel source code leak: How risky is it?
Ermolov told The Stack via Twitter DM that consequences of the leak included the potential ability to bypass Intel’s Boot Guard. It also gives bad actors the ability to review UEFI code meaning attackers could identify undocumented CPU functions, as well as look for potential zero days in the UEFI for the actual CPUs.
MSRs were also leaked. These are the interface to the microcode, most of them are undocumented in public.
It was not immediately clear if that key had been used in production nor how the Intel source code was leaked.
As Tom’s Hardware reported: “The GitHub repository [that housed the leaked code], now taken down but already replicated widely, was created by an apparent LC Future Center employee, a China-based ODM that manufactures laptops for several OEMs, including Lenovo. Additionally, one of the leaked documents refers to "Lenovo Feature Tag Test Information," furthering the theories of the link between the company and the leak.”
He added that by studying the leaked MSRs attackers might, in theory, find previously undocumented “debug facilities to break Intel's CPUs security technologies, such as SGX” – the onus, he added by DM, was on Lenovo to confirm that the leaked private key was not used in production or there would be a danger of the emergence of malicious UEFI implants on Lenovo laptops that would go unnoticed by end-users.
Intel said: “Our proprietary UEFI code appears to have been leaked by a third party. We do not believe this exposes any new security vulnerabilities as we do not rely on obfuscation of information as a security measure.
“This code is covered under our bug bounty program within the Project Circuit Breaker campaign, and we encourage any researchers who may identify potential vulnerabilities to bring them our attention through this program,” Intel said.
The BIOS/UEFI of a computer initialises the hardware before the operating system has loaded and helps establish connections to security mechanisms, like Intel’s TPM (Trusted Platform Module).
Hardware and UEFI-based attacks have become more common in recent years. In August Eclypsium published a detailed analysis of Russian ransomware group Conti’s approach to targeting vulnerabilities in Intel’s Management Engine “ME”, the microcontroller embedded in many modern Intel chipsets.
As Joe FitzPatrick of Securing Hardware, a security researcher focused on firmware and hardware, noted to The Stack in earlier discussion on firmware attacks: “[In the past] there was no need to attack the firmware, because the software was vulnerable enough. Only now that we have robust OSs with encrypted storage, signed kernels and drivers, and sandboxing everywhere does any attacker even need to consider firmware.”
He also said firmware attacks have been helped by the homogenisation of firmware: “It used to be that every version of every motherboard had a different bios written for it, and there were dozens of bios vendors. Now, everything is UEFI, and huge portions of the UEFI firmware on systems is identical across products, often with shared portions across different vendors as well. We have firmware being developed with modern tools – and we have tools to analyse and modify firmwares much more easily,” he told The Stack by email at the time.
