IBM updates Linux IMA to improve boot security

Thiago Jung Bauermann of IBM has submitted a 6-part patch to the Linux-IMA-devel/Linux-Kernel lists, with some improvements to Linux IMA for OpenPOWER secure/trusted boot. Including comments from parts 1 and 6 of the patch, see the full patch for full details.

Appended signatures support for IMA appraisal

On the OpenPOWER platform, secure boot and trusted boot are being implemented using IMA for taking measurements and verifying signatures. Since the kernel image on Power servers is an ELF binary, kernels are signed using the scripts/sign-file tool and thus use the same signature format as signed kernel modules. This patch series adds support in IMA for verifying those signatures. It adds flexibility to OpenPOWER secure boot, because it can boot kernels with the signature appended to them as well as kernels where the signature is stored in the IMA extended attribute. The first four patches are cleanups and improvements that can be taken independently from the others (and from each other as well). The last two are the ones actually focused on this feature. […] This patch introduces the appended_imasig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule:

appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig|imasig

In the second form, IMA will accept either an appended signature or a signature stored in the extended attribute. In that case, it will first check whether there is an appended signature, and if not it will read it from the extended attribute. The format of the appended signature is the same used for signed kernel modules. This means that the file can be signed with the scripts/sign-file tool, with a command line such as this:

$ sign-file sha256 privkey_ima.pem x509_ima.der vmlinux

This code only works for files that are hashed from a memory buffer, not for files that are read from disk at the time of hash calculation. In other words, only hooks that use kernel_read_file can support appended signatures. The change in CONFIG_INTEGRITY_SIGNATURE to select CONFIG_KEYS instead of depending on it is to avoid a dependency recursion in CONFIG_IMA_APPRAISE_APPENDED_SIG, because CONFIG_MODULE_SIG_FORMAT selects CONFIG_KEYS and Kconfig complains that CONFIG_INTEGRITY_SIGNATURE depends on it.

https://lists.sourceforge.net/lists/listinfo/linux-ima-devel

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

Intel cancels Intel Developer Forum

http://www.anandtech.com/show/11279/intel-discontinues-the-intel-developer-forum-idf17-cancelled

http://www.intel.com/content/www/us/en/intel-developer-forum-idf/san-francisco/2017/idf-2017-san-francisco.html

PS: In other event news, the Fall UEFI Plugfest will be in Taipei instead of Seattle. See the presentations from the last plugfest for details.

Microsoft MDT: moving from BIOS to UEFI

If you have a Windows box and are trying to convert MBR/BIOS installs to GPT/UEFI installs on ‘class 2’ systems, you might want to read this:

https://blogs.technet.microsoft.com/mniehaus/2017/04/14/moving-from-bios-to-uefi-with-mdt-8443/

 

details on Intel’s Bug Bounty Program

The Intel Security Center now has a new page that describes Intel’s Bug Bounty Program:

Intel® launches its first bug bounty program
Intel® Bug Bounty Program

At the CanSecWest Security conference on March 14, 2017, Intel launched its first Bug Bounty program targeted at Intel Products. We want to encourage researchers to identify issues and bring them to us directly so that we can take prompt steps to evaluate and correct them, and we want to recognize researchers for the work that they put in when researching a vulnerability. By partnering constructively with the security research community, we believe we will be better able to protect our customers.

Scope and Severity Ratings

Intel Software, Firmware, and Hardware are in scope. The harder a vulnerability is to mitigate, the more we pay
Vulnerability Severity     Intel Software     Intel Firmware     Intel Hardware
Critical     Up to $7,500     Up to $10,000     Up to $30,000
High     Up to $2,500     Up to $5,000     Up to $10,000
Medium     Up to $1,000     Up to $1,500     Up to $2,000
Low     Up to $500     Up to $500     Up to $1,000

A few details on items that are not in the program scope:

    Intel Security (McAfee) products are not in-scope for the bug bounty program.
    Third-party products and open source are not in-scope for the bug bounty program.
    Intel’s Web Infrastructure is not in-scope for the bug bounty program.
    Recent acquisitions are not in-scope for the bug bounty program for a minimum period of 6 months after the acquisition is complete.

https://security-center.intel.com/BugBountyProgram.aspx

https://security-center.intel.com/default.aspx

 

OEMs still shipping insecure systems…

Note for Intel OEMs: You’re supposed to pass CHIPSEC’s security tests *before* you ship a product. Click on pictures in below tweets to see examples of what your QA test logs should NOT have. 🙂

 

https://twitter.com/desantis/status/845031496473817089

 

apple_set_os.efi: unlock Intel IGD on MacBook Pro

apple_set_os.efi: Tiny EFI program for unlocking the Intel IGD on the Macbook Pro 11,3 for Linux and Windows. It has been made to be easily chainloaded by unmodified EFI bootloader like Grub, rEFInd etc. The Macbook Pro 11,3 model’s EFI is switching off the Intel GPU if you boot anything but Mac OS X. So a little trick by faking the OS identifiction is required to make all hardware accessible. All credits belong to Andreas Heider who originally discovered this hack.[…]

https://github.com/0xbb/apple_set_os.efi

More info:
https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html

Microsoft updates ACPI web page

Microsoft just updated an ACPI doc of theirs:

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/acpi-system-description-tables

It still refers to ACPI 5.0, while current ACPI version is at 6.1, though… No changelog, you’ll have to compare this against your archive of the old version of this web page. 🙂

Different results from reading the 3 URLs:
http://www.uefi.org/acpi_id_list
http://www.uefi.org/acpi
http://www.uefi.org/uefi-acpi-export (exports a spreadsheet)
http://www.uefi.org/specifications

If you use the search ability of the uefi.org site, eg:

http://www.uefi.org/ACPI_ID_List?search=microsoft

it only lists 3 tables. I’d expect it list WSMT, but it does not. Strange. Note that the ACPI search page says it was last updated 2016, so may not have current data to search?

I’d really like to see the ACPI site map the various registries to all of their specs, not have a few separate lists of company registeries, and a separate list of specs, not tied to companies.

 

alloc8 untethered bootrom exploit for iPhone 3GS

Write-up for alloc8: untethered bootrom exploit for iPhone 3GS
alloc8 brings freedom to millions of iPhone 3GS devices, forever, by exploiting a powerful vulnerability in function malloc in the bootrom. Both revisions of iPhone 3GS bootrom are vulnerable, but old bootrom is also vulnerable to 24Kpwn, which is faster than alloc8.[…]

https://github.com/axi0mX/alloc8

Debian signed Shim

Secure Boot chain-loading bootloader (Microsoft-signed binary)

This package provides a minimalist boot loader which allows verifying signatures of other UEFI binaries against either the Secure Boot DB/DBX or against a built-in signature database. Its purpose is to allow a small, infrequently-changing binary to be signed by the UEFI CA, while allowing an OS distributor to revision their main bootloader independently of the CA. This package contains the version of the bootloader binary signed by the Microsoft UEFI CA.

https://packages.debian.org/sid/main/shim-signed

https://wiki.debian.org/SecureBoot

AMD seeks Firmware Security Engineer

MTS Software Development Engineer – Firmware – Security
The Software Security Engineering group is responsible for enabling Platform Security and Content Protection features. The team develops components across the entire software stack including device drivers, firmware, and application level interfaces, enabling customers to build novel solutions while supporting industry standards. […] Design and implement embedded firmware supporting Platform Security features across a wide range of AMD product lines.[…]

https://jobs.amd.com/job/Markham-MTS-Software-Development-Engineer-Firmware-Security-ON/391389700/

Exploiting Broadcom’s WiFi stack, part 2

 […]In this post, we’ll explore two distinct avenues for attacking the host operating system. In the first part, we’ll discover and exploit vulnerabilities in the communication protocols between the Wi-Fi firmware and the host, resulting in code execution within the kernel. Along the way, we’ll also observe a curious vulnerability which persisted until quite recently, using which attackers were able to directly attack the internal communication protocols without having to exploit the Wi-Fi SoC in the first place! In the second part, we’ll explore hardware design choices allowing the Wi-Fi SoC in its current configuration to fully control the host without requiring a vulnerability in the first place. While the vulnerabilities discussed in the first part have been disclosed to Broadcom and are now fixed, the utilisation of hardware components remains as it is, and is currently not mitigated against. We hope that by publishing this research, mobile SoC manufacturers and driver vendors will be encouraged to create more secure designs, allowing a better degree of separation between the Wi-Fi SoC and the application processor.[…]

https://googleprojectzero.blogspot.in/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html

more from Shadow Brokers, Equation Group

https://github.com/misterch0c/shadowbroker

https://steemit.com/shadowbrokers/@theshadowbrokers/lost-in-translation

https://www.bleepingcomputer.com/news/security/shadow-brokers-release-new-files-revealing-windows-exploits-swift-attacks/

Purism and Trammell Hudson partnership

It looks like Purism is going to use Heads now! I hope other OEMs consider some of the features Heads offers.

http://www.marketwired.com/press-release/security-researcher-trammell-hudson-device-maker-purism-join-forces-set-new-standard-2209477.htm

http://finance.yahoo.com/news/security-researcher-trammell-hudson-device-160000558.html

https://puri.sm/posts/purism-collaborates-with-heads-project-to-co-develop-security-focused-laptops/

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.