Oracle Solaris 11.4: UEFI Secure Boot on Intel HW

UEFI Secure Boot on Oracle Solaris x86 enables you to install and boot Oracle Solaris on platforms where UEFI Secure Boot is enabled. This feature provides more security by maintaining a chain of trust during boot: digital signatures of the firmware and software are verified before executing the next stage. No break occurs in the chain because of unsigned, corrupt, or rogue firmware or software during the boot process. This feature helps assure that the firmware and software used to boot Oracle Solaris on a hardware platform is correct, and has not been modified or corrupted.

https://docs.oracle.com/cd/E72435_01/html/E72445/grijo.html
https://docs.oracle.com/cd/E37838_01/html/E60974/index.html
https://blogs.oracle.com/solaris/oracle-solaris-114-beta-released
https://github.com/oracle/solaris-userland/tree/master/components/shim
https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Linux-7-Update-4

 

 

MacAdmins Podcast: Episode 70: Secure Boot

Synopsis: Tim Perfitt joins the pod to talk about SecureBoot, the iMac Pro, the future of securing everything, and the history of BootRunner and other products at Twocanoes.

Your Hosts:
Tom Bridge, Partner at Technolutionary LLC [@tbridge]
Pepijn Bruienne, R&D Engineer at Duo Security [@bruienne], Proprietor of EnterpriseMac.Bruienne.com
Charles Edge, Director of Marketplace at Jamf, [@cedge318]

Guests: Tim Perfitt, Founder of Twocanoes Software

https://podcast.macadmins.org/2018/02/21/episode-70-tim-perfitt-twocanoes-software/

show notes:

https://twocanoes.com/secureboot-imac-pro/

Dell Sputnik systems disable Secure Boot

“Dell ship their Sputnik systems with a pre-populated MokSB variable that disables Secure Boot, so this is working as intended on the Fedora side.”

https://bugzilla.redhat.com/show_bug.cgi?id=1544794

Payment card Industry: Secure Boot == Verified Boot == “Trusted Boot”

I just noticed that the PCI compliance group lumps all of the Trusted/Measured/Verified/Secure boot technologies into one, and calls it Trusted Boot, which, AFAIK, is the name for Intel TXT-based Trusted Boot. I wish they were more precise. Then again, I guess I should be glad there is *SOME* firmware security in the PCI compliance docs, I wish there was more, system should check firmware-based code for malware, not just OS-based code.

Payment Card Industry (PCI)
Software-based PIN Entry on COTS Security Requirements
Version 1.0, January 2018
[…]
The PIN CVM Application must only support platforms that, at a minimum, provide the following features:

* An enforcing mandatory access control framework
* A “trusted boot” mechanism that validates the operating system’s authenticity

Trusted Boot: A cryptographic process where the bootloader verifies the integrity of all components (e.g., kernel objects) loaded during operating system start-up process, before loading. Also known as Verified Boot and Secure Boot (e.g., Google or Apple).
[…]

https://www.pcisecuritystandards.org/ptsdocs/RP450RP456RP457_PCI_Security_Policy-1461704231.78085.pdf

 

Aleph Security: Firehorse: Research & Exploitation framework for Qualcomm EDL (Firehose)

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
By Roee Hay (@roeehay) & Noam Hadad
January 22, 2018
* QPSIIR-909, ALEPH-2017029, CVE-2017-13174, CVE-2017-5947

There are many guides across the Internet for ‘unbricking’ Qualcomm-based mobile devices. All of these guides make use of Emergency Download Mode (EDL), an alternate boot-mode of the Qualcomm Boot ROM (Primary Bootloader). To make any use of this mode, users must get hold of OEM-signed programmers, which seem to be publicly available for various such devices. While the reason of their public availability is unknown, our best guess is that these programmers are often leaked from OEM device repair labs. Some OEMs (e.g. Xiaomi) also publish them on their official forums. […] In this 5-part blog post we discuss the security implications of the leaked programmers. The first part presents some internals of the PBL, EDL, Qualcomm Sahara and programmers, focusing on Firehose. In Part 2, we discuss storage-based attacks exploiting a functionality of EDL programmers – we will see a few concrete examples such as unlocking the Xiaomi Note 5A (codename ugglite) bootloader in order to install and load a malicious boot image thus breaking the chain-of-trust. Part 3, Part 4 & Part 5 are dedicated for the main focus of our research – memory based attacks. In Part 3 we exploit a hidden functionality of Firehose programmers in order to execute code with highest privileges (EL3) in some devices, allowing us, for example, to dump the Boot ROM (PBL) of various SoCs. We then present our exploit framework, firehorse, which implements a runtime debugger for firehose programmers (Part 4). We end with a complete Secure-Boot bypass attack for Nokia 6 MSM8937, that uses our exploit framework. We achieve code execution in the PBL (or more accurately, in a PBL clone), allowing us to defeat the chain of trust, gaining code execution in every part of the bootloader chain, including TrustZone, and the High Level OS (Android) itself.

The merit of our research is as follows:
* We describe the Qualcomm EDL (Firehose) and Sahara Protocols. (Part 1)
* We created firehorse, a publicly available research framework for Firehose-based programmers, capable of debugging/tracing the programmer (and the rest of the bootloader chain, including the Boot ROM itself, on some devices). (Part 3 & Part 4)
* We obtained and reverse-engineered the PBL of various Qualcomm-based chipsets (MSM8994/MSM8917/MSM8937/MSM8953/MSM8974) using the Firehose programmers and our research framework. (Part 3)
* We obtained the RPM & Modem PBLs of Nexus 6P (MSM8994). (Part 3)
* We managed to unlock & root various Android Bootloaders, such as Xiaomi Note 5A, using a storage-based attack only. (Part 2)
* We managed to manifest an end-to-end attack against our Nokia 6 device running Snapdragon 425 (MSM8937). We believe this attack is also applicable for Nokia 5, and might be even extensible to other devices, although unverified. (Part 5)

Research & Exploitation framework for Qualcomm EDL Firehorse programmers
https://github.com/alephsecurity/firehorse

Exploiting Qualcomm EDL Programmers (1): Gaining Access & PBL Internals
https://alephsecurity.com/2018/01/22/qualcomm-edl-1/

Exploiting Qualcomm EDL Programmers (2): Storage-based Attacks & Rooting
https://alephsecurity.com/2018/01/22/qualcomm-edl-2/

Exploiting Qualcomm EDL Programmers (3): Memory-based Attacks & PBL Extraction
https://alephsecurity.com/2018/01/22/qualcomm-edl-3/

Exploiting Qualcomm EDL Programmers (4): Runtime Debugger
https://alephsecurity.com/2018/01/22/qualcomm-edl-4/

Exploiting Qualcomm EDL Programmers (5): Breaking Nokia 6’s Secure Boot
https://alephsecurity.com/2018/01/22/qualcomm-edl-5/

 

Insyde Software security updates for Windows 10

Hurray, UEFI vendors focusing on security! 🙂

Insyde® Software Highlights Strategies to Strengthen Firmware Security at the Fall UEFI Plugfest

Company’s Chief Technology Officer to Present at The UEFI Forum Plugfest in Taipei, Taiwan

[…]In related UEFI-security news, Insyde Software announced its full compliance with the latest firmware security updates needed by Microsoft’s upcoming Windows® release. The Windows 10 Fall Creators Update adds new requirements that include improved support for TPMs (Trusted Platform Modules) and new functionality for Secure Boot BIOS update, all of which is fully supported by InsydeH2O® UEFI BIOS.[…]

https://www.insyde.com/press_news/press-releases/insyde%C2%AE-software-highlights-strategies-strengthen-firmware-security-fall

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.

 

dbxparser: PowerShell script to parse UEFI DBX blacklist

dbxparser.ps1 is a PowerShell script that: dumps SHA256 hashes of blacklisted UEFI bootloaders from the ‘dbx’ UEFI variable.

Darn, Github chokes on Github Gist URLs. Remove the 3 spaces from the below URL, or click on the above Tweet.

https:// gist. github. com/mattifestation/991a0bea355ec1dc19402cef1b0e3b6f

Booting Windows from USB drive

Here’s a MSDN blog entry on how to boot Windows via a thumbdrive. It is basically an introduction to Rufus…

Installing Windows with Secure Boot from USB drive
July 18, 2017
by Anders Lybecker

Once and a while I reinstall my machine. It feels nice with a clean slate as I tend to install all kinds of applications that pollutes my machine. A newly installed machine just runs better somehow. My machine needs to be secure, so Secure Boot and encrypted drive via BitLocker is a must. It limits the risk of someone messing with my machine and stealing my data. Here is how…[…]

https://blogs.msdn.microsoft.com/lybecker/2017/07/18/installing-windows-with-secure-boot-from-usb-drive/

http://www.lybecker.com/blog/2017/07/18/installing-windows-with-secure-boot-from-usb-drive/

https://github.com/pbatard/rufus

https://rufus.akeo.ie/

BTW, these days it is pretty rare to see a modern open source GUI tool that is written to use the native Windows Win32 GUI (GDI). These days, most GUIs are written using friendlier GUI frameworks/languages. Rufus is an ‘old school’ Windows tool, no drag-and-drop IDE-generated GUI code… 🙂

https://github.com/pbatard/rufus/blob/master/src/rufus.c

NXP: designing IoT devices with secure boot

NXP has a webinar for IoT makers, talking about secure booting. ‘Webinar’ scared me, but there’s no registration required. 🙂

Watch this on-demand presentation to learn how to:
* Manage the life cycle of an IoT edge node from development to deployment.
* Leverage hardware and software offerings available with the Kinetis MCU portfolio that can help you protect against attacks.
* Ease the burden of secure IoT edge node development using new processors and architectures from ARM.

https://community.arm.com/processors/trustzone-for-armv8-m/b/blog/posts/designing-secure-iot-devices-starts-with-a-secure-boot

http://www.nxp.com/video/designing-secure-iot-devices-starts-with-a-secure-boot:DESIGNING-SECURE-IOT-DEVICES

slides: https://www.nxp.com/docs/en/supporting-information/Designing-Secure-IoT-Devices-Starts-with-a-Secure-Boot.pdf

http://www.nxp.com/docs/en/supporting-information/Designing-Secure-IoT-Devices-Starts-with-a-Secure-Boot.pdf

Matthew on improving UEFI Secure Boot on Linux with TPMs

http://mjg59.dreamwidth.org/48897.html

IBM OpenPower secure and trusted boot, Part 2

OpenPOWER secure and trusted boot, Part 2
Protecting system firmware with OpenPOWER secure boot
Making your system safe against boot code cyberattacks
Dave Heller and Nageswara Sastry
Published on June 05, 2017

This content is part 2 of 2 in the series: OpenPOWER secure and trusted boot. IBM® OpenPOWER servers offer two essential security features, trusted boot and secure boot, to help ensure the integrity of your server and safeguard against a boot code cyberattack. Trusted boot works by creating secure recordings, or measurements, of executable code as the system boots. Using a process known as remote attestation, you can retrieve these measurements securely and use them to verify the integrity of your firmware or target operating system (OS). Secure boot helps ensure the integrity of your OS and firmware as well. But rather than taking measurements for later examination, secure boot performs the validation in place, during boot, and will halt the boot process if the validation fails. These two features are complementary and work together to provide comprehensive protection of platform boot code. This article explores the secure boot method, with particular focus on protection of system firmware.[…]

https://www.ibm.com/developerworks/library/l-protect-system-firmware-openpower/

Part 1 is from Feburary:

https://www.ibm.com/developerworks/linux/library/l-trusted-boot-openPOWER-trs/index.html?ca=drs-

 

sicherboot: systemd Secure boot integration

systemd Secure boot integration

sicher*boot automatically installs systemd-boot and kernels for it into the ESP, signed with keys generated by it. The signing keys are stored unencrypted and only protected by the file system permissions. Thus, you should make sure that the file system they are stored (usually /etc) in is encrypted. After installing sicherboot, you can adjust a number of settings in /etc/sicherboot.conf and should set a kernel commandline in /etc/kernel/cmdline. Then run ‘sicherboot setup’ to get started.

 

https://github.com/julian-klode/sicherboot

Mike on Windows Config Mgr and Secure Boot

Mike Terrill has 2 blog posts on Windows Configuration Manager and UEFI Secure Boot:

BIOS and Secure Boot State Detection during a Task Sequence
With all of the security issues and malware lately, BIOS to UEFI for Windows 10 deployments is becoming a pretty hot topic (unless you have been living under a rock, UEFI is required for a lot of the advanced security functions in Windows 10). In addition, with the Windows 10 Creators Update, Microsoft has introduced a new utility called MBR2GPT that makes the move to UEFI a non-destructive process. If you have already started deploying Windows 10 UEFI devices, it can be tricky to determine what state these devices are in during a running Task Sequence. The Configuration Manager Team introduced a new class called SMS_Firmware and inventory property called UEFI that helps determine which computers are running in UEFI in Current Branch 1702. This can be used to build queries for targeting and reports, but it would be nice to handle this plus Secure Boot state (and CSM) during a running Task Sequence. We do have the Task Sequence variable called _SMSTSBootUEFI that we will use, but we need to determine the exact configuration in order to execute the correct steps.[…]

BIOS and Secure Boot State Detection during a Task Sequence Part 1

BIOS and Secure Boot State Detection during a Task Sequence Part 2

 

UEFI-SecureBoot-SignTool

Aneesh Neelam has written UEFI-SecureBoot-SignTool, a script to sign external Linux kernel modules for UEFI Secure Boot.


UEFI Secure Boot sign tool

The default signed Linux kernel on Ubuntu (>=16.04.x), Fedora (>=18) and perhaps on other distributions as well, won’t load unsigned external kernel modules if Secure Boot is enabled on UEFI systems. Hence, any external kernel modules like the proprietary Nvidia kernel driver, Oracle VM VirtualBox’s host/guest kernel driver etc. won’t work. External kernel modules must be signed for UEFI Secure Boot using a Machine Owner Key (MOK). You can use the UEFI Secure Boot Sign Tool to sign kernel modules. This is useful if you can’t or don’t wish to disable Secure Boot on your UEFI-enabled system.[…]

https://github.com/aneesh-neelam/UEFI-SecureBoot-SignTool

 

 

Secure Boot BOF at DebConf17

Helen Koike of Collabora has proposed a BOF on UEFI Secure Boot at DebConf17, this August:

DebConf17 – BoF proposal to discuss secure boot
I want to send a BoF proposal to DebConf17 so we can meet there and discuss about secure boot. I would like to know if you are interested in attending and also which topics you suggest for discussion. I would appreciate if you could put your name and suggestions in this form in case you are interested https://goo.gl/forms/lHoEibY1H6FmSHSJ2 , or just reply to this email thread.

For full message, see the debian-efi mailing list archives.

https://lists.debian.org/debian-efi/2017/05/threads.html

https://docs.google.com/forms/d/e/1FAIpQLSdtHYNy9212iXP26tkjbb6XvgVSMjJzn2DYoAilFT1l89vemw/viewform?c=0&w=1

https://debconf17.debconf.org/

 

 

Secure Boot for VMWare

Secure Boot for ESXi 6.5 – Hypervisor Assurance
Mike Foley
I’ve talked about how vSphere has been moving towards a “secure by default” stance over the past few years. This can clearly be seen in the new vSphere 6.5 Security Configuration Guide where the number of  “hardening” steps are growing smaller with every release. In this blog post we will go over another “secure by default” feature of vSphere 6.5 that provides hypervisor assurance, Secure Boot for ESXi. One of the coolest things in 6.5,  in my opinion, is the adoption of Secure Boot for ESXi. Now, you might say “But my laptop has had Secure Boot  since Windows 8, what’s the big deal?” Well, the “big deal” is that we’ve gone beyond the default behavior of Secure Boot and we now leverage the capabilities of the UEFI firmware to ensure that ESXi not only boots with a signed bootloader validated by the host firmware but that it also ensures that unsigned code won’t run on the hypervisor. Best of all, it’s simple to implement! Let’s dive in![…]

https://blogs.vmware.com/vsphere/2017/05/secure-boot-esxi-6-5-hypervisor-assurance.html

 

more on Intel AMT story

Time for IBVs and OEMs to start issuing Intel AMT reports, not just from Intel. Lenovo has one:

https://support.lenovo.com/us/en/product_security/len-14963

https://downloadcenter.intel.com/download/26754/INTEL-SA-00075-Mitigation-Guide

(I hope no FUD is coming from this blog. However, I can see why people would merge two background technologies they have no control over. For example:

https://arstechnica.com/security/2017/05/intel-patches-remote-code-execution-bug-that-lurked-in-cpus-for-10-years/