In mid-2022, security researchers uncovered CVE-2022-28737—a nasty overflow bug hiding in the way the popular "shim" EFI bootloader loads EFI binaries. Understanding this vulnerability helps us grasp just how deeply firmware flaws can cut, and why even minor parsing errors in firmware can risk the whole security chain of your computer.

This exclusive deep dive will guide you through the bug: what it is, where it lives in the code, proof-of-concept details, and the broader impact. We’ll use clear examples and simple language, aiming for everyone to follow, regardless of their experience with EFI internals.

First, some quick background

- shim is a small bootloader used on many Linux distributions to help start the main operating system, especially on computers with Secure Boot enabled. Think of it as a translator, letting Secure Boot approve Linux even if the firmware wouldn't natively trust it.
- EFI (Extensible Firmware Interface, or UEFI) is the first thing your PC runs when it powers on, initializing hardware and handing off control to an OS bootloader.

So, a flaw in how a shim loads an EFI binary means an attacker might hijack your boot process before your OS even starts.

Where Does the Bug Live?

The problem hides in shim’s code that loads and parses sections of EFI binaries—specifically, in the handle_image() function.

It has a header,

- Then a set of sections, each with fields like where it should go in memory and how big it is (that’s the SizeOfRawData field).

The Vulnerable Code

The overflow comes from trusting the SizeOfRawData field, supplied by whatever binary’s being loaded. Unfortunately, this field is not always verified carefully enough.

Here’s a cut-down, simplified version of what the real C code looks like

EFI_STATUS handle_image(...) {
    ...
    for (i = ; i < num_sections; i++) {
        SectionHeader *section = ...;
        void *dest = image_base + section->VirtualAddress;
        // Vulnerable: trusting SizeOfRawData!
        memcpy(dest, data + section->PointerToRawData, section->SizeOfRawData);
        // ... no check if 'dest' is inside buffer bounds
    }
    ...
}

If an attacker supplies a malformed EFI binary where SizeOfRawData is too large or points outside of the expected region, memcpy() will happily trample over RAM—and possibly critical control structures.

Here’s how an attacker might abuse this

1. Craft an evil EFI executable, setting SizeOfRawData for one or more sections to target memory regions just outside the intended buffer.
2. Sign this with a trusted certificate (if they’re trying to bypass Secure Boot in a real-world attack).

This overflows memory just after the, say, .text section.

- If this overflows into a code pointer, function table, or some other sensitive structure, on the next boot or call, the attacker’s code takes over.

While practical remote exploitation requires deeper access (since you often need to modify boot files), this is exactly the stage attackers want, because it’s before the OS even starts.

Here’s how you might visualize a malicious section table in the binary

# Pseudocode: crafting a malicious EFI binary section header
section_table = []
for i in range(num_sections):
    section = {
        "VirtualAddress": x100 + i*x100,
        "SizeOfRawData": x100000,  # Much bigger than the allocated buffer
        "PointerToRawData": correct_file_offset(i)
        # ...and so on
    }
    section_table.append(section)
# Write this into your EFI binary file format!

After building and signing such a binary, just booting with it triggers the out-of-bounds write.

Highest risk: systems that allow untrusted EFI binaries or don’t strictly enforce Secure Boot.

- Potential impact: Arbitrary code execution is possible. Once control is gained, attackers can install rootkits or hide persistent malware, often invisible to regular antivirus.
- Why so dangerous: Because it affects the *very first* code your system runs—meaning no OS-level defenses can help.

Original Sources

- CVE-2022-28737 in NVD (National Vulnerability Database)
- shim repository / known issues
- Red Hat Security Advisory

Update to the latest shim version available for your distribution.

- Only use signed, trusted EFI executables, and do not allow boot from removable media except when required.

Lessons For Developers

- Never trust file fields! Always validate buffer sizes before copying data, especially in boot processes.

Conclusion

CVE-2022-28737 shows just how small errors in firmware-level code can open catastrophic risk. For users: keep firmware up to date and use Secure Boot wisely. For developers: treat every untrusted field as a potential weapon.

Stay safe, patch early—and never, ever trust unchecked sizes.

*If you enjoyed this technical breakdown, follow for more clear, exclusive computer security deep-dives!*

Timeline

Published on: 07/20/2023 01:15:00 UTC
Last modified on: 07/28/2023 15:33:00 UTC