- Responsible for discovering and exploiting vulnerabilities affecting Dell software and firmware
Author: hucktech
Drop-EFI: Mac “droplet” GUI dock for EFI’s ESP
Drop EFI is a super Droplet for Mount any EFI Partition on macOS
Working for HFS+J, APFS, NTFS GPT, Core Storage volumes.
https://github.com/chris1111/Drop-EFI
efiboot-rs: efivar and efiboot UEFI tools in Rust
This repository contains the source code for:
* efivar – A Rust crate to read and write EFI variables
* efiboot – A command-line tool to manage the UEFI boot manager
SiFive: DDR controller configuration register values unleashed!
Re: https://firmwaresecurity.com/2018/06/25/risc-v-implementations-filled-with-blobs/
https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/8
Comment from SiFive:
SiFive is committed to supporting the open-source community. We are pleased to report that after discussions with our IP partners, we are now able to make available all the source code required to initialize the HiFive Unleashed board. The board’s boot sequence is described in the manual. The assembly code in the initial reset ROM is listed in the manual Chapter 6.1 “Reset Vector”. The firmware in the ZSBL mask ROM is directly readable by software on the chip, and we will be making the full source code available shortly. The source code for FSBL including the DDR initialization will also be available shortly. We can attest there is no other firmware run by the system during boot.
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.[…]
Tetris game for UEFI in x64 assembler
Re: https://firmwaresecurity.com/2018/02/19/uefimarkebcedition-uefi-byte-code-ebc-benchmark-utility/
GRAPHICAL TETRIS. UEFI X64 EDITION. MAIN MODULE.
SEPARATE EDITION = TETRIS WITHOUT UEFIMARK.
(C)2013-2017 IC Book Labs.
https://github.com/manusov/UEFImarkAndTetris64/blob/master/source/TETRIS.ASM
Not to be confused with the other UEFI Tetris:
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
Apple: periodic reminder: set your firmware password
Google Android: Pixel firmware security updates
[…]To prevent attackers from replacing our firmware with a malicious version, we apply digital signatures. There are two ways for an attacker to defeat the signature checks and install a malicious replacement for firmware: find and exploit vulnerabilities in the signature-checking process or gain access to the signing key and get their malicious version signed so the device will accept it as a legitimate update. The signature-checking software is tiny, isolated, and vetted with extreme thoroughness. Defeating it is hard. The signing keys, however, must exist somewhere, and there must be people who have access to them.[…]
https://security.googleblog.com/2018/06/insider-attack-resistance.html
REcon Montreal 2018: slides uploaded
Winbagility project: simulates a debugged kernel
https://github.com/Winbagility/Winbagility
https://github.com/Winbagility/Winbagility/tree/master/bindings/python
Winbagility is a tool that gives you ability to connect WinDbg on non /DEBUG Windows x64 systems. Winbagility simulates a debugged kernel. It retrieves over the STUB for some essentials information (KDBG, KPCR…) and forward these informations to WinDbg over KD.
PyFDP is a Python extension used to communicate with the FDP (Fast Debugging Protocol) hypervisor-based debugging server used in the Winbagility project. Winbagility introduced an instrumented version of VirtualBox which can be used to implement a sthealth debugger via Virtual Machine introspection and runtime analysis. While Winbagility simply connect the FDP server to Windbg in order to debug a Windows VM as if the guest was launch with /DEBUG option activated, anyone can write a FDP client. PyFDP expose the FDP client side by wrapping the DLL’s exports via ctypes, enabling any Python program to script a VM debugging session.
Threat Detection using Windows Defender Application Control (Device Guard) in Audit Mode
https://twitter.com/mattifestation/status/1011569106347286528
https://twitter.com/subTee/status/1011318358917165057
Matt Graeber
Security Researcher, SpecterOps
Jun 26
Note: I originally scrapped this post because I didn’t like that audit events were only logged once per boot due to caching, however, Casey’s tweet reminded me that I shouldn’t let perfect be the enemy of good. This is still one of the best options that I know of (without requiring a commercial solution) to log all driver loads.[…]
RAMpage: 4 Rowhammer variants for Android (with logos and own web site)
CVE-2018-1000205: U-Boot, Verified Boot input validation
Re: https://firmwaresecurity.com/2018/06/26/cve-2018-1000205-u-boot/
and https://firmwaresecurity.com/2018/06/07/teddy-reed-on-u-boots-verified-boot/
There is now a description for the CVE. Ah, this makes sense, the Verified Boot issues that Teddy Reed brought up earlier:
U-Boot contains a CWE-20: Improper Input Validation vulnerability in Verified boot signature validation that can result in Bypass verified boot. This attack appear to be exploitable via Specially crafted FIT image and special device memory functionality.
https://nvd.nist.gov/vuln/detail/CVE-2018-1000205
https://lists.denx.de/pipermail/u-boot/2018-June/330454.html
https://lists.denx.de/pipermail/u-boot/2018-June/330898.html
coreboot for HiFive Unleashed
What does NVRAM lock/unlock actually mean?
What does NVRAM lock/unlock actually mean
Jun 26, 2018
So, recently I’ve realized that meaning of “lock/unlock” in context of nvram on iOS is not understood correctly by many, so I’ve decieded to make a quick blog post on meaning of those words.[…]
https://stek29.rocks/2018/06/26/nvram.html
Google Shell style guide
Maybe this is old news to you, but I just learned that Google has a style guide for shell scripts. Not just bash-centric, either.
No, they don’t have one for the UEFI Shell. 🙂
UEFI Forum: Firmware Security 101 Webinar
The UEFI Forum is doing a webinar on Firmware Security! I don’t know if GoToMeeting supports this with webinars, but it’d be nice if you could make the audio archive available for those who can’t dial in, or need time to listen to audio to translate to their native language.
Tuesday, July 24 at 9:00 am PT
FIRMWARE SECURITY 101 WEBINAR
The Firmware Security 101 Webinar will feature a panel of firmware security experts representing the Forum, including:
Moderator:
Michael Krau, Industry Communications Working Group Chair
Panelists:
Eric Johnson, American Megatrends, Inc.
Tim Lewis, Insyde Software
Vincent Zimmer, Intel
The panelists will outline the major challenges currently facing platform security, how the UEFI Forum and UEFI specification address these challenges and finally, how you can join us in the battle to protect firmware from outside threats. The webinar is open to the public and attendees will get the chance to participate in a live Q&A session.
Registration for this free, one-hour webcast will open in the next couple of weeks.
Conan for UEFI??
An open source, secure, vendor-neutral, pre-OS packaging tool for updating platform microcode and firmware might be interesting. So when I saw this UEFI test app:
https://github.com/matlo607/uefi-test
it was interesting to note that it includes some support for the Conan C/C++ packaging tool for UEFI, eg:
https://github.com/matlo607/uefi-test/blob/master/conan-recipes/edk2/conanfile.py
I’ve no time today to study it closely, so I’m unsure if it is using conan as an OS-present tool, or it has conan running as a pre-OS UEFI app. Big difference! 🙂
Conan is a C/C++ packaging tool. The official docs don’t mention UEFI support:
Conan can be installed in many Operating Systems. It has been extensively used and tested in Windows, Linux (different distros), OSX, and is also actively used in FreeBSD and Solaris SunOS. There are also several additional operating systems on which it has been reported to work. […] Conan works and is being actively used on Windows, Linux (Ubuntu, Debian, RedHat, ArchLinux, Raspbian), OSX, FreeBSD, and SunOS, and, as it is portable, it might work in any other platform that can run python. In the documentation, examples for a specific OS might be found, such as conan install . -s compiler=”Visual Studio”, which will be specific for Windows users. If on a different system, the reader should adapt to their own platform and settings (for example conan install . -s compiler=gcc). […] Also conan works with any build system. In the documentation, CMake will be widely used, because it is portable and well known. But conan does not depend on CMake at all; it is not a requirement. Conan is totally orthogonal to the build system. There are some utilities that improve the usage of popular build systems such as CMake or Autotools, but they are just helpers. Furthermore, it is not necessary that all the packages are built with the same build system. It is possible to depend on packages created with other build system than the one you are using to build your project.
https://github.com/conan-io/conan
https://conan.io/
PS: Above project uses CMake, and Conan supports CMake. And there’s also this CMake/UEFI project, but appears to not be native UEFI use of CMake:
https://github.com/eruffaldi/uefiboot
http://teslacore.blogspot.com/2016/02/starting-with-uefi-with-cmake-and.html
HPE: iLO: Remote Unauthorized Modification of Information
Re: https://firmwaresecurity.com/2018/06/11/subverting-your-server-through-its-bmc-the-hpe-ilo4-case-presentation-toolbox/ and https://firmwaresecurity.com/2018/06/20/airbus-seclab-ilo4_toolbox-more-info-uploaded/
NOTICE: The information in this Security Bulletin should be acted upon as soon as possible.
Release Date: 2018-06-26
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbhf03844en_us
Firmware Security 
You must be logged in to post a comment.