Detecting backdoors in hardware is hard. I just noticed this paper from last year:

X-Ray Tech Lays Chip Secrets Bare: Researchers in Switzerland and the U.S. have a non-destructive technique that can reverse engineer an entire chip without damaging it[…]

https://spectrum.ieee.org/nanoclast/semiconductors/design/xray-tech-lays-chip-secrets-bare

https://zenodo.org/record/2657340

https://www.nature.com/articles/s41928-019-0309-z

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

Re: https://firmwaresecurity.com/2015/06/25/tool-mini-review-uefi-firmware-parser/ and other posts,

uefi-firmware-parser has been forked, and that fork has some fixes/improvements.

Let’s hope the two versions get merged sometime in the future.

https://gitlab.com/saruman9/uefi-firmware-parser

Original version:

https://github.com/theopolis/uefi-firmware-parser

https://pypi.org/project/uefi_firmware/#history

By: Dominik Maier, Lukas Seidel, Shinjo Park

Rogue base stations are an effective attack vector. Cellular basebands represent a critical part of the smartphone’s security: they parse large amounts of data even before authentication. They can, therefore, grant an attacker a very stealthy way to gather information about calls placed and even to escalate to the main operating system, over-the-air. In this paper, we discuss a novel cellular fuzzing framework that aims to help security researchers find critical bugs in cellular basebands and similar embedded systems. BaseSAFE allows partial rehosting of cellular basebands for fast instrumented fuzzing off-device, even for closed-source firmware blobs. BaseSAFE’s sanitizing drop-in allocator, enables spotting heap-based buffer-overflows quickly. Using our proof-of-concept harness, we fuzzed various parsers of the Nucleus RTOS-based MediaTek cellular baseband that are accessible from rogue base stations. The emulator instrumentation is highly optimized, reaching hundreds of executions per second on each core for our complex test case, around 15k test-cases per second in total. Furthermore, we discuss attack vectors for baseband modems. To the best of our knowledge, this is the first use of emulation-based fuzzing for security testing of commercial cellular basebands. Most of the tooling and approaches of BaseSAFE are also applicable for other low-level kernels and firmware. Using BaseSAFE, we were able to find memory corruptions including heap out-of-bounds writes using our proof-of-concept fuzzing harness in the MediaTek cellular baseband. BaseSAFE, the harness, and a large collection of LTE signaling message test cases will be released open-source upon publication of this paper.

https://arxiv.org/abs/2005.07797

Maybe we need to wait until WiSec2020 to see code?

https://www.isti.tu-berlin.de/security_in_telecommunications/menue/research/publications/

https://wisec2020.ins.jku.at/

H2Lab is a French non-profit association targetting the development and production of hardware, software and tools for embedded, security and is building is expertise against the passion and skills of all its members.

https://h2lab.org/blogposts/h2lab_comming/

The only other UEFI-centric Go project I know of has moved to a subproject of LinuxBoot/Fiano. This project appears to be unrelated to LinuxBoot/Fiano code:

Try be a complete UEFI API written in Go. No silly bindings.[…]

https://github.com/Foxboron/goefi

 

A modern newly-available classic BIOS-based PC? How is it that I’m just learning about this?! 🙂

https://yeokhengmeng.com/2020/05/review-of-a-new-old-motherboard-nuxt-v2.0/

https://github.com/skiselev/micro_8088

https://github.com/monotech/NuXTv2

https://monotech.fwscart.com/NuXT_v20_-_MicroATX_Turbo_XT_-_10MHz_832K_XT-IDE_Multi-IO_SVGA/p6083514_19777986.aspx

 

This is nice overview of the Arm ISA-centric features available in the latest version of GCC.

I wish each ISA vendor would do a blog post like this for each major Clang/GCC compiler release!

https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/making-the-most-of-the-arm-architecture-in-gcc-10

A new U-Boot tool.
And hopefully multiple tools in the future! 🙂

The ioXt Alliance, who is working to “build confidence in IoT products”. have recently released a requirements document (they call it a Pledge) that mentions some HW and Platform Firmware requirements, including Secure Boot:

Click to access ioXt-Pledge-Book_S.pdf

 

https://www.ioxtalliance.org/the-pledge

PS: It is just me, or are all the images on this web site larger than most? 🙂

[…]It turns out, however, that TFTP operations have not been tested in all UEFI firmwares extensively.[…]

https://github.com/pief/tftptest.efi

Trusted Objects is a French company doing IoT Security. They are  offering a firmware security solution:

“Trusted Objects Secure Firmware (TOSF) is a configurable secure firmware solution designed for Secure Element-based hardware implementation.”

https://www.trusted-objects.com/news/21/12/Trusted-Objects-publishes-a-Position-Paper-on-Software-IP-Protection-for-OEM/d,buddy012-newsDetail.html

https://www.trusted-objects.com/doc.html

https://www.trusted-objects.com/en-corporate/documentation-technical.html

 

Hyper-V backdoor […] provides an interface for inspecting of hypervisor state (VMCS, physical/virtual memory, registers, etc.) from guest or host partition and perform the VM escape attacks.

https://github.com/Cr4sh/s6_pcie_microblaze/tree/master/python/payloads/DmaBackdoorHv

From last month’s CVE, excerpt from XDA-Developers.com page:

[…]Moreover, Android Verified Boot 2.0 may kick in and brick your phone if you try to make permanent changes to protected partitions such as boot, system, and vendor without an unlocked bootloader. That being said, the exploit is currently available in its compiled form, while the developer will soon release the source code.[…]

https://github.com/bluefrostsecurity/CVE-2020-0041

https://labs.bluefrostsecurity.de/blog/2020/04/08/cve-2020-0041-part-2-escalating-to-root/

https://source.android.com/security/bulletin/2020-03-01

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0041

https://www.xda-developers.com/lg-v50-thinq-root-locked-bootloader-exploit/

Debian has a new wiki page, a directory of open source firmware projects.

Search for “was lost” to see if you can help them with some missing firmware issues.

https://wiki.debian.org/Firmware/Open

Please edit the Debian wiki with other projects that need to be added (there aer a few).

 

[…]2692 new commits by over 190 developers[…] Besides a whole lot of Chrome OS devices (again), this release features a whole bunch of retrofits for devices originally shipping with non-coreboot OEM firmware, but also support for devices that come with coreboot right out of the box. For that, a shout out to System76, Protectli, Libretrend and the Open Compute Project![…]

Announcing coreboot 4.12

 

[…]New schemas include the addition of SecureBootDatabase and Signatures for managing UEFI Secure Boot databases using Redfish. The schema updates include SecureBoot, Certificate, CertificateCollection, and CertificateLocations.[…]

https://www.dmtf.org/content/new-redfish-release-20201-adds-support-network-device-registry-secure-boot-database-and

It looks like the main DMTF Redfish web sites are not yet updated with pointers to above spec, beyond the above press release page. Use that page for download links.

[…]Operating system installation routines tend to have these boot configuration labels hard-coded and to create them in EFI PROM automatically. So in case a computer has, say, several Ubuntu instances installed, it is also likely to have several identical “ubuntu” boot configuration labels in its EFI menus, causing a kind of confusion. One might further want to rename boot configurations, so to make them distinguishable, but unfortunately the standard efibootmgr utility has no option for that.[…] The rename-efi-entry script is designed to facilitate renaming EFI boot configuration entries using efibootmgr utility. It automates querying current EFI configuration and bootable partition data, and also shaping command line arguments for efibootmgr.[…]This script can only rename EFI boot entries that are related to Linux. It will most probably ignore the other ones.[…]

https://github.com/s-n-ushakov/rename-efi-entry

This project is intended to illustrate the harnessing required to fuzz a Linux kernel module using AFL through the Xen VMI API. The tool utilizes Xen VM forks to perform the fuzzing, thus allowing for parallel fuzzing/multiple AFL instances to fuzz at the same time. Coverage guidance for AFL is achieved using Capstone to dynamically disassemble the target code to locate the next control-flow instruction. The instruction is breakpointed and when the breakpoint triggers, MTF is activated to advance the VM ahead, then the processes is repeated again. The tool allows fine-tuning how many control-flow instructions to allow the fuzzing to encounter before terminating. This provides an alternative to timing out the fuzzing process.

https://github.com/intel/kernel-fuzzer-for-xen-project

UEFI has a few network commands, such as [1]. There’s a new one in the works, an HTTP client.

“Introduce an http client utilizing EDK2 HTTP protocol, to allow fast image downloading from http/https servers. HTTP download speed is usually faster than tftp. The client is based on the same approach as tftp dynamic command, and uses the same UEFI Shell command line parameters. This makes it easy integrating http into existing UEFI Shell scripts.”

Network security researchers should spend more time focusing on UEFI. Not only is there a new command, but the new network stack components. There’s a lot of network security tools that have not been directed at UEFI’s network stack and command line tools. Where security tools vary greatly bewteen OSes (and thus don’t apply well to UEFI),  that is not the case with network security against common network protocols.

Hmm, today I can’t find this mailing list post in the proper EDK2 mailing list archives, the archives page does not show up-to-date message list. And I can’t find the source code on the EDK2 github page. 😦 In any case, the source is in the mailing list post, at at least Mail-Archive.com has a copy. Look for it to be in the main EDK2 tree at some time the future.

https://www.mail-archive.com/devel@edk2.groups.io/msg19906.html
https://www.mail-archive.com/devel@edk2.groups.io/msg14349.html

[1]
https://github.com/tianocore/edk2/tree/master/ShellPkg/DynamicCommand/TftpDynamicCommand
https://github.com/tianocore/edk2/tree/master/ShellPkg/Library/UefiShellNetwork2CommandsLib
https://github.com/tianocore/edk2/tree/master/ShellPkg/Library/UefiShellNetwork1CommandsLib

Re: https://firmwaresecurity.com/2020/05/11/spycheck-and-thunderspy/

Intel has a new blog post on the topic:

https://blogs.intel.com/technology/2020/05/more-information-on-thunderspy/#gs.5ro74j