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.
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.
linux thinks secure boot is intact when in fact it has been circumvented and boot time rootkits are present.
the module is rejected.
*** Bug 1262904 has been marked as a duplicate of this bug. ***
*** Bug 1252579 has been marked as a duplicate of this bug. ***
*** Bug 1263195 has been marked as a duplicate of this bug. ***
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
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.
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.