The world of computer security sees hundreds of new vulnerabilities every month. Some are minor, but others have the potential to cripple core security functions right from the system’s boot-up. Today, we’ll be digging into CVE-2023-40546, a flaw uncovered in Shim, the crucial component that connects Linux distributions to UEFI Secure Boot. This vulnerability may not let hackers instantly take over a PC, but it shows how a simple programming oversight can disrupt vital security mechanisms.

What is Shim and Why Does It Matter?

Before diving in, let’s clarify what Shim is. When you boot a modern Linux system on a computer using UEFI Secure Boot, Shim acts as a trusted first-stage bootloader. Signed by Microsoft, it verifies the next pieces of the boot process (like GRUB or the Linux kernel), ultimately making sure only trusted code can kick off.

Shim needs to talk to the UEFI firmware, set up secure variables, and gracefully handle errors so you know what’s happening if things go wrong.

In this case, CVE-2023-40546 is

> “A flaw in shim when an error happens while creating a new ESL variable. If shim fails to create the new variable, it tries to print an error message to the user; however, the number of parameters used by the logging function doesn't match the format string used by it, leading to a crash under certain circumstances.”
(Red Hat Bugzilla bug 223936)

What Causes the Crash? Let's See the Code

In C, printing error messages is done with printf-style format strings—think printf("Value: %d", val). If you don’t pass the exact number or type of parameters the format string asks for, you get unpredictable behavior and sometimes a straight-up crash!

Here’s a simplified code snippet similar to the vulnerable area in Shim

// pseudo-code example!
efi_status = create_new_esl_variable(...);

if (efi_status != EFI_SUCCESS) {
    // BAD: log_error expects 1 argument, but 2 provided!
    log_error("Failed to create new ESL variable, status: %lx", efi_status);  
}

Suppose the log_error function is defined like this

void log_error(const char *msg) {
    // ... print the message
}

But the code passes both a format string and the status number to print. If log_error doesn’t expect it, the format string gets no replacement value, which can lead to crashes—especially in secure boot environments where memory is tightly controlled.

Why Is It Dangerous?

- Boot disruption: Crashing Shim during boot can halt the startup process, leaving the system stuck and unusable until fixed.
- Denial of Service: While this isn’t a clear route to code execution, a bad actor could, in some theoretical situations, intentionally cause the variable creation to fail and thus brick a machine’s boot process.
- Secure Boot chain break: Any error disrupting the chain of trust for Secure Boot is always a top priority for patching.

Exploit Details

The real-world exploitation of this bug is tricky—attackers would need to find a way to force Shim into a situation where creating the ESL variable fails. On some systems, simply filling up EFI variable storage (through repeated writes or by abusing certain UEFI features) might do the trick. When the failure happens, the buggy logging function crashes Shim.

System never boots, effectively a Denial of Service.

Because this happens so early in the boot process, regular OS protections probably can’t help. The effect is a persistent “bootloop” until the firmware storage is cleared or a patched Shim is deployed.

Fix and Response

The patch was simple: either correct the format string to match the argument list, or change the logging function to accept variable arguments. Here’s what that might look like in the fix:

// FIX: Only pass the string, or use a printf-style function
// Option 1: Remove format argument
log_error("Failed to create new ESL variable, status check the logs.");
// Option 2: Use a logging function that supports format specifiers
log_errorf("Failed to create new ESL variable, status: %lx", efi_status);

You can see the upstream patch proposal here.

Distributions affected fixed the issue in their Shim packages (Fedora, Red Hat, etc).

- Most users should just update their system's firmware or bootloader packages to get the new, safe Shim.

References

- NVD CVE-2023-40546 entry
- Red Hat Security Advisory
- GitHub Shim CVE patch
- Linux Foundation Shim homepage
- UEFI Secure Boot Explained

Conclusion

CVE-2023-40546 reminds us that Secure Boot’s weakest link might be something as simple as a mismatched parameter in a logging call. It’s a classic “minor mistake, major impact” bug. Keeping your systems updated—and understanding both the bug and the patch—goes a long way in keeping your boot chain solid and trustworthy.

Timeline

Published on: 01/29/2024 17:15:08 UTC
Last modified on: 04/25/2024 14:15:08 UTC