GRUB's Secure Boot implementation loads unsigned kernel without warning

Bug #1401532 reported by Wouter on 2014-12-11
348
This bug affects 17 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Mathieu Trudel-Lapierre

Bug Description

Me and some other students have conducted some various experiments on Secure Boot enabled machines. The main focus of the tests was to circumvent Secure Boot and load unsigned kernels or kernels that have been signed with other keys.

On your SecureBoot (https://wiki.ubuntu.com/SecurityTeam/SecureBoot) it is outlined that GRUB will boot unsigned kernels when the kernel is unsigned. During one of our experiments it seemed that this statement was true and that GRUB loads unsigned kernels as described on your page. We understand that for various reasons GRUB should still support the use-case when an unsigned kernel must be loaded, but with the current approach the user isn't aware if there is a whole chain of trust. For example, it could still be possible to load some malware before it boots the Operating System itself (bootkits). One of the many reasons that Secure Boot has been developed is to protect the user from these kind of attacks.

With the current approach the purpose of Secure Boot is somewhat defeated, and the user doesn't know if the whole chain has been verified or not. It could easily be the case that an unsigned kernel has been loaded by Ubuntu without the user noticing. From our point of view, a better approach would be to inform the user that an unsigned kernel will be loaded and that the user can make a choice if he/she wants to proceed. The default action could be to accept the option, remember the user's option and sometimes remind the user of the fact that it is loading an unsigned kernel.

This problem is of course related to GRUB itself and not to Ubuntu itself. The reason for filing this bug and informing the SecurityTeam of Ubuntu is to ask for their opinions and what your point of view is on the current approach and to see if other users classify this as a "bug".

GRUB2 versions: grub-2.02~beta2, 1.34.1+2.02~beta2-9ubuntu1
Ubuntu version: Trusty (will also affect newer and older versions, GRUB specific problem)

tags: added: grub2-signed
Marc Deslauriers (mdeslaur) wrote :

Thanks for reporting this.

We aren't currently using SecureBoot for security reasons. Our SecureBoot support is only to allow installation on computers that have it enabled by default.

If we ever in the future rely on SecureBoot as a security measure, I agree a warning would be appropriate.

information type: Private Security → Public Security
Changed in grub2-signed (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Dimitri John Ledkov (xnox) wrote :

The purpose of SecureBoot is to prevent untrusted modification of firmware, thus as per SecureBoot specs no unsigned code should be called before ExitBootServices() has been called. Thus one should be targetting as to how to bypass that when booted in secure boot mode. For example the King's & Queen's Gambits vulnerabilities as presented in http://www.mitre.org/sites/default/files/publications/14-2221-extreme-escalation-presentation.pdf

Wouter (wouter-miltenburg) wrote :

The presentation is about a bug in the UEFI implementation itself, which is not related to Secure Boot directly. It can affect Secure Boot and maybe turn it off, but that is not the direction I was looking for in this "bug" report. Of course, we are looking into several other aspects to circumvent Secure Boot, and this presentation is indeed relevant. However, GRUB not verifying the kernel is something what should be done later on or display the user with a warning (as discussed previously).

Indeed, at this moment GRUB is explicitly trying to verify kernels, but will also silently fallback to ignoring failed verification so that users can still boot their systems. Note that this is the case for a few reasons, among which that ensuring a full trust chain is hard when one also has to load modules that are locally built (we can't ship our signing key on all systems, it would defeat the purpose).

Fixing this is the target of spec foundations-x-installing-unsigned-secureboot.

Some basic considerations:
 - fixing grub to not silently ignore validation results
 - provide some way for users to disable validation in shim (MokSB) when they need to use custom drivers or kernels
 - ship mokutil by default so a tool is there to toggle validation

And as later steps:
 - replace disabling validation (MokSB) with allowing users to enroll their own keys from the installer, where we can helpfully walk them through the key generation and enrollment.

We're probably only looking at toggling validation for 16.04.

The net effect of properly relying on shim's validation of the signatures from grub will be to automatically show a "Booting in insecure mode" message when validation is disabled, but SecureBoot is enabled. If SecureBoot is disabled, validation would succeed anyway in both the signed kernels and unsigned kernels.

For more information, I'd refer you to the blueprint or to the source code for shim (https://github.com/rhinstaller/shim), or contact me (cyphermox) on IRC in #ubuntu-installer.

Changed in grub2-signed (Ubuntu):
status: Triaged → In Progress

Re-assigning to grub; this "simply" needs modifying one of the linuxefi patches to not fallback to linux when linuxefi fails; but depends on having the installer, mokutil and some minimal infrastructure (new shim keys) in place to handle making this easy for users to "disable" first if they use DKMS modules.

affects: grub2-signed (Ubuntu) → grub2 (Ubuntu)
Changed in grub2 (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Tim Hitchins (timtjtim) on 2016-01-28
description: updated
kay (kay-diam) wrote :

Will you manage to fix it before xenial release?

Alexander (sality) wrote :

Same problem. Nvidia-prime doesn't works

tags: added: xenial

Resetting to Triaged; we're fixing this, but I can't realistically say that I'm actively working on it at the moment. It involves moving to a new signing key before we can stop grub from falling back to 'linux' when 'linuxefi' validation fails.

This has nothing to do with nvidia-prime or loading whatever drivers -- drivers still load normally, this changes nothing at all but the fact that on a failure to validate the kernel image, grub will still load the badly-signed kernel rather than reporting an error and kicking the user back to the GRUB menu.

Changed in grub2 (Ubuntu):
status: In Progress → Triaged
importance: Wishlist → High
QkiZ (qkiz) wrote :

Ubuntu 16.10. Secure boot is working but I'm able to load unsigned kernel.

QkiZ (qkiz) wrote :

After reboot and load signed kernel I can load unsigned modules.

QkiZ, this is not the bug for that. Please file your own bug, and include the details as to how you did the installation, and including what /proc/sys/kernel/secure_boot and /proc/sys/kernel/moksbstate_disabled report. There can be various reasons for unsigned binaries to be loaded despite Secure Boot being marked as enabled in the firmware.

Thorsten Leemhuis (thleemhuis) wrote :

> there can be various reasons for unsigned binaries to be loaded
> despite Secure Boot being marked as enabled in the firmware.

@cyphermox: I'd be curious to know what these "various reasons" are. Obviously one is: Secure Boot enforcement was disabled via MokManager in Shim. But what other reasons are there? If you have a minute could you please mentione them? tia!

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers