CVE-2015-7837: RHEL UEFI Secure Boot


Vulnerability ID 106841
Red Hat Enterprise Linux UEFI Secure Boot privilege escalation

A vulnerability, which was classified as critical, has been found in Red Hat Enterprise Linux (the affected version is unknown). This issue affects an unknown function of the component UEFI Secure Boot. The manipulation with an unknown input leads to a privilege escalation vulnerability. Using CWE to declare the problem leads to CWE-269. Impacted is confidentiality, integrity, and availability. The weakness was released 09/19/2017 (oss-sec). The advisory is shared for download at openwall.com. The identification of this vulnerability is CVE-2015-7837 since 10/15/2015. The exploitation is known to be easy. An attack has to be approached locally. No form of authentication is needed for a successful exploitation. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 09/20/2017).[…]


Comments above seem to incidate a 9/19 update, but I can’t find that, only older messages from 2015-2016. Unclear about current status of this.



Red Hat released RHEL 7.4

One new feature that is news to me:

USB Guard, a feature that allows for greater control over how plug-and-play devices can be used by specific users to help limit both data leaks and data injection.





Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.


[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt



UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:


The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:


Red Hat Satellite GRUB UEFI PXE script

Satellite 6 TFTP boot file legacy grub conversion script

This script is used to convert the tftp boot files (found in /var/lib/tftpboot/pxelinux.cfg/) which are automatically generated by Satellite 6 into the old legacy grub format. Why is this useful? Recently I encountered some HP servers which have an additional 10GbE card in one of the PCI-E slots on the machine which is used for the PXE boot. Unfortunately this additional interface only supports UEFI boot and not classic bios boot. By default Satellite 6 uses the shim image for UEFI but this doesn’t work with the older Linux kernel used by RHEL6.X. If this script is executed on a capsule or satellite server which has TFTP enabled, it will automatically replace the boot files using the old format which gives a successful boot for RHEL6.




Shell script for Laszlo’s SMM test environment article

Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org[1], showing how to setup the EDK2 with QEMU/OVMF for testing SMM code using Fedora.

Recently, Alex Floyd of PreOS Security wrote a shell script to codify this wiki article[2].

Laszlo’s wiki is dense, I expect this script will be useful for some UEFI firmware engineers and security researchers.

According to Alex, “some things needed tweaking to get to work, and the Windows portion of the tutorial is not included in the script.”

[1] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

[2] https://github.com/gencymex/smmtestbuildscript



Background for Kernel Lockdown patch

Re: https://firmwaresecurity.com/2017/04/05/linux-kernel-lockdown-2/

Here’s more background on the Kernel Lockdown patch, from email by David Howells of Red Hat:

The idea is to properly implement UEFI Secure Boot mode such that we can kexec another operating system (Linux, Windows, etc.) and pass on the Secure Boot flag with a guarantee that we haven’t been compromised. This assumes the following:

 (1) Someone wanting to compromise your machine can’t get physical access to the running hardware.  I think pretty much all bets are off if someone gets their hands on your computer.
 (2) Whatever boots our kernel is not itself compromised.  If it is, there’s pretty much nothing we can do about it.
 (3) Whatever boots our kernel can prove that our kernel is what it says it is.

Now, (2) has to start with security right from the system booting, and likely involves the firmware being checked by the hardware.  The firmware then has to validate anything it runs, and the things it runs have to validate anything they run, etc. up to our kernel being booted.

With regard to (3), take the example of booting Fedora Linux on a UEFI PC in secure boot mode: the UEFI BIOS boots the Fedora SHIM, which boots Grub, which boots the kernel.  The SHIM is signed by the UEFI signing authority and is checked against the UEFI key database; Grub and the kernel are signed by a key built into the SHIM.

[Note that in secure boot mode, Grub loads the kernel image asks the SHIM to verify it; further, the SHIM will catch anyone trying to boot without verification and halt the machine.]

[Note that we do verification with cryptographic signatures, but compiled-in hash whitelists would also work.]

In order to maintain the security guarantee, the kernel then needs to prevent unauthorised modification of code and data in the running kernel (module loading is permissible) and also it needs to protect any private keys or other security data it may hold within the image.  We try to do this by the following means:

 (1) Refuse to use any key or hash that UEFI has in its blacklist.
 (2) Refuse to load any module that isn’t signed/hashed.
 (3) Refuse to load any firmware that isn’t signed/hashed.
 (4) Refuse to kexec any image that isn’t signed/hashed.
 (5) Refuse to dump a kernel image for software suspend/hibernation if it’s not encrypted.  Further, if it is encrypted, the key must be protected.
 (6) Refuse to load a dumped kernel image that isn’t encrypted with a protected key.
 (7) Refuse to allow userspace direct access to kernel memory (no /dev/mem,  /dev/kmem, /proc/kcore).
 (8) Refuse to allow userspace direct, unsupervised access to hardware (no iopl, /dev/ioports, MSRs, etc.).  It might be feasible to open PCI BARs through dedicated device files for certain functions though (eg. X servers), but unconstrained DMA must be disallowed.
 (9) Refuse to let userspace configure a driver to use a piece of hardware to muck around with system RAM, possibly by mismatching driver and device.

See the posting on the linux-kernel/efi list for full message.