Bug 1264103 (CVE-2015-5281)

Summary: CVE-2015-5281 grub2: modules built in on EFI builds that allow loading arbitrary code, circumventing secure boot
Product: [Other] Security Response Reporter: Stefan Cornelius <scorneli>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: dwmw2, fweimer, mbanas, pjones, scorneli, security-response-team, slawomir, slong
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
It was discovered that grub2 builds for EFI systems contained modules that were not suitable to be loaded in a Secure Boot environment. An attacker could use this flaw to circumvent the Secure Boot mechanisms and load non-verified code. Attacks could use the boot menu if no password was set, or the grub2 configuration file if the attacker has root privileges on the system.
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-20 04:38:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1264104    
Bug Blocks: 1210268, 1252821, 1263195, 1263198    

Description Stefan Cornelius 2015-09-17 14:04:44 UTC
Quoting from bug #1262904:
Description of problem:

Long long ago somebody committed http://pkgs.devel.redhat.com/cgit/rpms/grub2/commit/?h=rhel-7.2&id=909ac684df7a662e7afd9d45d546ad97d363d197 to our grub2 packages in RHEL 7.  While the first hunk is correct, the second hunk is pretty much purely wrong.  The last two changes got reverted immediately, but the multiboot and multiboot2 modules remained built in.

Those modules /should not/ function on UEFI systems, but there's no code in them that actually stops them from doing so, and therefore they allow a user to load non-verified code, such as tools to circumvent Secure Boot.

Since Secure Boot is a security feature of RHEL 7, that means this is a security problem in RHEL 7.

Version-Release number of selected component (if applicable):

It's everything in RHEL 7.

How reproducible:

100% of the time; there's no conditional behavior here.  The user can do it from the boot menu of there's no password set, or if they've already rooted the machine they can do it from the config file.

Steps to Reproduce:
1. write a multiboot module that replaces some EFI runtime call pointers or whatever other attack you might like
2. add it to the configfile to load before the linux kernel, loading the kernel as a mutliboot module.
3. reboot.

Actual results:

linux thinks secure boot is intact when in fact it has been circumvented and boot time rootkits are present.

Expected results:

the module is rejected.

Comment 2 Stefan Cornelius 2015-09-17 14:07:36 UTC
*** Bug 1262904 has been marked as a duplicate of this bug. ***

Comment 3 Stefan Cornelius 2015-09-17 14:08:07 UTC
*** Bug 1252579 has been marked as a duplicate of this bug. ***

Comment 6 Stefan Cornelius 2015-11-17 09:11:26 UTC
*** Bug 1263195 has been marked as a duplicate of this bug. ***

Comment 8 errata-xmlrpc 2015-11-19 12:24:19 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2015:2401 https://rhn.redhat.com/errata/RHSA-2015-2401.html

Comment 9 Fedora Update System 2015-11-24 19:51:31 UTC
grub2-2.02-0.24.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2015-11-30 23:22:11 UTC
grub2-2.02-0.17.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.