Ubuntu has a white-paper that discusses Secure Boot, amongst other things. But you have to register for it, it is not publicly-available.
Tag: Ubuntu
Ubuntu bug 1798863, CVE-2018-18653, UEFI Secure Boot vuln
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.[…]
Source: MITRE
Description Last Modified: 10/25/2018
https://nvd.nist.gov/vuln/detail/CVE-2018-18653
[…]This flaw is introduced by certain configuration options in combination with this out-of-tree patch from the Lockdown patchset[…]
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798863
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798863/comments/23
https://vuldb.com/?id.125976
Current Exploit Price (≈) $5k-$25k
UK Gov security guidance for Ubuntu, including Secure Boot
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.
https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1804-lts
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.
Ubuntu: DKMS modules need to be configured to work with UEFI Secure Boot
I just noticed this nice document on Ubuntu security features, maybe it is new, maybe I never noticed it before:
https://wiki.ubuntu.com/Security/Features#secure-boot
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.
https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566221
ZFS-on-Root-Installer: Install ZFS on Root with Ubuntu
A Bare Metal Installer for ZFS on Root
This repository is intended to produce a bootable UEFI image that allows installing a full bare system with ZFS disks. Be aware that it is not intended for building dual-boot systems. While you are given the ability to choose which disks are used, the EFI boot system will wipe other OS entries. It uses an Ubuntu kernel and a minimal ramdisk builder to host the scripts used to perform the actual install.[…]
https://github.com/symmetryinvestments/zfs-on-root-installer
Ubuntu 17.10 corrupting BIOS – many Lenovo laptops models (and Acer and Toshiba)
“Canonical has pulled downloads for its Ubuntu 17.10 Linux distribution following reports that it can trigger a bug in the UEFI firmware of selected Lenovo, Acer, and Toshiba laptops, corrupting the BIOS and disabling the ability to boot from USB Drives.”
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
Thunderbolt-software-user-space in Ubuntu
Colin Ian King of Canonical has been packaging up the Intel Thunderbolt user-space software for Ubuntu. His Tweets are private, but he just tweeted that the tool is now in Ubuntu!
https://github.com/01org/thunderbolt-software-user-space
https://launchpad.net/~colin-king/+archive/ubuntu/thunderbolt/+packages
https://thunderbolttechnology.net/
https://01.org/thunderbolt-sw
https://thunderbolttechnology.net/fun-facts
Thunderbolt user-space components:
[…]The user-space components implement device approval support:
* Easier interaction with the kernel module for approving connected devices.
* ACL for auto-approving devices white-listed by the user.
So far, I’ve not found a public security page for Thunderbolt. Only a “Fun Facts” page… 😦 I was hoping to find a page listing Thunderstrike, Thunderstrike2, the Legbacore t2e tool, CIA Sonic Screwdriver, PCILeech, etc.
https://trmm.net/Thunderstrike
https://github.com/legbacore/t2e_integrity_check
Hyper-V UEFI bootloader complexities
[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]
OpenCIT 2.2 released
Adolfo V Aguayo of Intel announced the version 2.2 release of OpenCIT.
New Features in 2.2:
– TPM 2.0 support.
+ Added support for platform and asset tag attestation of Linux and Windows hosts with TPM 2.0.
+ Support attestation of either SHA1 or SHA256 PCR banks on TPM 2.0.
+ Ubuntu 16.04 and RHEL 7.2, 7.3 (SHA1 and SHA256), Windows Server 2012 and Hyper-V Server 2012 (SHA1) are supported with TPM 2.0
– All the certificates and hashing algorithms used in CIT are upgraded to use SHA256. SHA1 has been deprecated and will no longer be used.
– CIT Attestation Service UI has been updated to allow the user to select either the SHA1 or SHA256 PCR bank for Attestation of TPM 2.0 hosts.
+ The CIT Attestation Service will automatically choose the strongest available algorithm for attestation (SHA1 for TPM 1.2, and SHA256 for TPM 2.0)
– CIT Attestation Service UI Whitelist tab no longer requires the user to select PCRs when whitelisting, and will automatically choose the PCRs to use based on the host OS and TPM version. This is done to reduce confusion due to differing behaviors between TPM 1.2 and TPM 2.0 PCR usages.
– Additional changes made to support TPM 2.0:
+ Linux hosts with TPM 2.0 will now utilize TPM2.0-TSS (TPM 2.0 Software Stack) and TPM2.0-tools instead of the legacy trousers and tpm-tools packages. The new TSS2 and TPM2.0-tools are packaged with the CIT Trust Agent installer.
+ TPM 2.0 Windows hosts use TSS.MSR (The TPM Software Stack from Microsoft Research) PCPTool.
+ TPM 1.2 hosts will continue to use the legacy TSS stack (trousers) and tpm-tools components.
For more information, see the full announcement on the oat-devel@lists.01.org mailing list.
SeaBIOS ACPI patch fixing Ubuntu/Windows installs
Bin Meng posted an 18-part patch to the SeaBIOS list, fixing multiple issues that may impact the installation of Ubuntu (only Ubuntu and no other Linux distros??) and Windows:
[PATCH v2 00/18] x86: acpi: Support installation of Ubuntu/Windows and boot Windows
SeaBIOS can be loaded by U-Boot to aid the installation of Ubuntu and Windows to a SATA drive and boot from there. But till now this is broken. The installation either hangs forever or just crashes. This series fixed a bunch of issues that affect the installation of Ubuntu and Windows, and booting Windows.
Testing was performed on MinnowMax by:
– Install Ubuntu 14.04 and boot
– Install Windows 8.1 and boot
– Install Windows 10 and boot
This series is available at u-boot-x86/acpi2-working.
Changes in v2:
– New patch to remove the unnecessary checksum calculation of DSDT
– New patch to remove header length check when writing tables
– New patch to enable SeaBIOS on all boards
– New patch to add GPIO ASL description
Bin Meng (18):
x86: minnowmax: Adjust U-Boot environment address in SPI flash
x86: Call board_final_cleanup() in last_stage_init()
x86: Fix up PIRQ routing table checksum earlier
x86: Compile coreboot_table.c only for SeaBIOS
x86: Prepare configuration tables in dedicated high memory region
x86: Unify reserve_arch() for all x86 boards
x86: Reserve configuration tables in high memory
x86: Use high_table_malloc() for tables passing to SeaBIOS
x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM
x86: acpi: Remove the unnecessary checksum calculation of DSDT
x86: acpi: Remove header length check when writing tables
x86: doc: Update information about IGD with SeaBIOS
x86: baytrail: Enable SeaBIOS on all boards
x86: doc: Mention Ubuntu/Windows installation and boot support
acpi: Quieten IASL output when ‘make -s’ is used
x86: baytrail: Add internal UART ASL description
x86: baytrail: Add GPIO ASL description
x86: doc: Add porting hints for ACPI with Windows
For more information, see the U-Boot list:
http://lists.denx.de/mailman/listinfo/u-boot
ubuntu-secure-boot package
James Johnson has a project to help make Secure Boot on Ubuntu. Excerpt of readme:
ubuntu-secure-boot package
The stock Ubuntu 15.10 installation only implements secure boot just enough to get a Microsoft-signed shim in place. It does nothing to actually secure the boot process. This package can help users do so.
Features of ubuntu-secure-boot:
* Self-signed bootloader files: take control over your boot process by stripping Canonical / Microsoft signatures from your boot files and signing everything yourself.
* Summary of files that are digitally signed and verified during the boot process are:
* GRUB itself (self-signed)
* GRUB configuration (self-signed)
* GRUB modules and other external files (self-signed)
* Linux kernel (self-signed)
* Linux initramfs / initrd (self-signed)
* Linux kernel modules (using existing Canonical signatures)
* Self-signed private keys are stored in /etc/ubuntu-secure-boot/keys and protected by a passphrase.
* UEFI Secure Boot self-signed key pairs are generated and used to sign the self-contained GRUB .efi image. They can be imported into a UEFI firmware to take full control over the secure boot process.
* The secure GRUB image is added as a boot option in EFI firmware.
* Digital signature support in GRUB is enabled to check signatures on any boot file that is loaded from disk. The risk of loading an unsigned file from GRUB is eliminated (e.g. an unsigned kernel).
* GRUB is now deployed as a stand-alone .efi image that contains a memdisk with the full configuration and all loadable modules. This eliminates the risk of tampering with the GRUB configuration.
* GRUB is automatically locked down with a password so that users cannot tamper with boot settings or use advanced boot options.
* Unsigned GRUB files in /boot remaining from the original GRUB packages are completely wiped (but restored upon uninstall of this package).
* Newly-installed kernels are automatically signed whenever they are installed. Existing Canonical .efi signatures in the linux-signed-image-* packages are stripped and replaced with your signature.
* The initramfs is automatically re-signed whenever update-initramfs is run.
* Linux kernel module signing enforcement is automatically enabled by default. This can be controlled from /etc/default/grub.d/ubuntu-secure-boot.cfg.
Ubuntu Secure Boot concerns
David Hartsock has a blog post on the state of Ubuntu Secure Boot for those who have not been paying attention to things:
Ubuntu Secure Boot Threatens All PCs
We’re all doomed! Scary, right? Well, maybe, but I should explain a bit first. […]
https://davescomputertips.com/ubuntu-secure-boot-threatens-all-pcs/
WUBI UEFI fork
There’s a UEFI github project, a fork of the Ubuntu Windows installer project, WUBI, that has more UEFI support:
https://github.com/hakuna-m/wubiuefi
fork of Wubi (https://launchpad.net/wubi) for UEFI support and for support of recent Ubuntu releases
PCWorld on Ubuntu’s UEFI security
Chris Hoffman of PCWorld has an article on Ubuntu’s UEFI security:
https://firmwaresecurity.com/2016/01/07/ubuntus-uefi-secure-boot-not-a-security-measure/
Ubuntu to opt-out of fwupd?
Not only do you have to study your Linux distribution to see if/how it uses Secure Boot, you also need to research if/how it gets firmware updates.
https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-uefi-capsule-update
“Ubuntu should support updating firmware for systems and components (but not peripherals) via EFI UpdateCapsule (see EFI Capsule specification, in Related Links), so that users do not require Windows or DOS to apply BIOS/component firmware updates, and as such updates are easily available to all Ubuntu users. Peripheral firmware updates are not technically supported by the UEFI Capsule specification, and so are out of the scope of this blueprint.”
I also wonder about non-GNOME systems, how do KDE systems get firmware updates?
Ubuntu’s UEFI Secure Boot: not a security measure
[[UPDATE: As Teddy Reed points out, this information is in the Ubuntu wiki, not just in a Ubuntu bug report:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532
“IMPORTANT: Canonical’s Secure Boot implementation in Ubuntu 15.10 and early is primarily about hardware-enablement and this page focuses on how to test Secure Boot for common hardware-enablement configurations, not for enabling Secure Boot to harden your system. If you want to use Secure Boot as a security mechanism, an appropriate solution would be to use your own keys (optionally enrolling additional keys, see above) and update the bootloader to prohibit booting an unsigned kernel. Ubuntu 16.04 LTS is planned to enable enforcing secure boot (see LP: #1401532 for details). “]]
Research the implementation of UEFI Secure Boot by a Linux/FreeBSD distro before presuming to rely on it to provide any security. 😦
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1475954/comments/1
Intel Platform QoS tool for Linux
Colin King of Canonical has a new blog post on Intel’s Cache Monitoring Tool, and Intel’s Ubuntu implementation:
“The Intel Platform Shared Resource Monitoring features were introduced in the Intel Xeon E5v3 processor family. These new features provide a mechanism to measure platform shared resources, such as L3 cache occupancy via Cache Monitoring Technology (CMT) and memory bandwidth utilisation via Memory Bandwidth Monitoring (MBM). Intel have written a Platform Quality of Service Tool (pqos) to use these monitoring features and I’ve packaged this up for Ubuntu 16.04 Xenial Xerus.” […]
http://smackerelofopinion.blogspot.com/2015/11/intel-platform-shared-resource.html
Ubuntu supports UEFI firmware updates
As reported by Softpedia, the latest release of Ubuntu supports the new UEFI 2.5 firmware update mechanism:
FWTS updated
Ivan Hu of Canonical has announced the release of FWTS (FirmWare TestSuite), to 5.09.00. FWTS is a set of command line tools for Ubuntu-based and related Linux systems. It also includes a curses-based interface frontend, which is also the default UI to FWTS-live. FWTS is also included in LUV, the Linux UEFI Validation distribution, but it may be a few days until this latest release has been updated in LUV-live. The release features many bugfixes, as well as some new updates/features, including:
* Update ACPICA to version 20150717
* SMBios 3.0.0 tests supported
* acpi: add _CR3 test
* acpi: add _MTL test
* acpi: add _RST test
* acpi: add _PRR test
* dmicheck: SMBIOS 3.0.0 test
For more information, see the full announcement on the fwts-announce mailling list, and see the full changelog, /usr/share/doc/fwts/changelog.Debian.gz in the source tarball.
https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V15.09.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.09.00
FWTS 15.08.00 released
Today Canonical has released version 15.08.00 of FWTS (FirmWare Test Suite), a set of firmware-related tests for Linux-based systems. The tests can be run via command line, or via a curses front-end, the latter of which is used by the FWS-live distribution. FWTS is also included in Intel’s LUV-live (Linux UEFI Validation) distribution, but it’ll take LUV a bit of time to update to new FWTS release. FWTS is also available as packages on Ubuntu-based distributions.
It appears that most new features are ACPI-related. New ACPI TPM2 and IORT tests, new tables for: FPDT, MCHI, STAO, ASF!, WDAT, and a few other things. There were a lot of bugfixes as well. For more information, see the full announcement, the changelog, and sources:
http://fwts.ubuntu.com/release/fwts-V15.08.00.tar.gz
https://launchpad.net/ubuntu/+source/fwts
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.08.00
I wish ALL Linux/FreeBSD distributions would ship FWTS, not just Ubuntu-based ones: FTWS is very useful to detect if system has anomalies which’ll make it difficult to install/use the OS. Granted, those distro uses can just use FWTS-live, but they have to reboot into FWTS-live to use FWTS, with no native packaging.
Firmware Security 
“Ubuntu’s support for secure boot is solely intended as a compatibility measure so that media can boot on secure boot enabled computers. There are no current plans to enable secure boot as a security measure.”