By: Bo Feng, Alejandro Mera, and Long Lu, Northeastern University

Dynamic testing or fuzzing of embedded firmware is severely limited by hardware-dependence and poor scalability, partly contributing to the widespread vulnerable IoT devices. We propose a software framework that continuously executes a given firmware binary while channeling inputs from an off-the-shelf fuzzer, enabling hardware-independent and scalable firmware testing. Our framework, using a novel technique called P2IM, abstracts diverse peripherals and handles firmware I/O on the fly based on automatically generated models. P2IM is oblivious to peripheral designs and generic to firmware implementations, and therefore, applicable to a wide range of embedded devices. We evaluated our framework using 70 sample firmware and 10 firmware from real devices, including a drone, a robot, and a PLC. It successfully executed 79% of the sample firmware without any manual assistance. We also performed a limited fuzzing test on the real firmware, which unveiled 7 unique unknown bugs.

https://www.usenix.org/conference/usenixsecurity20/presentation/feng

https://github.com/RiS3-Lab/p2im

 

The first in a series of posts for researchers on how to emulate, debug and fuzz UEFI modules, we begin with a refresher on how to dump SPI flash memory.[…]

Moving From Common-Sense Knowledge About UEFI To Actually Dumping UEFI Firmware

By Michael Milvich

Anvil is releasing a white paper today describing a technique that we have found useful to bypass secure boot on a number of embedded Linux devices where the file systems have been split into a signed/protected partition for executables, and a non protection partition to store persistent data.[…]

https://www.anvilventures.com/blog/defeating-secure-boot-with-symlink-attacks.html
https://github.com/anvilventures/symlink-secure-boot-vm

acpiparse is a small utility which understands the format of common ACPI tables and can print them in a human-readable way.[…]

https://github.com/jhand2/acpiparse

This script makes Downgrade-able BIOS update file from Dell original BIOS updates.[…]

https://github.com/vuquangtrong/Dell-PFS-BIOS-Assembler

Intel® Thunderbolt™ Controller Advisory
INTEL-SA-00411
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00411.html

Intel® SSD DCT Advisory
INTEL-SA-00406
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00406.html

Intel® Distribution of OpenVINO™ Toolkit Advisory
INTEL-SA-00399
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00399.html

Intel® RealSense™ D400 Series UWP Advisory
INTEL-SA-00396
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00396.html

Intel® Mailbox Interface Driver Advisory
INTEL-SA-00394
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00394.html

Intel® NUC Firmware Advisory
INTEL-SA-00392
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00392.html

Intel® Computing Improvement Program Advisory
INTEL-SA-00387
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00387.html

Intel® Server Board M10JNP2SB Advisory
INTEL-SA-00386
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00386.html

Intel® Server Boards, Server Systems and Compute Modules Advisory
INTEL-SA-00384
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00384.html

Intel® Wireless for Open Source Advisory
INTEL-SA-00379
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00379.html

Intel® RAID Web Console 3 for Windows* Advisory
INTEL-SA-00378
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00378.html

Intel® RSTe Software RAID Driver Advisory
INTEL-SA-00377
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00377.html

Intel® LED Manager for NUC Advisory
INTEL-SA-00376
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00376.html

Intel® PAC with Arria® 10 GX FPGA Advisory
INTEL-SA-00375
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00375.html

Intel® Graphics Drivers Advisory
INTEL-SA-00369
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00369.html

Intel® Server Board Families Advisory
INTEL-SA-00367
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00367.html

IIntel® PROSet/Wireless WiFi Software Advisory
INTEL-SA-00355
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00355.html

Intel® Wireless Bluetooth® Advisory
INTEL-SA-00337
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00337.html

 

ZMK is a new keyboard firmware software project. It is based on Zeyphyr RTOS. I guess the main keyboard firmware alternatives are QMK and TMK. [1].

https://zmkfirmware.dev/

As for security issues, new mechanical keyboards — with either QMK or TMK and I presume also with ZMK — are programmable, with layers and macros, with many opportunites to be a “BadUSB” device. Including WiFi support, not just USB. Let’s hope that peripheral firmware and operating systems learn to treat these powerful peripheral devices with appropriate caution.

[1] https://github.com/qmk/qmk_firmware
https://github.com/tmk/tmk_keyboard
https://www.reddit.com/r/MechanicalKeyboards/wiki/firmware
https://github.com/BenRoe/awesome-mechanical-keyboard/blob/master/docs/firmware.md

PS: I’m hoping to see one of (ZMK, TMK, or QMK) support RISC-V. At this point in it’s evolution, RISC-V would be useful in more maker projects (like mechanical keyboards and #badgelife projects), in addition to FPGA-centric focus, while it evolves to eventually power a real PC. I hope the RISC-V ecosystem puts more effort into competing with Arduino and other ARM dev boards. While I believe ZephyrOS supports RISC-V, the ZMK project doesn’t.

https://zmkfirmware.dev/docs/hardware/

Apparently the dump includes info on: Intel ME, Intel FSP, and “Lots of other things”…

https://del.dog/onufumerap.txt

https://www.theregister.com/2020/08/06/intel_nda_source_code_leak/

Microsoft has a new Knowledgebase Article on UEFI SecureBoot DBX certs:

On July 29, 2020, Microsoft published security advisory 200011 that describes a new vulnerability that’s related to Secure Boot. Devices that trust the Microsoft third-party Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA) in their Secure Boot configuration may be susceptible to an attacker who has administrative privileges or physical access to the device. This article provides guidance to apply the latest Secure Boot DBX revocation list to invalidate the vulnerable modules. Microsoft plans to push an update to Windows Update to address this vulnerability after further testing in 2021.[…]

https://support.microsoft.com/en-ph/help/4575994/microsoft-guidance-for-applying-secure-boot-dbx-update

https://uefi.org/revocationlistfile

There really should be more technical information provided about the revoked/otherwise bad certs in the DBX files.

Re: https://firmwaresecurity.com/2019/11/23/edk2-vscode-visual-studio-code-plugin-for-edkii-files/ and https://firmwaresecurity.com/2019/10/01/musupport-a-vs-code-extension-to-support-project-mu/:

there is a third UEFI plugin for Visual Studio Code, from Abhishek Sharma of Microsoft:

This is a VS code extension which helps points to definition of keywords in the UEFI code like PCDs, GUIDs, etc.

https://github.com/unkemptArc99/uefi-code-defn

This is UEFI port of the Duktape embeddable Javascript engine, duktape-2.5.0, released on 24 Nov 2019. It requires edk2-libc to build an UEFI shell application. build succeeded but not confirmed it works.[…]

https://github.com/TuvianNavy/Duktape-UEFI

https://duktape.org/

In case you’ve not been reading the news, a vulnerability has been found in GRUB:

https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html
https://www.kb.cert.org/vuls/id/174059
https://www.kb.cert.org/vuls/id/174059
https://ubuntu.com/security/notices/USN-4432-1
https://cyber.gc.ca/en/alerts/grub-security-advisory
https://access.redhat.com/security/vulnerabilities/grub2bootloader
https://access.redhat.com/errata/RHSA-2020:3217

New Python Redfish samples beyond the ones in Fujitsu’s project. Half a dozen scripts, including one that does a BIOS update.

Sample Python scripts to manage Fujitsu integrated Remote Management Controller (iRMC) via Redfish in Fujitsu Server PRIMERGY.

https://github.com/mmurayama/fujitsu-redfish-samples

See-also:

https://github.com/fujitsu/fujitsu-ansible-irmc-integration
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=CED64CAE-A20C-494E-91FE-66ADAD0DBFD2
https://support.ts.fujitsu.com/IndexDownload.asp?SoftwareGuid=85DBC785-B759-4CDE-A1D3-C335B5EC7C1D

There are a few blog posts on Fujitsu Redfish here:
http://mmurayama.blogspot.com/search?q=redfish

By: Solon Falas, Charalambos Konstantinou, Maria K. Michael

[…]In this paper, we present a framework for secure firmware updates on embedded systems. The approach is based on hardware primitives and cryptographic modules, and it can be deployed in environments where communication channels might be insecure. The implementation of the framework is flexible as it can be adapted in regards to the IoT device’s available hardware resources and constraints. Our security analysis shows that our framework is resilient to a variety of attack vectors. The experimental setup demonstrates the feasibility of the approach. By implementing a variety of test cases on FPGA, we demonstrate the adaptability and performance of the framework. Experiments indicate that the update procedure for a 1183kB firmware image could be achieved, in a secure manner, under 1.73 seconds.

https://arxiv.org/abs/2007.09071

“Hello everyone. My name is Harshit Sharma (hst on IRC). I am working on the project to add the “Address Sanitizer” feature to coreboot as a part of GSoC 2020.[…]”

[GSoC] Address Sanitizer, Part 1

https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/PVAFQQZKOJXK26M44I7PEGNBJMWOUJ5J/

So, there are a handful of tools for checking for hardware/firmware security issues. Each tool has a separate list of security checks, half of which are publicly-viewable. With gaps from some hardware and OS vendors. I’m wondering how much overlap there is between these security lists, that might be useful to port and find additional security issues.

* Intel has CHIPSEC, for testing the hardware and firmware for security issues. It works on Intel x86 and Intel x64, not AMD AMD64. It works on Mac, Windows, and Linux, and UEFI. Public can run this on their own device.

https://github.com/chipsec/chipsec/wiki/Vulnerabilities-and-CHIPSEC-Modules

* ARM has SBSA-ACS, for testing hardware and firmware security issues.It works on ARM AArch64 ‘enterprise’ devices. Unclear if there is a technical distinction for non-enterprise AArch64 device use. Not AArch32. It works on UEFI. Intended for vendor use on development machines, not consumer devices (“To prevent the leakage of secure information, it is strongly recommended that the ACS test suite is run only on development platforms. If it is run on production systems, the system should be scrubbed after running the test suite.”).

https://github.com/ARM-software/sbsa-acs/blob/master/docs/testcase-checklist.md

* Apple has eficheck for macOS. It works on Intel x64, and I am guessing that it’ll also work on future ARM processors. The list of security tests it makes is unknnown, the documentation is lacking.

* Microsoft has Defender AV (which has UEFI support) for Windows.  I presume (but do not know) it works on all ISAs that Windows does, so maybe coverage on Intel, AMD, and ARM. The list of security tests it makes is unknnown, the documentation is lacking.

* AMD has nothing. Except for Microsoft Defender (for Windows users only).

* Linux has nothing. Except for Intel CHIPSEC on Intel systems.

I wonder about the delta between these 4 security lists. I wish there was more information from Microsoft and Apple on the specific tests their tools make. Are there any from one list that should also be tested on the other lists, and vice versa? Obviously, some entries are platform-centric, but there are others that might not be.

Any professors out there: please suggest a grad student do some research on the Intel and ARM security lists. Thanks.

Re: https://firmwaresecurity.com/2016/05/08/uefi-ported-to-risc-v/

Atish of Western Digital is using FWTS to test the RISC-V port of UEFI on Linux.

http://lists.infradead.org/pipermail/linux-riscv/2020-July/001248.html

https://wiki.ubuntu.com/FirmwareTestSuite

Colin of Canonical has updated FWTS to have a RISC-V port.

There is a relatively-new operating system called “Barbara IoT”, based out of Madrid Spain, which is new to my daily “Verified Boot” searches.

Their security page mentions “verified boot”. Given the vagueness of their web site, I can’t say if this is Linux/Android/Chrome Verified Boot or something else. Unclear what flavor(s) of platform firmware the OS interacts with.

“Raise the security level of your devices with verified boot, data encryption and no exposed network services”

Have not found the source to the OS yet, I’m guessing closed-source. Their web site is pretty closed: it requires you to submit name/email contact info to view any data on their OS. Their home page link to their Developers page is broken.

https://barbaraiot.com/

security

View at Medium.com

“Raise the security level of your devices with verified boot,”

IBM has a new article discussing how they secure their cloud, discussing security technologies such as TPM, Intel TXT, and Intel BootGuard:

 

Policy-based governance in a trusted container platform

Project uses Intel Security Libraries for Data Center (Intel SecL-DC), a library that discover, attest, and utilize Intel security features, to enable critical cloud security and confidential computing use-cases.

https://01.org/intel-secl

[There was a time when I had bandwidth to read all new IETF RFCs and I-Ds that came out each day. Sigh…]

There is a new IETF Internet Draft from the “anima Working Group” about storing private keys in embedded devices. Sandelman Software Works and Huawei Technologies are authors. There are other documents from this working group as well.

This document provides a nomenclature to describe ways in which manufacturers secure private keys and public trust anchors in devices.

https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

https://datatracker.ietf.org/wg/anima/about/
https://datatracker.ietf.org/wg/anima/documents/
https://tools.ietf.org/wg/anima/