Bug 1264103 - (CVE-2015-5281) CVE-2015-5281 grub2: modules built in on EFI builds that allow loading arbitrary code, circumventing secure boot
CVE-2015-5281 grub2: modules built in on EFI builds that allow loading arbitr...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20151117,reported=2...
: Security
: 1252579 1262904 1263195 (view as bug list)
Depends On: 1264104
Blocks: 1210268 1252821 1263195 1263198
  Show dependency treegraph
 
Reported: 2015-09-17 10:04 EDT by Stefan Cornelius
Modified: 2016-11-08 10:54 EST (History)
7 users (show)

See Also:
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-19 23:38:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stefan Cornelius 2015-09-17 10:04:44 EDT
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 10:07:36 EDT
*** Bug 1262904 has been marked as a duplicate of this bug. ***
Comment 3 Stefan Cornelius 2015-09-17 10:08:07 EDT
*** Bug 1252579 has been marked as a duplicate of this bug. ***
Comment 6 Stefan Cornelius 2015-11-17 04:11:26 EST
*** Bug 1263195 has been marked as a duplicate of this bug. ***
Comment 8 errata-xmlrpc 2015-11-19 07:24:19 EST
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 14:51:31 EST
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 18:22:11 EST
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.

Note You need to log in before you can comment on or make changes to this bug.