[…]The UEFI (“Unified Extensible Firmware Interface”) support first introduced in Debian 7 (code name “wheezy”) continues to be greatly improved in Debian 10 “buster”. Secure Boot support is included in this release for amd64, i386 and arm64 architectures and should work out of the box on most Secure Boot-enabled machines. This means users should no longer need to disable Secure Boot support in the firmware configuration.[…]
Hmm, above URL generates an error on the resulting Debian.org-hosted page, but the MARC and Mail-Archive links work, the latter rendered better. The Debian page also wrongly points to the now-dead GMane site, two Debian bugs that need to get fixed…
The author of: Super-UEFIinSecureBoot-Disk < https://firmwaresecurity.com/2019/02/27/super-uefiinsecureboot-disk-is-a-bootable-image-with-grub2-bootloader-designed-to-be-used-as-a-base-for-recovery-usb-flash-drives/ > has a new post on Habr.com (in Russian) on UEFI Secure Boot security.
Excerpt of Google Translation: […]In this article we proved the existence of not enough reliable bootloaders signed by Microsoft key, which allows booting untrusted code in Secure Boot mode. Using signed Kaspersky Rescue Disk files, we achieved a silent boot of any untrusted .efi files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK. These files can be used both for good deeds (for booting from USB flash drives) and for evil ones (for installing bootkits without computer owner consent).[…]
Steve McIntyre has updated the Debian wiki page for Secure Boot “to cover a lot more user-facing stuff.”
Steve McIntyre has posted an update on Debian’s UEFI Secure Boot status, to the debian-boot and debian-efi mailing lists. Excerpt:
I’ve just pushed changes to a few bits of d-i this weekend to make SB work for amd64:
* build/util/efi-image: […]
* build/config/arm.cfg, build/config/x86.cfg: […]
* debian/control: […]
* grub-installer/grub-installer: […]
The effect of these changes is that the next daily and weekly debian installer images (tomorrow) should Just Work (TM) end-to-end with UEFI Secure Boot. The changes to efi-image also mean that our next live image builds will do SB (for live and installation).
I’ll test all these again in the next couple of days to verify that things have pulled through as I expect, then it’s time to post to d-d-a and write a blog too. We’ve made great progress already. These last changes just tie it all together for end users.
Apple has — at least I think so — updated their Secure Boot knowledge base article in the last few days:
The Linux kernel, as used in Ubuntu 18.10 and when booted with UEFI Secure Boot enabled, allows privileged local users to bypass intended Secure Boot restrictions and execute untrusted code by loading arbitrary kernel modules. This occurs because a modified kernel/module.c, in conjunction with certain configuration options, leads to mishandling of the result of signature verification.[…]
Description Last Modified: 10/25/2018
[…]This flaw is introduced by certain configuration options in combination with this out-of-tree patch from the Lockdown patchset[…]
Current Exploit Price (≈) $5k-$25k
This script provides commands to sign a designated list of kernel modules and loads them via modprobe into the linux kernel. This was built to specfically address the issue of having to re-sign and reload kernel modules after upgrading the linux kernel, so they are not rejected by UEFI Secure Boot. (e.g. virtualbox kernel modules). As an example, this script is defaulted to load virtualbox kernel modules and will look for the private key and x509 cert in a specific directory. Please change these values inside the script as needed.[…]
The UK government has guidance on secure usage of Ubuntu. It appears to be newly-written.
Lots of useful information, and it mentions that Secure Boot is only active at some time: nice to see that level of detail.
Secure Boot section:
Secure boot validates the bootloader, kernel and kernel modules. However, some boot-related files are not protected by default and could be modified by an attacker to tamper with the boot process. Hardening of the boot process can help mitigate the risk.
Ubuntu does not use any dedicated hardware to protect its disk encryption keys. If an attacker can get physical access to the device, they can perform an offline brute-force attack to recover the encryption password.
Encryption keys protecting sensitive data remain available to an attacker when the device is locked. This means that if the device is attacked while powered on and locked, keys and data on the device may be compromised without the attacker knowing the password.
I just noticed this nice document on Ubuntu security features, maybe it is new, maybe I never noticed it before:
I also notice this page, which I believe has recently been updated:
DKMS modules need to be configured to work with UEFI Secure Boot
Ubuntu is now checking module signing by default, on kernels 4.4.0-18.34, 4.4.0-21.37, 4.2.0-42.49, 3.19.0-65.73 and 3.13.0-92.139 onwards. You can read more details in this bug in Launchpad. Because of those changes, DKMS modules will not work on systems with Secure Boot enabled unless correctly configured. In order to make DKMS work, Secure Boot signing keys for the system must be imported in the system firmware, otherwise Secure Boot needs to be disabled. There are several methods to configure your system to properly load DKMS modules with Secure Boot enabled.
I believe this is a new (or revised) document [to me].
[…]VMware Tools version 10.1 or later is required for virtual machines that use UEFI secure boot. You can upgrade those virtual machines to a later version of VMware Tools when it becomes available.
For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode. Remove VMware Host-Guest Filesystem from VMware Tools before you enable secure boot.[…]
Cryptology ePrint Archive: Report 2018/427
Secure Boot and Remote Attestation in the Sanctum Processor
During the secure boot process for a trusted execution environment, the processor must provide a chain of certificates to the remote client demonstrating that their secure container was established as specified. This certificate chain is rooted at the hardware manufacturer who is responsible for constructing chips according to the correct specification and provisioning them with key material. We consider a semi-honest manufacturer who is assumed to construct chips correctly, but may attempt to obtain knowledge of client private keys during the process. Using the RISC-V Rocket chip architecture as a base, we design, document, and implement an attested execution processor that does not require secure non-volatile memory, nor a private key explicitly assigned by the manufacturer. Instead, the processor derives its cryptographic identity from manufacturing variation measured by a Physical Unclonable Function (PUF). Software executed by a bootloader built into the processor transforms the PUF output into an elliptic curve key pair. The (re)generated private key is used to sign trusted portions of the boot image, and is immediately destroyed. The platform can therefore provide attestations about its state to remote clients. Reliability and security of PUF keys are ensured through the use of a trapdoor computational fuzzy extractor.
We present detailed evaluation results for secure boot and attestation by a client of a Rocket chip implementation on a Xilinx Zynq 7000 FPGA.
System x Secure Boot Vulnerability
Lenovo Security Advisory: LEN-20241
Potential Impact: Booting unauthenticated code
Scope of Impact: Lenovo-only
CVE Identifier: CVE-2017-3775
Lenovo internal testing discovered some System x server BIOS/UEFI versions that, when Secure Boot mode is enabled by a system administrator, do not properly authenticate signed code before booting it. As a result, an attacker with physical access to the system could boot unsigned code. Lenovo ships these systems with Secure Boot disabled by default, because signed code is relatively new in the data center environment, and standard operator configurations disable signature checking. Apply the BIOS/UEFI update appropriate for your model described in the product impact section below. If you are relying on Secure Boot, you may want to control physical access to systems prior to applying the updates.[…]
On the Path to a Secure Boot Solution for RISC-V
By SecureRF | April 26, 2018 | 0
As the RISC-V ISA gains in popularity and more industries proceed with plans to build and deploy systems based on RISC-V technologies, the security requirements of those systems will grow. One avenue that hackers have used to exploit systems has been to modify the firmware and cause it to misbehave. For example, one of the recent vehicle hacks involved corrupting firmware in order to jump from an infotainment center to the CAN-BUS. The solution to this style of attack is a secure boot, and with minimal additions to the ISA, RISC-V can provide secure boot hooks directly. Secure boot is a self-hosted root of trust that uses a digital signature and a known, trusted, public key to protect the firmware before it loads. The RISC-V system validates the signature over the firmware using the trusted public key and will run the code only if the signature verifies correctly. If the firmware has been modified in any way, the signature validation will fail. Once this initial trusted load completes, subsequent loads can use the same process to chain the trust to additional loads.[…]
Click on above URL or remove spaces in below URL (WordPress mangles Github Gist URLs…)
https://gist. github.com/mattifestation /f1e160bc970c8a7b82355d7e5946901b