News

Reminder: UEFI Migration Requirements for Dev Partners Coming Soon

• By Kurt Mackie
• August 25, 2022

Certain "memory mitigation requirements" for PCs and software that use the Unified Extensible Firmware Interface (UEFI) are coming in November, Microsoft reminded developer partners this week.

The requirements for original equipment manufacturers (OEMs) and software developers need to be met before Nov. 30, 2022. On that date, Microsoft's memory mitigation requirements will be in effect for "all applications to be signed by the Microsoft third-party Unified Extensible Firmware Interface (UEFI) Certificate Authority (CA)."

Memory Mitigations
Various technical requirements are specified for OEMs and software developers working with UEFI systems. There are stipulations for Portable Executable (PE) and Common Object File Format (COFF) files, used to wrap executable code. Most of these stipulations appear to be aimed at preventing code from launching spurious processes or using memory space inappropriately.

For instance, code submitted for UEFI CA signing should "not run self-modifying code." Microsoft also wants appropriate use of EFI_MEMORY_ATTRIBUTE_PROTOCOL if an application "attempts to load any internal code into memory for execution." The code "must not assume all memory ranges are valid" and "stack space cannot be used for code execution."

Secure Boot Inadequate
UEFI is the successor to the BIOS PC boot process and is perhaps best known for ushering its "Secure Boot" protection scheme for PCs at the firmware level. Secure Boot was introduced back when Windows 8 was newly emerging and it was supposed to have blocked malware, such as "rootkits" and "bootkits," which activated before an operating system had booted up.

Later, in 2019, Secured-core PCdcrosoft and the PC industry, promising to deliver the same boot-level protections that Secure Boot was supposed to have addressed. Back then, Microsoft had explained that the Strontium attack group was able to leverage firmware vulnerabilities and apparently bypass Secure Boot protections.

Secure Boot just wasn't up to the task, according to a 2019 comment by David Weston, then partner director for OS security at Microsoft.

"Since firmware is already trusted to verify the bootloaders, Secure Boot on its own does not protect from threats that exploit vulnerabilities in the trusted firmware," Weston wrote at that time. "That's why we worked with our partners to ensure these new Secured-core capabilities are shipped in devices right out of the box."

Vendor Inconsistencies
Microsoft's document on "OEFI Memory Mitigations," which also describes Microsoft's UEFI CA signing requirements, suggested that firmware mitigation techniques are getting unevenly applied by OEMs and software developers, which is a problem.

Here's how that notion was expressed:

The Cybersecurity & Infrastructure Security Agency recently found that firmware vulnerabilities, as a whole, continue to rise. Meanwhile, firmware mitigation techniques being deployed are insufficient to prevent modern attacks and mitigations are not being applied uniformly across vendor firmware implementations.

Microsoft's announcement this week echoed earlier warnings to software makers. For instance, this Jan. 28, 2021 announcement had offered an even longer list of requirements for developers and OEMs to meet Microsoft's UEFI CA signing requirements.

Microsoft conducts a "manual review" process for binaries before granting UEFI CA compliance. This process applies to "UEFI firmware binaries targeted to x86, x86-64, or ARM computers," the January announcement clarified.