|
What's going on here?
In a research report titled “Usage of default test keys leads to complete Secure Boot bypass”, Binarly research published their discovery that many PC manufacturers who license AMI's very popular UEFI boot firmware failed to replace AMI's sample test Platform Key (PK) certificate with their own certificate before shipping PCs to their customers.
Even though AMI clearly marked their sample certificate with the text “DO NOT SHIP” and “DO NOT TRUST”, many PC makers including Acer, Aopen, Dell, Formelife, Fujitsu, Gigabyte, HP, Intel, Lenovo and Supermicro, have sold and shipped PCs whose SecureBoot process is “protected” only by this sample certificate which was never intended to be used in production. (See this Github page for a list of known makes and models.) They estimate that 1 of every 10 PCs currently contains one of AMI's insecure keys.
This is somewhat like shipping computers with a default password everyone knows that cannot be easily changed. The computer's manufacturer will need to publish new firmware which users who are concerned about this will need to install into their affected PCs.
Since this affects approximately 850 PC makes and models, Binarly has named this critical oversight the PKfail vulnerability.
Why is this Platform Key Certificate important?
If a system is booting in UEFI mode (as opposed to BIOS mode) and if its “UEFI SecureBoot” option is enabled, the system's user and their operating system should be protected from boot-time malware by the system's firmware which will use its Platform Key to verify the digital signature of all operating system files before they are allowed to load and run. This is an effective system, but it is only secure if the matching private key is kept secret. If the private key becomes known, then malicious actors can arrange to properly sign their own malware which can compromise a system every time it's booted before the operating system has the chance to start.
What does this IsBootSecure utility do?
In order to have true boot-time security, three things must all be true:
IsBootSecure verifies and reports on each of these three requirements. It will show a green conclusion like the one above on the left, only if all three of these requirements are met. This test will fail with a specific red explanation, such as the one above on the right, if the system contains the AMI “DO NOT SHIP” or “DO NOT TRUST” sample certificates, if SecureBoot mode is not currently enabled, or if the system is booting with BIOS firmware which does not offer boot-time malware protection.
You may download and run this free analysis and reporting utility to learn about the current status of any Windows system.
Is this really a huge problem?
It's not our place to make that judgment either way, and we're not suggesting that this should be of great concern. Some people will be very concerned, whereas many will not care, and either way is fine. But if you believed that your systems are booting securely, wouldn't you be curious to know whether they are?
However, there are many situations where the promise of SecureBoot's security could be of crucial importance. In those situations, knowing whether a machine might be vulnerable to any boot security bypass could be important. One thing that is certain is that “the bad guys” are now also aware of this new means of compromising vulnerable systems.
And regardless of the security of the system's SecureBoot key, this little utility allows anyone to quickly determine whether BIOS or UEFI firmware was used during booting and if UEFI, whether SecureBoot is currently enabled.
What can be done if a system's key is found to be untrustworthy?
A system's SecureBoot Platform Key is contained within the machine's firmware and a machine's firmware is always supplied by its original manufacturer. All affected manufacturers are aware of their mistake and many are taking responsibility for this by releasing updated firmware for machines which are still being actively supported. Supermicro was one of the affected brands. You may click this link to see a sample manufacturer statement.
Reading the UEFI platform key from LINUX
Although the IsBootSecure Windows application cannot read the platform key when running under WINE in Linux, this is easily done from the Linux command line. First, the “efi-readvar” command must be added to the system with this command: $ sudo apt install efitools
Then use the efi-readvar command to show the PK: $ sudo efi-readvar -v PK
Check the display “Subject” and “Issuer” data to verify that neither of the phrases “DO NOT USE” or “DO NOT SHIP” appear in the results.
You might also use the efi-readvar command: $ sudo efi-readvar -v SecureBoot to confirm whether Linux was booted with boot security enabled.
Links for additional information
Release history
ExitCode | Trouble Itemization |
0 | System is running on WINE with Linux. |
1 | System booted in BIOS mode. No other info available. |
2 | SecureBoot is enabled and the Platform Key is not bad. |
3 | SecureBoot is disabled and Platform Key is not bad. |
4 | SecureBoot is enabled and Platform Key IS BAD! |
5 | SecureBoot is disabled and Platform Key IS BAD! |
6 | SecureBoot is disabled and the Platform Key could not be read. |
7 | Error: Could not get status. Run interactively for a pop-up message. |
This zip archive: “SilentRun.zip” contains sample Windows console batch (SilentRun.bat) and PowerShell (SilentRun.ps1) script files which demonstrate the use of IsBootSecure's exitcode.
Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |
Last Edit: Aug 15, 2024 at 09:31 (114.25 days ago) | Viewed 54 times per day |