New
Microsoft Reminds PC Partners of UEFI Mitigation Requirements Coming in November
Microsoft this week reminded developer partners of certain “memory mitigation requirements” for PCs and software that use the Unified Extensible Firmware Interface (UEFI).
Requirements for original equipment manufacturers (OEMs) and software developers must be met by November 30, 2022. On that date, Microsoft’s memory mitigation requirements will be in effect for “all applications to be signed by the third-party Microsoft Unified Extensible Certification Authority (CA) Firmware Interface (UEFI).”
Memory impairments
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 seem to be aimed at preventing code from launching bogus processes or using memory space inappropriately.
For example, code submitted for UEFI CA signing must “not run self-modifying code”. Microsoft also wants proper use of EFI_MEMORY_ATTRIBUTE_PROTOCOL if an application “attempts to load internal code into memory for execution”. The code “must not assume that all memory ranges are valid” and “stack space cannot be used for code execution”.
Improper Secure Boot
UEFI is the successor to the PC BIOS boot process and is perhaps best known for pioneering its “Secure Boot” protection scheme for PCs at the firmware level. Secure Boot was introduced back when Windows 8 was just emerging and it was supposed to have blocked malware, such as “rootkits” and “bootkits”, that activated before a bootable system started. exploitation.
Later, in 2019, Secure-Core PCs were announced by Microsoft and the PC industry, promising to provide the same boot-level protections that Secure Boot was supposed to have handled. At the time, Microsoft explained that the Strontium attack group was able to take advantage of firmware vulnerabilities and apparently bypass Secure Boot protections.
Secure Boot just wasn’t up to the task, according to a 2019 comment from David Weston, then associate director for operating system security at Microsoft.
“Because firmware is already trusted to verify boot loaders, Secure Boot alone does not protect against threats that exploit vulnerabilities in trusted firmware,” Weston wrote at the time. “That’s why we’ve worked with our partners to ensure these new Secured-core features are delivered to devices right out of the box.”
Vendor inconsistencies
Microsoft’s “OEFI Memory Mitigation” document, which also outlines Microsoft’s UEFI Certificate Authority signing requirements, suggests that firmware mitigation techniques are applied unevenly by OEMs and vendors. software developers, which is problematic.
Here is how this notion was expressed:
The Cybersecurity & Infrastructure Security Agency recently found that firmware vulnerabilities, as a whole, continue to increase. Meanwhile, deployed firmware mitigation techniques are insufficient to prevent modern attacks, and mitigations are not consistently applied across vendor firmware implementations.
Microsoft’s announcement this week echoes previous warnings to software makers. For example, this January 28, 2021 announcement offered an even longer list of requirements for developers and OEMs to meet Microsoft’s UEFI Certificate Authority signing requirements.
Microsoft performs a “manual review” process of binaries before granting UEFI CA compliance. This process applies to “UEFI firmware binaries intended for x86, x86-64, or ARM computers,” the January announcement said.
About the Author
Kurt Mackie is senior news producer for 1105 Media’s Converge360 group.