Changes/UEFISecureBootBlacklistUpdates

UEFI Secure Boot Blacklist Updates

Summary

Currently our implementation of UEFI Secure Boot does not include a facility to apply blacklist ("dbx") updates enabled by default. We provide a utility, dbxtool, which uses a systemd service to apply updates, and when there are updates we update that package with the new data. dbxtool is currently not installed on UEFI machines by default, and when it is installed, its systemd service does not default to enabled.

Owner

• Name: Peter Jones
• Email: pjones@redhat.com
• Release notes owner:

Current status

• Targeted release: Fedora 22
• Last updated: 08-Dec-2014
• Tracker bug: #1181568

Detailed Description

In UEFI Secure Boot, the ability for a pre-boot binary such as a bootloader or hardware maintenance utility to be executed is determined by a whitelist of binaries and cryptographic signing certificates, as well as a blacklist of binaries and signing certificates which are no longer considered valid. When a signed binary is discovered to have vulnerabilities which allow it to be used to circumvent the Secure Boot security model, and thus render the system unable to prevent execution of pre-boot malware, the UEFI CA, in coordination with the UEFI Security Response Team (USRT) and the relevant software vendor, must undertake remedial action. The software vendor must fix their vulnerability and issue a new version of the software, and the old software must be blocked from execution on applicable machines.

The first task is up to the vendor in question. Once the new version is ready (or when sufficient time has passed), if a vulnerability is being actively exploited or has a sufficiently high likelihood of being so, the UEFI CA issues a blacklist entry in the form of an update to the UEFI variable "dbx". That update is a cryptographically signed list of binaries and/or signing certificates in a format which may be appended to a specific UEFI variable.

Currently Fedora includes the dbxtool utility for updating the UEFI dbx blacklist. The dbxtool package includes the most recent UEFI CA blacklist update (they each include all data, so previous versions are not required) and a systemd service to ensure the update is applied to the system. Currently dbxtool is not installed by default on applicable systems, and when it is installed, its service is not enabled by default.

This change principally takes place in three packages:

• shim-signed must include a dependency on dbxtool
• dbxtool must have systemd %pre and %post scriptlets added
• systemd must include dbxtool.service in its 90-default.preset

Benefit to Fedora

The benefit to Fedora is the continued ability to protect systems from pre-boot malware. Pre-boot malware has the opportunity to subvert any and all security precautions we take within the operating system, through techniques such as modifying the bootloader and kernel while they are being loaded, or modifying the OS's view of system resources to disable functionality. Such malware will typically install a "bootkit", which serves to initialize itself before the OS is loaded, to hide itself from the OS, and to mask its own presence, and can potentially persist through OS re-installation.

When a new machine ships, it typically has the (somewhat) up to date blacklist installed at the factory, but as vulnerabilities are discovered, that list may change over time. To protect our users from this kind of malware, Fedora must update the dbx blacklist when new vulnerabilities are discovered.

Scope

• Proposal owners: Implement proposed change
• Other developers: potentially the systemd-maint team, though I think I can commit the applicable change there.
• Release engineering: N/A
• Policies and guidelines: If we're keeping a list somewhere of things allowed to have system preset services, dbxtool should be added.

Upgrade/compatibility impact

There are some changes to our compatibility with prior machines, though they are unlike those we've seen before. Specifically, in the event that an older version of Fedora (18 and newer) has its bootloaders blacklisted without an update, it may no longer be possible to install or boot that version of Fedora on a system that has had its blacklist updated. Additionally, if a system contains software external to Fedora, such as pre-boot utilities which are required to run before the OS can be booted, utilities to reconfigure hardware, or bootloaders for other operating systems, before the system boots, that external software may be affected by dbx updates. If e.g. an update is applied through linux and bans another OS's bootloader, a user would need to undertake manual intervention—such as temporarily disabling Secure Boot in the system firmware, performing a repair or update of the external software, and re-enabling Secure Boot—in order to make that external software work again.

Currently no Fedora component has ever been included in a dbx update, and we have no current reason to anticipate any such updates in the near term, however the existence of vulnerabilities in shim, grub2, or kernel such as CVE-2014-3675 could potentially necessitate a blacklist entry in the future.

How To Test

1. Get a UEFI machine with Secure Boot. It'd be best if this machine is a Windows 8 "client" logo certified machine from Oct-2013 through Mar-2014.
2. Ensure that Secure Boot is reset to "factory settings" and is enabled
3. Perform a fresh installation, but don't reboot
4. Using anaconda's shell, ensure that the shim and dbxtool packages are installed
5. Use the new system's "dbxtool -l" to discover what entries are present; there should not be many.
6. Reboot
7. Use dbxtool -l to look at the new list. There should be more entries.

User Experience

The user should not substantially notice this change, though in the event of a dbx update which affects their system, they may notice side effects later as discussed in the "compatibility" section.

Dependencies

The only package dependencies are between shim-signed and dbxtool.

Contingency Plan

This change is going to take me between 5 and 20 minutes. The contingency plan is simply not doing it.

• Contingency mechanism: All of shim's requirement on dbxtool, dbxtool's minor changes, and systemd's update are required for any behavior to change at all.
• Contingency deadline: It actually happens by default if any of the parts don't get done. No action is needed to invoke the contingency plan.
• Blocks release? No
• Blocks product? No

Documentation

Some gritty details were on my blog, and there's a man page for dbxtool in the package.

Release Notes

Yeah, we should probably include release notes.