Spectre & Meltdown vulnerability/mitigation checker for Linux

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-

https://www.cnx-software.com/2018/08/17/check-spectre-meltdown-l1-terminal-fault-linux/amp/

https://github.com/speed47/spectre-meltdown-checker/

NVMe Firmware: I Need Your Data

 

[…]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.[…]

https://blogs.gnome.org/hughsie/2018/08/17/nvme-firmware-i-need-your-data/

https://plus.google.com/+RichardHughes/posts/Wqqtots46aA

Linux UEFI firmware updates via LVFS at Linaro Connect

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).

https://yvr18.pathable.com/meetings/740447

http://connect.linaro.org/schedule/

https://fwupd.org/

Debian UEFI Secure Boot report from DebConf

DebConf, the Debian conference is happening, and there’s a EFI Secure Boot talk. Slides are listed on the debian-efi list below:

https://lists.debian.org/debian-efi/2018/07/msg00015.html

https://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/?

 

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.

ministub: Simplified EFI stub for Linux, based on systemd’s EFI stub

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.

https://github.com/angelsl/ministub

 

 

Yubikey Linux FDE UEFI Secure Boot tutorial

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)

https://github.com/sandrokeil/yubikey-full-disk-encryption-secure-boot-uefi

https://sandrokeil.github.io/yubikey-full-disk-encryption-secure-boot-uefi/

 

NSA using Qubes-like SecureView?

https://distrowatch.com/table.php?distribution=tens

https://www.ncst.com/solutions/secureview

https://www.ainfosec.com/innovative-products/secureview/

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.

https://spi.dod.mil/LPS-Public_for_DoD.htm

https://www.spi.dod.mil/lipose.htm

https://en.wikipedia.org/wiki/Lightweight_Portable_Security

Strengthening and Protecting Linux Servers: Top Ways to Harden Your Boxes

https://github.com/roxyd/roxyd.github.io/blob/master/talks/linux_strengthening.pdf

SystemBoot: a LinuxBoot distro that works as a system firmware + bootloader, based on u-root

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.[…]

 

https://github.com/systemboot/systemboot

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

 

bootloader_instrumentation_suite: [U-Boot] Bootloader research tools (very much a work in progress)

https://github.com/bx/bootloader_instrumentation_suite

This test suite helps you keep track of different versions of
u-boot/build tools, static analysis of that build’s binaries, and
runtime trace results of running that binary on a given hardware
configuration. For each u-boot/build configuration it keeps a database
of information it statically gathered for each boot stage, boot stage
images/ELF files, a prepared SD card image, and test results of
runtime trace analyses. If it detects changes in the u-boot source or
build tools it will create a new set of test result directories with a
new sdcard image and static analysis results.

Facebook BOLT: Binary Optimization and Layout Tool, used for optimizing performance of binaries

https://code.facebook.com/posts/605721433136474/accelerate-large-scale-applications-with-bolt/

https://github.com/facebookincubator/BOLT

Cyberus Tech: Intel LazyFP vulnerability: Exploiting lazy FPU state switching

[…]Earlier this year, Julian Stecklina (Amazon) and Thomas Prescher (Cyberus Technology) jointly discovered and responsibly disclosed another vulnerability that might be part of these, and we call it LazyFP. LazyFP (CVE-2018-3665) is an attack targeting operating systems that use lazy FPU switching. This article describes what this attack means, outlines how it can be mitigated and how it actually works.

For further details, see the current draft of the lazyFP paper: <Link withheld by request from Intel>

Please check back regularly, we’re going to update this post in coordination with Intel.[…]

http://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html

Kees Cook on Linux kernel 4.17 security features

If you’re not aware, Kees does a good job about blogging on new Linux kernel features. The topic list from current blog post:

Jailhouse hypervisor
Sparc ADI
new kernel stacks cleared on fork
MAP_FIXED_NOREPLACE
pin stack limit during exec
Variable Length Array removals start

https://outflux.net/blog/archives/2018/06/14/security-things-in-linux-v4-17/

 

On Intel not talking to OpenBSD about recent FPU vuln

Chip vendors controlling the security of OSes should be more transparent in their selection process. They should maintain a list of OSVs that they maintain embargoed fixes. Then uses could determine if they want to trust the OS or not, or try to lobby to try and get the ISA vendor to support their OS. Is the OS on the list, ok then they may have some chance at fixing things. If not on the list I expect to be vulnerable until the embargo ends. There are MANY more OSes than Microsoft Windows, Apple macOS, a limited number of Linux distros, and sometimes FreeBSD.

In some forums, Bryan Cantrill is crafting a fiction. He is saying the FPU problem (and other problems) were received as a leak. He is not being truthful, inventing a storyline, and has not asked me for the facts. This was discovered by guessing Intel made a mistake. We are doing the best for OpenBSD. Our commit is best effort for our user community when Intel didn’t reply to mails asking for us to be included. But we were not included, there was no reply. End of story. That leaves us to figure things out ourselves. Bryan is just upset we guessed right. It is called science.

https://marc.info/?l=openbsd-tech&m=152894815409098&w=2

 

How to acquire Linux memory images using without a driver

How to acquire Linux memory images using without a driver
Posted on Sunday, June 10th, 2018 at 5:52 am.
Written by blschatz

For a long time now, operating systems such as Windows and MacOS have prevented user space applications from accessing the raw physical memory of the machine. Physical acquisition and virtualisation approaches aside, this has led the field to require the use of kernel drivers to export physical ram for acquisition. In the linux realm, Joe Sylve’s LiME is the go-to for many. It appears not widely known that on Linux x64, acquisition of physical memory is possible without using a driver such as LiME. The prerequisite here is that /proc/kcore is enabled, which fortunately is widely the case: Ubuntu ships with it enabled by default, as does Redhat. On x64 the full physical address space is mapped into the kernel address space, and /proc/kcore exports this as a part of its virtual ELF file view.[…]

http://www.schatzforensic.com.au/insideout/2018/06/how-to-acquire-linux-memory-images-using-without-a-driver/

https://github.com/google/rekall/tree/master/tools/pmem

https://evimetry.com/getting-started/linear-ram-live/

iPXE-Boot-Server: Setup iPXE to support both BIOS and UEFI

Step by step guide for how to build your own PXE boot server supporting both legacy BIOS and EFI hardare

Build your own PXE boot server

This article is a step by step guide for building your own PXE boot infrastructure which can be used to boot both legacy BIOS and EFI based hardware from network. There are many articles on the Internet for building PXE boot infrastructure however I found most of them does not work for EFI based hardware. I use iPXE as the boot image and dnsmasq as DHCP & TFTP server and I found it’s dead simple to setup those two software.

https://github.com/boliu83/ipxe-boot-server

client_boot1.gif

 

 

VMWare: Enable or Disable UEFI Secure Boot for a Virtual Machine

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.[…]

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html