Although Secure Boot is often associated with Windows, it's an industry standard supported by various Linux distributions, including Ubuntu. Secure Boot is a security process that checks the signature of all software installed on a computer when it is powered on to ensure its trustworthiness. This process covers UEFI firmware drivers, EFI applications, and the operating system. Now, though, a vulnerability dubbed PKFail might render Secure Boot entirely useless on a number of computers.

In a report from Binarly, an automated software supply chain security platform, the company detailed how a leaked Platform Key (a Secure Boot master key) from American Megatrends International (AMI) was still in use even today even in enterprise-grade hardware. This key can be used to sign malicious software and make it a part of the boot process, bypassing Secure Boot without the user even being aware that their device is compromised. For example, even recently released Dell and Alienware computers are vulnerable.

What is Secure Boot?

A vital part of your computer's boot sequence

As we already explained, Secure Boot is a boot process that checks the signature of the drivers and other low-level software installed on the machine to ensure that it's trustworthy. If any of these elements have a signature that does not match the database of trusted software, the computer will not start normally, and a recovery process will be necessary. This mechanism prevents malicious software from launching during the boot process, protecting your data and maintaining the functionality of your PC.

Viruses and malware can infiltrate systems in numerous ways, but compromising the boot process is particularly dangerous. Attacks like these can ensure the malware runs continuously from startup, jeopardizing your PC's security from the moment it is turned on. Secure Boot is designed to thwart these attacks, significantly reducing the risk and attack surface of your PC, which is why it has become mandatory in Windows 11. However, Secure Boot is not infallible and can be undermined by vulnerabilities in the firmware or hardware of a specific PC, as in the case here.

Typically, you would not be able to modify the Key Exchange Key database, or KEK database. This database contains the signatures of trusted software, and Binarly has already demonstrated a proof of concept attack that would allow a piece of malicious software to add a malicious driver to the KEK database, and for that driver to then be trusted by the system on boot. Binarly tested it on a Gigabyte BRIX PRO GB-BSi3-1115G4 targeting both Windows 11 and Linux.

How did the Platform Key leak?

Apparently, it's been out there for two years

Binarly documents why they are certain of the assessment that the key has been distributed to hardware vendors and shouldn't be trusted.

• The team scanned an internal dataset of firmware images and found that the key was used by multiple unrelated vendors. This means it must have been generated at the root of the firmware supply chain.
• These test keys have indications they shouldn't be trusted, with Binarly pointing out that the issuer is listed as "DO NOT TRUST” or “DO NOT SHIP“.
• Finally, the team also identified the private Platform Key in a public GitHub repository owned by an alleged ODM employee, where the Platform Key was protected by a four-character-long password. This meant that it was easily cracked.

Both CVE-2016-5247 and LEN-7806 were identified in 2016 when there was the first public appearance of information relating to the AMI Test Key being adopted by hardware manufacturers. Then, in 2022, the key was leaked in a GitHub repository, and two years later, it was discovered by Binarly how far-reaching the vulnerability is.

Now with the key out there, it's possible for malicious software to be built and run as part of the boot-up process.

What can you do about it?

Not much, to be honest

If you want to test your motherboard firmware, Binarly has released a PKFail website where you can upload a file and it will check if it's safe or not. For example, I downloaded the Gigabyte GB-BSi3-1115G4 F9 BIOS and scanned it using the PKFail scanner, and it returned that the image can't be trusted and contains the AMI Test Key that has since been leaked. The full list of affected devices can be found in Binarly's report in the table at the end, but you can also upload your own firmware files to the PKFail website and see for yourself.

For now, there isn't a whole lot you can even do to protect yourself. Because AMI implemented test keys that were never replaced further into the chain, end users have ended up receiving devices that can be compromised once a malicious piece of software gains access to the operating system. You can also check if your computer is affected on Windows by running the following command in an elevated PowerShell:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI PK).bytes) -match "DO NOT TRUST|DO NOT SHIP"

If it returns true, then you are affected. If it returns false, then your machine is not affected. Device vendors are able to release updates that can replace the PK in the boot sequence, which users should ensure they install when those updates come out. Otherwise, in the meantime, there isn't much you can do. Users can replace the PK themselves and repopulate their KEK database, but we don't recommend doing that.