As the tweet mentions, there is a disparity for OS-level access to UEFI runtime services.
Welcome to salt, a tool to reverse and learn kernel heap memory management. It can be useful to develop an exploit, to debug your own kernel code, and, more importantly, to play with the kernel heap allocations and learn its inner workings.
This tool helps tracing allocations and the current state of the SLUB allocator in modern linux kernels.
It is written as a gdb plugin, and it allows you to trace and record memory allocations and to filter them by process name or by cache. The tool can also dump the list of active caches and print relevant information.
This repository also includes a playground loadable kernel module that can trigger allocations and deallocations at will, to serve both as a debugging tool and as a learning tool to better understand how the allocator works.
Today we’d like to announce the Qubes U2F Proxy. It is a secure proxy intended to make use of U2F two-factor authentication devices with web browsers without exposing the browser to the full USB stack, not unlike the USB keyboard and mouse proxies we’ve already implemented in Qubes.[…]
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.[…]
A shell script to tell if your system is vulnerable against the several “speculative execution” CVEs that were made public in 2018.
CVE-2017-5753 [bounds check bypass] aka ‘Spectre Variant 1’
CVE-2017-5715 [branch target injection] aka ‘Spectre Variant 2’
CVE-2017-5754 [rogue data cache load] aka ‘Meltdown’ aka ‘Variant 3’
CVE-2018-3640 [rogue system register read] aka ‘Variant 3a’
CVE-2018-3639 [speculative store bypass] aka ‘Variant 4’
CVE-2018-3615, CVE-2018-3620, CVE-2018-3646 [L1 terminal fault] aka ‘Foreshadow & Foreshadow-
[…]The NVMe ecosystem is pretty new, and things like “what version number firmware am I running now” and “is this firmware OEM firmware or retail firmware” are still queried using vendor-specific extensions. I only have two devices to test with (Lenovo P50 and Dell XPS 13) and so I’m asking for some help with data collection. Primarily I’m trying to find out what NMVe hardware people are actually using, so I can approach the most popular vendors first (via the existing OEMs). I’m also going to be looking at the firmware revision string that each vendor sets to find quirks we need — for instance, Toshiba encodes MODEL VENDOR, and everyone else specifies VENDOR MODEL.[…]
System Firmware and Device Firmware Updates using Unified Extensible Firmware Interface (UEFI) Capsules
Firmware is responsible for low-level platform initialization, establishing root-of-trust, and loading the operating system (OS). Signed UEFI Capsules define an OS-agnostic process for verified firmware updates, utilizing the root-of-trust established by firmware. The open source FmpDevicePkg in TianoCore provides a simple method to update system firmware images and device firmware images using UEFI Capsules and the Firmware Management Protocol (FMP). This session describes the EFI Development Kit II (EDK II) capsule implementation, implementing FMP using FmpDevicePkg, creating Signed UEFI Capsules using open source tools, and an update workflow based on the Linux Vendor Firmware Service (fwupd.org).
DebConf, the Debian conference is happening, and there’s a EFI Secure Boot talk. Slides are listed on the debian-efi list below:
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.
A simplified EFI stub that allows you to bundle a Linux kernel image, initial RAM disk, and command line into a single EFI binary, so that you can sign the image and use it in a user key Secure Boot setup. This is just a simplified version of systemd’s stub.
Rationale: systemd’s usual EFI stub includes the command line, kernel image and RAM disk as separate sections in the PE. I was having random boot failures with that, and so I wondered if the extra sections were causing issues with my laptop’s pretty poor UEFI implementation.
YubiKey Full Disk Encryption
Tutorial to create full disk encryption with YubiKey, encrypted boot partition and secure boot with UEFI, using Arch Linux.
This repository contains a step-by-step tutorial to create a full disk encryption setup with two factor authentication (2FA) via YubiKey. It contains:
+ YubiKey encrypted root (/) and home (/home) folder on separated partitions
+ Encrypted /boot partition
+ UEFI Secure boot (self signed boot loader)
PS: US Mil also has another security distro, LiPoSe (Lightweight Portable Security). For years they did not release source code, but later did. Now it is called TENS. Last time I looked, it had no firmware-level security.
SystemBoot is a distribution for LinuxBoot to create a system firmware + bootloader. It is based on u-root. The provided programs are:
* netboot: a network boot client that uses DHCP and HTTP to get a boot program based on Linux, and uses kexec to run it
* localboot: a tool that finds bootable kernel configurations on the local disks and boots them
* uinit: a wrapper around netboot and localboot that just mimicks a BIOS/UEFI BDS behaviour, by looping between network booting and local booting. The name uinit is necessary to be picked up as boot program by u-root.
This work is similar to the pxeboot and boot commands that are already part of u-root, but approach and implementation are slightly different. Thanks to Chris Koch and Jean-Marie Verdun for pioneering in this area. This project started as a personal experiment under github.com/insomniacslk/systemboot but it is now an effort of a broader community and graduated to a real project for system firmwares.[…]
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.