Mortar is an attempt to take the headache and fragmented processes out of joining Secureboot, TPM keys, and LUKS. Through the “Mortar Model” everything on disk that is used is either encrypted, signed, or hashed. The TPM is used to effectively whitelist certain boot states. Disks are automatically unlocked once the boot sequence has been validated. This makes full-disk encryption dramatically more convenient for end-users and viable on servers (as they can automatically unlock on reboot). Mortar aims to support both TPM 1.2 (via its own implementation) and TPM 2 (via clevis). LUKS1 and LUKS2 are both supported by intelligently selecting different implementation paths based on your current setup. Mortar aims to be distribution agnostic. Initial developments are on Arch Linux and Debian Linux.
Google has a new (or updated?) white paper on Enterprise Android, with mention of Verified Boot, and other Android security features:
Written by Bruno – 2020-01-14
Last summer, I finally started reversing the firmware of a computer I had since quite some times: a Lenovo ThinkPad P51s.[…]The problem of calling this function from SMM is that the EFI_BOOT_SERVICES is a table of services located in the normal world. An attacker can simply change the address in the EFI_BOOT_SERVICES table and get an arbitrary call. This type of vulnerability is usually named a callout of SMRAM and they are basically equivalent to calling userland code from kernelland.[…]
Intel has released 6 new security advisories:
SNMP Subagent Stand-Alone Advisory for Windows INTEL-SA-00300
Chipset Device Software Advisory INTEL-SA-00306
RWC 3 for Windows Advisory INTEL-SA-00308
Processor Graphics Advisory INTEL-SA-00314
VTune Amplifier for Windows Advisory INTEL-SA-00325
DAAL Advisory INTEL-SA-00332
And a blog post about it:
Grubkit is a demonstration of a very simple trick to deploy your own bootkit on a system that boots with GRUB. The trick is simply to use your own code as the init parameter to the kernel, fork, start systemd as normal and you’re done! PSTree did not detect my bootkit when I did this. Seems like a good and simple method.[…]
haybale is a general-purpose symbolic execution engine written in Rust. It operates on LLVM IR, which allows it to analyze programs written in C/C++, Rust, Swift, or any other language which compiles to LLVM IR. In this way, it may be compared to KLEE, as it has similar goals, except that haybale is written in Rust and makes some different design decisions. That said, haybale makes no claim of being at feature parity with KLEE.
The github project site has a link to a 3.3 gigabyte dataset hosted on Google Drive, as well…
The UEFI Forum usually runs 2 plugfest events per year, one in Seattle and one in Asia. This year, it appears that it won’t be in Seattle but rather in Portland.
Where: Embassy Suites by Hilton Portland in Hillsboro, Oregon
When: March 30 – April 3, 2020
Krabs is working on booting vmlinux and ELF kernels on legacy 32-bit PCs and is under the development. Krabs also aims to support only the minimal Linux boot protocol. This allows you to specify the kernel command line and manipulate the behavior of the kernel at boot time. Another feature is that in order to save space, the ELF format kernel is compressed using bzip2 before use and uses libbzip2 library for decompressing.
[…]Krabs is an experimental x86 bootloader written in Rust. Krabs can boot the ELF formatted kernel which compressed with bzip2. Krabs decompresses the bz2 image and relocate the ELF image, then boot the kernel. Some of the source code uses libbzip2 C library for decompressing, but the rest is completely Rust only.
In this post we’ll explore running unsigned Option ROM code on an Intel D34010WYK NUC, solely for testing purposes. We will verify that unsigned/unverified Option ROM code is not run when UEFI Secure Boot is enabled. We will demonstrate how to persist code at runtime using UEFI Runtime Services, and use a small signalling protocol to allow an unprivileged userland process to fake the contents of UEFI variables such as the SecureBoot variable.[…]
[…]I wanted to reverse engineer the UEFI code running on my own laptop (a Lenovo Y520-15IKBN). To do this, I will first need to obtain the firmware. This should be extractable from a firmware update, so I downloaded the firmware updater from the Lenovo support site.[…]I extracted the contents of the flash ROM with UEFIExtract in the new_engine branch of UEFITool. This resulted in a folder containing over 300 PE images. One of them sounded interesting: SecureBackDoorPeim, but I think this blog post is long enough, so it may be the topic of another post.[…]
CPUs these days have a feature that prevents inadvertent memory accesses from the kernel to userland memory. Intel calls this feature “SMAP” (Supervisor Mode Access Prevention) while ARM calls it “PAN” (Privileged Access Never). Apple’s A10 chips and later have this feature,[…]
This is a rudimentary attempt to build an autogenerated formal-ish model of x86 intrinsics by interpreting Intel’s instruction pseudocode, transforming it into a model for Z3.
If you use the LLVM LLDB debugger, you should also be using lldbinit, and there’s an updated release out!
Binary-only, no source code, so be careful if you use experiment with this tool:
[…]Further, we demonstrate JackHammer, a novel and efficient Rowhammer from the FPGA to the host’s main memory. Our results indicate that a malicious FPGA can perform twice as fast as a typical Rowhammer attack from the CPU on the same system and causes around four times as many bit flips as the CPU attack. We demonstrate the efficacy of JackHammer from the FPGA through a realistic fault attack on the WolfSSL RSA signing implementation that reliably causes a fault after an average of fifty-eight RSA signatures, 25% faster than a CPU rowhammer attack. In some scenarios our JackHammer attack produces faulty signatures more than three times more often and almost three times faster than a conventional CPU rowhammer attack.
[…]I created QASan (QEMU-AddressSanitizer), a fork of user-mode QEMU that introduce AddressSanitizer for heap objects into QEMU. QASan not only enables AddressSanitizer on COTS x86/x86_64/ARM/ARM64 binaries on Linux/*BSD but allows also the instrumentation of code generated at runtime (e.g. JIT) that is, of course, not supported by source-level ASAN. Note also that at the time of writing AddressSanitizer doesn’t support ARM/ARM64 on Linux and QASan enables that for this class of binaries.[…]
This is a project to collect hardware details of Linux-powered computers over the world and help Linux users and developers to collaboratively debug hardware related issues, check for Linux-compatibility and find drivers.
The web site has a tool, HW-Probe, and a Github repo of uploaded ACPI tables:
This is a repository of decoded ACPI tables for various computers collected by Linux users […] Everyone can contribute to this repository by uploading probes of their computers by the hw-probe tool: