Secure Boot

From Kicksecure
Jump to navigation Jump to search

Documentation for this is incomplete. Contributions are happily considered! See this for potential alternatives.

Bad Design[edit]

Secure Boot allowing only one signature on a binary creates a major mess.

1) Users wishing to run in a Secure Boot environment will have to trust Microsoft in order to boot official Fedora. The Secure Boot signing format currently allows only one signature on a binary -- so Fedora's shim bootloader can be signed only by the Microsoft-vouched key. If a user removes Microsoft's key, official Fedora will no longer boot, as long as Secure Boot is on.

Note: Unspecific to Fedora and also applicable to other Linux distributions.

1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware.

But that does not help Ubuntu much because Ubuntu cannot sign its bootloader (shim) with both keys, the Microsoft key and their Ubuntu key. Therefore, quote:

2) Ubuntu CDs, distributed separately from hardware, will also depend on the presence of Microsoft's key in the machine's firmware to boot, when Secure Boot is active.

And also the security gain is negligible because Microsoft's key also must be installed.

1) Machines sold as "Ubuntu Certified," preinstalled with Ubuntu, will have an Ubuntu-specific key, generated by Canonical, in their firmware. Additionally, they will be required by the certification guidelines to have the Microsoft key installed.

The decision to either trust Microsoft or Ubuntu is a big one. But in rather rare cases it will make sense for users to trust both keys at the same key (except in dual-boot scenarios).

It is also a bit of security theater.

the boot loader must not execute any unsigned code in a firmware context, that is, before ExitBootServices is called just before jumping into the kernel.

Then also nowadays the inital ramdisk used by most (if not all) Linux desktop distributions contains unsigned code.

ExitBootServices

Microsoft[edit]

Microsoft is dictating policy for the Linux boot process.

Due to the complexity of the Linux boot process, the number of active releases from different distributions with compatibility challenges, and the support and serviceability timelines of in-market products, a limited exception to the NX signing requirements has been granted.

This limited exception is granted for shims serving in-market products.  This exception will be reviewed regularly, and once component versions are identified that meet the compatibility requirements, new shim signing requests for products targeting the identified components will no longer be exempt. Additionally, when shim functionality is developed to provide compatibility for older, non-compliant boot components, new shim signings will no longer be exempt. 

Please reach out to: uefisign@microsoft.com with any questions on this policy.

Related shim ticket linking to the same source Is 15.8 being prepared?archive.org.

https://techcommunity.microsoft.com/t5/hardware-dev-center/updated-uefi-signing-requirements/ba-p/1062916archive.org

https://techcommunity.microsoft.com/t5/windows-hardware-certification/pre-submission-testing-for-uefi-submissions/ba-p/364829archive.org

shim review board

https://github.com/rhboot/shim-reviewarchive.org

shim HTTP boot[edit]

HTTP boot is part of the UEFI specification.

shim can be started from a UEFI boot entry. [1]

Where is that UEFI boot entry stored? Inside efivars (a (U)EFI variable filesystem).

Where is efivars stored? Inside the NVRAM. What is the NVRAM? Imagine it being similar to a hard drive but not really a separate hard drive. It's a writable storage area on the motherboard, part of the firmware.

shim's HTTP boot can then fetch and execute another UEFI executable such as bootloader (such as GNU GRUB or Linux

The vulnerability can also be exploited locally by an attacker with enough privileges to manipulate data in the EFI Variables or on the EFI partition. This can be accomplished with a live Linux USB stick. The boot order can then be changed such that a remote and vulnerable shim is loaded on the system. This shim is then used to execute privileged code from the same remote server, all without ever disabling Secure Boot.

related:

Footnotes[edit]

no THE shim


Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 11 year success story and maybe DONATE!