Swift-Apple-EFI-Patcher: Apple EFI Patcher written in Swift with Flashrom Integration

Apple EFI Patcher written in Swift with Flashrom integration. This application was developed out of a need for a simple user-friendly and native macOS based approach to working with Apple EFI roms. The result is an all-in-one application capable of utilizing affordable SPI / eeprom chip reading hardware for reading/dumping from, patching and writing to EFI Rom chips. This application integrates flashrom support in order to communicate with hardware, thus incorporating a lot of the methodologies and current hardware already utilized by technicians.[…]

https://github.com/sadponyguerillaboy/Swift-Apple-EFI-Patcher

See-also:
https://github.com/sadponyguerillaboy/Python-Apple-EFI-Patcher

patch

Multiple Cisco UCS-Based Products UEFI Secure Boot Bypass Vulnerability


Advisory ID: cisco-sa-20200219-ucs-boot-bypass
First Published: 2020 February 19 16:00 GMT
Workarounds: No workarounds available
Cisco Bug IDs: CSCvn09490 CSCvq27796 CSCvq27803

A vulnerability in the firmware of the Cisco UCS C-Series Rack Servers could allow an authenticated, physical attacker to bypass Unified Extensible Firmware Interface (UEFI) Secure Boot validation checks and load a compromised software image on an affected device. The vulnerability is due to improper validation of the server firmware upgrade images. An attacker could exploit this vulnerability by installing a server firmware version that would allow the attacker to disable UEFI Secure Boot. A successful exploit could allow the attacker to bypass the signature validation checks that are done by UEFI Secure Boot technology and load a compromised software image on the affected device. A compromised software image is any software image that has not been digitally signed by Cisco.
[…]There are no workarounds that address this vulnerability. Cisco has released firmware updates that address this vulnerability.
[…]UEFI Secure Boot is enabled only in a small subset of Cisco UCS-based appliances. For all the other appliances, the feature is not used, so the vulnerability does not apply.

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20200219-ucs-boot-bypass

Debian 10 released, with Secure Boot

[…]The UEFI (“Unified Extensible Firmware Interface”) support first introduced in Debian 7 (code name “wheezy”) continues to be greatly improved in Debian 10 “buster”. Secure Boot support is included in this release for amd64, i386 and arm64 architectures and should work out of the box on most Secure Boot-enabled machines. This means users should no longer need to disable Secure Boot support in the firmware configuration.[…]

https://lists.debian.org/msgid-search/bcd827ac-a3cf-6695-9a21-9b9d148aed76@debian.org

Hmm, above URL generates an error on the resulting Debian.org-hosted page, but the MARC and Mail-Archive links work, the latter rendered better. The Debian page also wrongly points to the now-dead GMane site, two Debian bugs that need to get fixed…

https://www.debian.org/News/2019/20190706

edk2-gdb-server: Open Source EDK2 GDB Server

For a long time Intel has offered a “freeware” (not open source) solution to debug UEFI with a 2-system solution, one running either Linux/GDB or Windows/Windbg:

https://firmware.intel.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool

Last updated in 2017, it used to work on the old TunnelMountain desktop systems, I’ve been meaning to see if it works on MinnowBoard2 systems. And this is Intel-centric (and I presume it may also work on AMD), but, I’m not aware of ARM — nor UEFI Forum’s Tianocore — having a similar offering, which I’d like to be able to use on a UEFI-based Rasberry Pi. HOWEVER… I just noticed this, which came out LAST YEAR, somehow I missed it, an open source solution!!

This is a open code replacement for Intel’s binary only GDB server that comes as part of the ‘Intel UEFI Development Kit Debugger Tool’. Since that tool is Intel x86/64 Linux/Windows only this allows more flexibility. E.g. you can run this on any ARM based SoC with python3 and a USB OTG port connected directly to your target via a USB2.0 EHCI Debug port using the Linux USB OTG Debug Port gadget. You can then connect to that target remotely from your build box, etc. This also allows you to tweak the debugger itself. I’ve already added some additional functionality here to assist when using SourceLevelDebugPkg on non-EDK2 (i.e. no source available) firmwares such as AMI Aptio IV.

https://github.com/night199uk/edk2-gdb-server

Now it just needs also add LLDB support (especially for the Clang-centric HBFA branch)… 🙂 Given this is open source, unlike the Intel solution, this is a possiblity!

LVFS: checking for expired certs in UEFI

Richard Hughes has two new blog posts, one with an update to LVFS, and one on how it parses firmware ‘blobs’:

[…]Specifically, firmware is now being checked for expired Authenticode certificates which expired more than 3 years before the upload date of the firmware. The LVFS is also looking for test signing certificates that really should not exist in production firmware. All existing firmware on the LVFS is being tested, and the test backlog should be complete by this afternoon. All test failures are currently waivable.[…]

https://lists.linuxfoundation.org/pipermail/lvfs-announce/2019-June/000022.html
https://blogs.gnome.org/hughsie/2019/06/02/breaking-apart-dell-uefi-firmware-capsuleupdate-packages/

UEFI, bootloaders, and Rust

There was a talk about UEFI programming in Rust at MadRust, the Madrid Rust Meetup:

https://github.com/aruiz/madrust-uefi-skeleton

https://drive.google.com/file/d/19Zv1jbu-leKsa0DaRWEWt0dHSeIwwqVg/view

https://www.meetup.com/MadRust/events/259988070/

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

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.

https://edk2-docs.gitbooks.io/security-advisory/content/buffer-overflow-in-blockio-service-for-ram-disk.html

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.

https://edk2-docs.gitbooks.io/security-advisory/content/authvariable-timestamp-zeroing-on-append_write.html

 

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/

GRUB2 security changes in Fedora

[…]Include Grub’s “verify,” “cryptodisk,” “luks” and <others here> modules in grubx64.efi of the ‘grub2-efi-x64’ package.  Users utilising secure boot functionality on the UEFI platform cannot insert modules that aren’t in grubx64.efi. Paradoxically, this means that security-conscious users cannot use grub’s verify module, or employ (near) full disk encryption using cryptodisk and luks. The security benefits of signature verification would reach more users if Fedora automated it by incorporating the process into grub2-mkconfig. For the long-term, to grant flexibility with grub2 modules on secure boot instances, it may be advisable to sign the .mod files in the ‘grub2-efi-x64-modules’ package, modify grub2-mkconfig (or -install) to copy the necessary modules into the EFI partition when required by the user’s configuration and then allow inserting of signed modules in secure boot instances.[…]

https://fedoraproject.org/wiki/Changes/Include_security_modules_in_efi_Grub2

https://www.phoronix.com/scan.php?page=news_item&px=GRUB2-New-EFI-Modules-For-F31

 

bcdedit-revert-uefi-gpt-boot-order: Powershell script to modify the UEFI/GPT boot order

This powershell script modifies the UEFI/GPT boot order by finding the first non-Windows entry and moving it to the top of the order. When using UEFI+GPT, the Windows installation (since Windows 7?) creates its own boot device entry (“Windows Boot Manager”, a.k.a. “{bootmgr}”) in the UEFI/GPT boot order list and, obnoxiously, takes the liberty of moving said entry to the top of the list. Under most circumstances, this is fine, and probably desirable. However for systems used for repeated deployment testing, or systems which you want a different bootloader to take priority (such as dual-boot systems, or computer lab systems that can be remotely re-imaged), this is a show stopper. So I needed a way to do this programmatically. This script makes use of the arcane and undocumented {fwbootmgr} identifier implemented by bcdedit to find the first non-Windows boot device entry in the UEFI/GPT boot order list and move it to the top of the list.

https://github.com/mmseng/bcdedit-revert-uefi-gpt-boot-order