First published: Thu Sep 17 2015(Updated: )
Quoting from <a class="bz_bug_link bz_secure " title="" href="show_bug.cgi?id=1262904">bug #1262904</a>: """ Description of problem: Long long ago somebody committed <a href="http://pkgs.devel.redhat.com/cgit/rpms/grub2/commit/?h=rhel-7.2&id=909ac684df7a662e7afd9d45d546ad97d363d197">http://pkgs.devel.redhat.com/cgit/rpms/grub2/commit/?h=rhel-7.2&id=909ac684df7a662e7afd9d45d546ad97d363d197</a> 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. """
Credit: secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Redhat Enterprise Linux | =7.0 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.