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.