This is a simple proof of concept illustrating the use of shim (with the transparent loader enhancements) to load iPXE, which in turn boots an operating system.
UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.
DBXtool is a tool by Peter Jones of Red Hat. So it works with Fedora, and perhaps other versions of Linux. It is an interesting tool in that it is one of the few tools that look at the UEFI SecureBoot PKI list of blacklisted keys, that UEFI Forum occassionally updates. Last year there was the Microsoft leaks Golden Keys” story, which was overblown, watch Jeremiah’s video on Youtube from the Fall 2016 UEFI Plugfest for more details. I just noticed that DBXtool has support for a dbxupdate.bin file from Microsoft, separate from the UEFI.org-hosted DBX file, related to this Microsoft Golden Keys incident.
Peter’s comment from that checkin:
Add a new dbxupdate.bin
This is the dbxupdate.bin referenced in CVE-2016-3320 and
It’s for their bootloaders, not ours.
WordPress mangles Github Gist URLs, so remove the spaces from the next URL to make it work:
https://gist. github.com/acepace/ df34b5213f1e0fae6529eb703d947187
Some more background on UEFI SB DBX:
https://translate.google.com/translate?hl=en&sl=ru&u=https://habrahabr.ru/post/273497/&prev=search (English translation above Russian document)
Besides Peter’s DBXtool, I’m not aware of many other tools that use the DBX file. There’s this PowerShell script:
Again, WordPress mangles Gist URLs, remove spaces to make this work:
https://gist. github.com/mattifestation/ 991a0bea355ec1dc19402cef1b0e3b6f
I wish I could point to a tool avaialble in each OS/distro that your firmware has the latest blacklist applied…
PS: Peter also works on the Shim. And he’s updated his canary:
Gary Ching-Pang Lin of SuSE has submitted a proposal for Linux kernel and Shim to include a Security Version. In addition to below shim wiki page, there is active discussion on this on the Linux-EFI list.
When a vulnerability is found, every distro will release the patch as soon as possible and push it into the update channel. However, since the signature of the old kernel is still valid, the attacker may trick the user to boot the old and insecure kernel to exploit the system. For the system with UEFI Secure Boot, although the admin can add the hashes of the insecure kernels into MokX, it could be burdensome to do this in large scale. Besides, it’s almost impossible to obsolete the kernels before a certain version. Not to mention that the old kernel sometimes might be useful for debugging. To keep the system secure and also flexible, we propose “Security Version”. The basic concept of Security Version is to use a whitelist to record the “version” of the latest known secure linux kernel. If the “version” of the kernel is lower than that in the whitelist, then the kernel is considered as “not secure”. The “version” in the whitelist can only be incremented monotonically unless the user decides to lower it.[…]
PS: Hmm, Gmane’s linux-efi links aren’t working for me.
Secure Boot chain-loading bootloader (Microsoft-signed binary)
This package provides a minimalist boot loader which allows verifying signatures of other UEFI binaries against either the Secure Boot DB/DBX or against a built-in signature database. Its purpose is to allow a small, infrequently-changing binary to be signed by the UEFI CA, while allowing an OS distributor to revision their main bootloader independently of the CA. This package contains the version of the bootloader binary signed by the Microsoft UEFI CA.
I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.
Especially because I’ve had nearly nothing useful in this blog on this post:
Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!
David Hartsock has a blog post on the state of Ubuntu Secure Boot for those who have not been paying attention to things:
Ubuntu Secure Boot Threatens All PCs
We’re all doomed! Scary, right? Well, maybe, but I should explain a bit first. […]
This from September, I only just noticed it. 😦
Matthew Garrett has updated GRUB bootloader with support for Trusted Boot, on TPM v1 or v2 systems!
In a follow-up to the above tweet, Matthew also states:
“I need to add equivalent code to Shim now lucky me”
So I need to check if that happened, and if Debian and other distros are using this version of GRUB and Shim…
I wish somebody — Wikipedia, the Linux Foundation, the Linux kernel security wiki, the UEFI Forum, etc. — were tracking the various hardware/firmware security features of various vendors, and what system components (grub and shim in this case) had support for the various technologies, with a table of red/green boxes. Then we could more easily see things like tboot only supporting BIOS and not UEFI, etc..
Peter Jones of Red Hat has an interesting post on Linux, UEFI, Secure Boot, and Linux shim maintenance.
If you use Linux and it’s UEFI Secure Boot shim, you may want to read this.