Uncategorized

Linux kernel lockdown patch

David Howells of Red Hat has posted the latest version of the ‘kernel lockdown’ patch to the Linux-EFI mailing list. The latest patch includes a manpage, see the LWN article below for text. For more info, see the full 27-part patch on the linux-efi mailing list.

AFAICT, no Linux distros use this patch. Why?!

The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded.

Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available. Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysRq combination to lift the lockdown. On x86 this is SysRq+x. The keys must be pressed on an attached keyboard. Enabling CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT will cause EFI secure boot to trigger kernel lockdown.

http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down
http://vger.kernel.org/majordomo-info.html
https://lwn.net/Articles/736910/

Standard
Uncategorized

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).[…]

https://tsecurity.de/de/206729/Reverse-Engineering/Exploits/Red-Hat-Enterprise-Linux-UEFI-Secure-Boot-erweiterte-Rechte-CVE-2015-7837/
https://vuldb.com/?id.106841
http://nakedsecurity.com/cve/CVE-2015-7837/
https://cxsecurity.com/cveshow/CVE-2015-7837
http://www.openwall.com/lists/oss-security/2015/10/15/6
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7837
https://www.security-database.com/detail.php?alert=CVE-2015-7837

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.

 

Standard
Uncategorized

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.

https://www.redhat.com/en/about/press-releases/red-hat-bridges-hybrid-multi-cloud-deployments-latest-version-red-hat-enterprise-linux-7

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/index.html

 

Standard
Uncategorized

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.

https://github.com/gencymex/smmtestbuildscript

[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

 

Standard
Uncategorized

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:

http://wiki.qemu.org/ChangeLog/2.9

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:
https://getfedora.org/
https://en.wikipedia.org/wiki/System_Management_Mode

Standard
Uncategorized

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.

https://github.com/RedHat-Consulting-UK/sat6-efi-converter

 

Standard
Uncategorized

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

https://github.com/gencymex/smmtestbuildscript/blob/master/smmtesthost.sh

Standard