libelfmaster: Secure ELF parsing/loading library for forensics reconstruction of malware, and robust reverse engineering tools

https://github.com/elfmaster/libelfmaster

See-also:
http://www.bitlackeys.org/
https://www.eventbrite.com/o/bitlackeys-17575943369
https://www.eventbrite.com/e/elf-voodoo-binary-analysis-workshop-brought-to-you-by-the-elfmaster-leviathan-tickets-48427221122

SALT – SLUB ALlocator Tracer for the Linux kernel (including GDB plugin)

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.

https://github.com/PaoloMonti42/salt

https://github.com/PaoloMonti42/salt/blob/master/presentation.pdf

screenshot

 

Qubes announces U2F Proxy

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

https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/

https://github.com/QubesOS/qubes-app-u2f

Lenovo ThinkPad X1 6en: Enabling S3 Sleep for Linux after Firmware Update

https://brauner.github.io/2018/09/08/thinkpad-6en-s3.html

sb-kmod-signload.sh: UEFI Secure Boot sign and load utility for Linux kernel modules

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

https://github.com/plyint/sb-kmod-signload.sh

 

 

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/

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.