CVE-2022-28735

What it actually does

The shim_lock verifier in GRUB2 fails to restrict loaded files to kernel images on shim-enabled secure boot systems, permitting arbitrary non-kernel files, modules, and code to be executed during the boot process and thereby breaking the measured boot trust chain.

Why it matters to the business

Organizations relying on secure boot to protect against rootkits and boot-time malware face elevated risk of persistent system compromise, potentially requiring extended downtime for remediation and increasing exposure to supply-chain or physical-access attacks on critical infrastructure.

How an attack unfolds

An attacker with local access crafts or obtains a malicious GRUB2 module or configuration file, places it in a location accessible to the bootloader, and leverages the flawed shim_lock check to load and execute the unverified code before the kernel boots, establishing an early foothold that survives subsequent OS security controls.

How to fix it

Upgrade gnu grub2 to a version containing the corrected shim_lock verifier logic as soon as vendor packages become available; in the interim restrict physical and local administrative access, enable additional measured-boot technologies such as TPM-based attestation where feasible, and monitor upstream GRUB2 and shim project advisories for patch releases.

How to confirm the fix worked

After applying updates, verify that only properly signed kernel images are accepted by shim and that attempts to load non-kernel modules are rejected; re-test the boot chain with known-good and known-bad artifacts under secure boot enforcement.

Typical attack path

1. Obtain local or physical access to the target system
2. Place a malicious GRUB2 module or configuration artifact in an accessible filesystem location
3. Trigger GRUB2 execution under shim secure boot
4. Exploit the permissive shim_lock verifier to load the unverified artifact
5. Execute attacker-controlled code in the pre-kernel environment

How to detect it

Review bootloader configuration files and module load history in system logs for unexpected non-kernel artifacts; examine GRUB2 environment variables and any evidence of unsigned modules being processed during boot; correlate with physical-access or local-privilege events.

What your security team should do

• Prioritize patching gnu grub2 on all systems that rely on shim secure boot
• Audit physical and privileged local access controls to reduce the attack surface
• Incorporate GRUB2 version checks into configuration management and vulnerability scanning pipelines
• Establish monitoring for upstream GRUB2 and shim security announcements