NSA has changed Ghidra from freeware to open source software.
https://github.com/NationalSecurityAgency/ghidra
https://github.com/NationalSecurityAgency/ghidra/commits/master
Author: hucktech
UEFI 2.8 released
The UEFI Forum has released the v2.8 specification for UEFI. March not only had the 2.8 release, but a 2.7b release. The last release, 2.7, was in August 2017.
https://uefi.org/specifications
Click to access UEFI_Spec_2_8_final.pdf
Below are list of changes from 2.7b and 2.8, from the Revision History section of the spec.
[The Mantis Number is the entry in the bug database which has all the details on the change, only UEFI Forum members have access to that data, all that is shown in the public spec is the Mantis Number and Bug Title. Non-members will need to use this Description String to try and find the updated section in the spec and look for recent Tianocore implmentation code checkins, or maybe wait for Nikolaj to issue a series of Tweets…]
Revision Mantis Number / Description Date
2.8 1832 Extend SERIAL_IO with DeviceTypeGuid
2.8 1834 UEFI REST EX Protocol
2.8 1853 Adding support for a REST style formset
2.8 1858 New Device Path for bootable NVDIMM namespaces
2.8 1861 New EFI_MEMORY_RANGE_CAPSULE Descriptor
2.8 1866 GetInfo() of Adapter Information Protocol should have a provision for IHV to return no data
2.8 1872 Peripheral-attached Memory
2.8 1876 Remove the EBC support requirement
2.8 1879 Clarification of REST (EX) protocol
2.8 1908 Update of uncommitted data in the FOROM_OPEN callback
2.8 1919 Memory Cryptography Attribute
2.8 1920 Redfish Discover Protocol
2.8 1921 HTTPS hostname validation
2.8 1924 Update to EFI_REST_EX_PROTOCOL.AsyncSendReceive
2.8 1925 Clarify requirement of REST related protocols
2.8 1926 New UEFI Spec Revision –> 2.8
2.8 1935 UEFI JSON Capsule Support
2.8 1936 ResetSystem – support ResetData for all status scenarios.
2.8 1937 Behavior of default values
2.8 1941 New EFI REST JSON Structure Protocol
2.8 1942 Adding dependency expression capability into FMP type capsules
2.8 1947 Keyword strings of Configuration Keyword Handler Protocol Enhancements
2.8 1953 Add document version# conventions
2.8 1954 set (*Attributes) when GetVariable() returns EFI_BUFFER_TOO_SMALL and Attributes is non-NULL
2.8 1956 Platform to honor ActionRequest for Action changing
2.8 1961 Add EFI_UNSUPPORTED to EFI_RUNTIME_SERVICES calls
2.8 1966 Add new capsule processing error codes
2.8 1974 Add new CCIX PER Log Error Section to appendix
2.8 1996 Firmware Processing of the Capsule Identified by EFI_JSON_CAPSULE_ID_GUID
2.7B 1773 Clarify The EFI System Table entry for capsule image
2.7B 1801 ExtractConfig() format may change when called multiple times
2.7B 1835 Misleading / unclear statement about EFI-bootability of UDF media
2.7B 1838 RGB/BGR Contradiction in 2.7 GOP
2.7B 1841 BluetoothLE ECR – support autoreconnect
2.7B 1842 BluetoothLE ECR – Add missing ConnectionCompleteCallback
2.7B 1843 HTTP Example Code Update
2.7B 1844 Replace obsoleted RFC number with new number for TCP
2.7B 1845 Clarification on AIP types “Network boot” and “SAN MAC Address”
2.7B 1846 EFI_LOAD_FILE2 requirement
2.7B 1865 Adding clarification in EFI_NOT_READY for ReadKeyStrokeEx()
2.7B 1869 Clarify FMP buffer too small behavior
2.7B 1874 Add RFC3021 to reference in uefi.org
2.7B 1875 Clarify platform specific elements in chapter 2.6.2
2.7B 1878 Errata – Make DHCP server optional for HTTP boot
2.7B 1880 Arm binding EL2 register state clarification
2.7B 1890 EfiMemoryMappedIO Usage Clarification
2.7B 1897 Clarification on mapping of UEFI memory attributes to ARM memory types and paging attributes
2.7B 1899 Errata: Clarify EFI_INVALID_PARAMETER for FMP->GetImageInfo()
2.7B 1901 GPT Protective MBR description
2.7B 1902 CapsuleImageSize Clarification
2.7B 1903 Root Directory File Name
2.7B 1906 ACPI Table Pointer Installation
2.7B 1908 Update of uncommitted data in the FOROM_OPEN callback
2.7B 1923 Syntax error in EFI iSCSI Initiator Name Protocol
2.7B 1957 Request to add status code EFI_DEVICE_ERROR for ExtractConfig
2.7B 1964 Print disclaimer for all future UEFI specs
2.7B 1987 incorrect VLAN_CONFIG_SET function definition
Intel seeks Security Researcher
[Reminder: I occasionally post interesting-sounding job postings for firmware security researchers and/or developers, using a tag of ‘job-posting’.]
Intel Security Center of Excellence’s goal is to be a prominent leader in the industry to assure security in computing platforms by conducting advanced security research. If you are a seasoned threat, vulnerability and exploit research expert who craves for tons of fun and pride in raising the security bar for ubiquitous computing systems, we would like you to join us as a proud member of Intel’s Advanced Security Research Team. Through your deep vulnerability analysis and mitigation development expertise, you will influence the security of a variety of Hardware, Firmware, Software & Systems spanning a range of products including Devices, Cloud, Auto, IOT, AI, VR, Drones, and Networks. Intel’s Product Assurance & Security team is chartered with building & maintaining customer trust through unparalleled security, privacy & assurance of Intel products. This team drives security & assurance governance, identifies emerging threats, secures existing products through mitigations and defines & initiates future security innovations for Intel products.
https://jobs.intel.com/ShowJob/Id/1658098/Security%20Researcher
OS Development on Windows – Part 1: Building a UEFI Application in NASM
Re: https://firmwaresecurity.com/2018/12/30/nasm-uefi-uefi-sample-application-built-in-nasm/
Here’s another Github project based on the same HackerPulp.com article:
https://github.com/Bowlslaw/uefi-kernel
https://hackerpulp.com/os/os-development-windows-1-building-uefi-applications-nasm/
Heterogeneous Design Creating Havoc With Firmware Versions
[Yeah, it was dated April 1st, but I don’t think it was a joke article….]
Updates, last-minute changes to design add a whole new set of challenges at sign-off.
April 1st, 2019 – By: Ed Sperling
Adding different kinds of processing elements into chips is creating system-level incompatibilities because of sometimes necessary, but usually uncoordinated, firmware updates from multiple vendors. In the past, firmware typically was synchronized with other firmware and the chip was verified and debugged. But this becomes much more difficult when multiple heterogeneous processing elements are introduced into the design for applications such as AI and networking infrastructure. Rather than updating firmware for a single type of processor, there are now multiple different processors, each with their own firmware updates for everything from performance and power to security.[…]
RISC-V OpenSBI mailing list created
A mailing list for OpenSBI has been created.
http://lists.infradead.org/pipermail/opensbi/2019-April/000000.html
http://lists.infradead.org/mailman/listinfo/opensbi
OpenSBI is an open source implementation of the RISC-V Supervisor Binary Interface (SBI). SBI enables an operating system to interact with the supervisor execution environment (SEE). The RISC-V ISA defines SBI to provide an interface for the supervisor OS, streamlining the process of virtualizing and bringing up new hardware platforms. The RISC-V SBI specifications, maintained as an independent project by the RISC-V Foundation, define the legacy SBI interface currently in use by various products as well as by RISC-V QEMU virtual machines. OpenSBI also implements SBI compliant early boot firmwares capable of handling various boot flows and payloads on various environments.
https://github.com/riscv/opensbi
https://github.com/riscv/riscv-sbi-doc
https://riscv.org/2019/01/risc-v-community-releases-opensbi-to-foster-continued-ecosystem-growth/
GrapheneOS
Re: CopperheadOS and AndroidHardening projects, there’s now GrapheneOS, which sounds interesting.
https://play.google.com/store/apps/details?id=app.attestation.auditor
UEFI-Bootloader and UEFI-CPP-headers
These are two new projects from the same author: a new C++-based UEFI bootloader (new code, a work-in-progress), and a set of self-contained UEFI headers: no reliance on Tianocore, GNU-EFI, or other build toolchains.
UEFI-Bootloader:
A simple UEFI bootloader written in C++17 that does not need any third-party support code like Tianocore EDK or gnu-efi; only needs a handful EFI standard definitions that are provided by a sub-module. At the moment, compilation with Microsoft Visual Studio is supported (tested with MSVC 2017). Compilation with clang is also possible.
https://github.com/VioletGiraffe/UEFI-Bootloader
UEFI-CPP-headers:
Some basic UEFI definitions and symbols exactly as definied by the UEFI spec, in a form of C++ headers to be used for writing C++ UEFI applications..
https://github.com/VioletGiraffe/UEFI-CPP-headers
There are about half a dozen projects which have self-contained UEFI headers separate from Tianocore, GNU-EFI and others (in C, C++, and Rust). I wish the UEFI Forum would adopt a set of UEFI headers (in C, C++, and Rust) like this, so people would stop creating new ones…
Tianocore Security Advisories: 10 new entries for March
There are 10 new UEFI/Tianocore Security Advisories, 32-40. I don’t see 10 new CVEs, though…
32. DNS Packet Size Check: Buffer overflow in network stack for EDK II may allow unprivileged user to potentially enable escalation of privilege and/or denial of service via network.
https://edk2-docs.gitbooks.io/security-advisory/content/dns-pack-size-check.html
33. Opal BlockSid Setting Disabled after S3: Improper configuration in system firmware for EDK II may allow unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/opal-blocksid-setting-disabled-after-s3.html
34. PartitionDxe and Udf Buffer Overflow: Buffer overflow in system firmware for EDK II may allow unauthenticated user to potentially enable escalation of privilege and/or denial of service via network access.
https://edk2-docs.gitbooks.io/security-advisory/content/partitiondxe-and-udf-buffer-overflow.html
https://nvd.nist.gov/vuln/detail/CVE-2019-0160
35. Stack Overflow on Corrupted BMP: Stack overflow in corrupted bmp for EDK II may allow unprivileged user to potentially enable denial of service or elevation of privilege via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/stack-overflow-on-corrupted-bmp.html
36. Buffer Overflow in BlockIo service for RAM disk: Buffer overflow in BlockIo service for EDK II may allow an unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via network access.
37. XHCI stack local stack overflow: Stack overflow in XHCI for EDK II may allow an unauthenticated user to potentially enable denial of service via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/xhci-stack-local-stack-overflow.html
38. SW SMI Confused Deputy SmramSaveState.c: Insufficient memory write check in SMM service for EDK II may allow an authenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/sw-smi-confused-deputy-smramsavestate_c.html
39. Unlimited FV Recursion: Stack overflow in DxeCore for EDK II may allow an unauthenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.
https://edk2-docs.gitbooks.io/security-advisory/content/unlimited-fv-recursion.html
40. AuthVariable Timestamp Zeroing on APPEND_WRITE: Logic issue in variable service module for EDK II/UDK2018/UDK2017/UDK2015 may allow an authenticated user to potentially enable escalation of privilege, information disclosure and/or denial of service via local access.
Supply Chain Integrity Month
In the US, the Department of Defense has designated April “Supply Chain Integrity Month”. Hopefully not just on April 1st….
https://www.us-cert.gov/ncas/current-activity/2019/04/01/Supply-Chain-Integrity-Month
Here’s their intro text:
Breaches in the supply chain provide an opportunity for malicious software or hardware to be installed on equipment. Lack of awareness or validation of the legitimacy of hardware and software presents a serious risk to users’ information and the overall integrity of a network environment.
Here’s my UPDATED version of their intro text:
Breaches in the supply chain provide an opportunity for malicious software, firmware, or hardware to be installed on equipment. Lack of awareness or validation of the legitimacy of hardware, firmware, and software presents a serious risk to users’ information and the overall integrity of a network environment.
After reading about half of the documents on their Supply Chain Threats site, I gave up looking for any references to firmware …they all refer to Hardware and Software. 😦
https://www.dni.gov/index.php/ncsc-what-we-do/ncsc-supply-chain-threats
IBM: Enabling secure boot on PowerNV systems
Claudio Carvalho of IBM submitted a 4-part patch to the Linux kernel to the linux(ppc-dev,-efi,-integrity,-kernel) lists.
This patch set is part of a series that implements secure boot on PowerNV systems.
See the comments for more info:
https://marc.info/?l=linux-efi&m=155422892907675&w=2
(I haven’t had time today to look at this code, but presume I think this means getting OPAL firmware to support Linux’s implementation of UEFI’s Secure Boot. There are two separate OpenPOWER UEFI implementations, neither of which are official, but I don’t think either of those are needed for this.)
Move fast and brick firmware: Open Source Firmware Hackathon in Germany in June
Change the way of firmware development, collaborate with others and share knowledge. Closed source firmware development has been the de-facto standard for the electronics industry since its inception. That didn’t change even when open-source took off in other areas. Now, with changing use cases and strict security requirements, it’s more important than ever to take open-source firmware development to the next level. That’s why we’re inviting you to the OpenSource Firmware Hackathon. During the hackathon you can meet core members of the coreboot, TianoCore and LinuxBoot community.
Nautilus: a grammar based feedback fuzzer
more on NetSpectre
How to Identify Counterfeit Electronic Components
Components Technology Institute Inc.
Counterfeit Components Avoidance Program
These slides contain material only for use with CCAP-101 Certification Program. They are the property of Components Technology Institute, Inc. (CTI) and the persons and organizations identified on individual slides.
Enabling Verified boot on Raspberry Pi 3
TL;DR: Verified boot is a fundamental security technology and it is important to be able to experiment with it on easily accessible hardware. However, creating a Verified boot demo on a Raspberry Pi 3 is harder than it sounds. We set out to find resources on the internet. Unfortunately, some of these were outdated, others blatantly wrong. After our fair share of failed builds, corrupted images and kernel panics, we made it to the other side. This is our story.
If next URL does not work, the link is also on the below Github page.
https://blog.nviso.be/2019/04/01/enabling-verified-boot-on-raspberry-pi-3/
Exploiting signed bootloaders to circumvent UEFI Secure Boot
The author of: Super-UEFIinSecureBoot-Disk < https://firmwaresecurity.com/2019/02/27/super-uefiinsecureboot-disk-is-a-bootable-image-with-grub2-bootloader-designed-to-be-used-as-a-base-for-recovery-usb-flash-drives/ > has a new post on Habr.com (in Russian) on UEFI Secure Boot security.
Excerpt of Google Translation: […]In this article we proved the existence of not enough reliable bootloaders signed by Microsoft key, which allows booting untrusted code in Secure Boot mode. Using signed Kaspersky Rescue Disk files, we achieved a silent boot of any untrusted .efi files with Secure Boot enabled, without the need to add a certificate to UEFI db or shim MOK. These files can be used both for good deeds (for booting from USB flash drives) and for evil ones (for installing bootkits without computer owner consent).[…]
https://habr.com/ru/post/446238/
https://translate.google.com/translate?hl=en&sl=zh-CN&tl=en&u=https://habr.com/ru/post/446238/
Cisco Trustworthy Technologies Data Sheet [updated?]
I believe this is a new white paper (or at least revised) from Cisco, on their HW/FW security technologies:
Trustworthy solutions encompass Cisco’s commitment to deliver products and solutions with multilayered security that protect against today’s threats. Trustworthy technologies provide a foundation of security and resilience across Cisco’s solutions portfolio. Trustworthy technologies such as image signing, secure boot, Cisco Trust Anchor module (TAm), and runtime defenses help ensure that the code running on Cisco hardware platforms is authentic, unmodified, and operating as intended. A hardware-level root of trust, unique device identity, and validation of all levels of software during startup establish a chain of trust for the system.
Attacking Hardware Root of Trust from UEFI Firmware, slides uploaded
Debian Secure Boot document updated
Steve McIntyre has updated the Debian wiki page for Secure Boot “to cover a lot more user-facing stuff.”
Firmware Security 
You must be logged in to post a comment.