Another day, another potential Linux security problem.This time around, it's a critical vulnerability in shim -- the key link between Linux and your computer's firmware during boot. Left unrepaired, a network attacker could bypass secure boot and take control of your system.

First things first: The shim in question is not a part of Linux per se. It's the bridge between modern PCs and servers' Unified Extensible Firmware Interface (UEFI) Secure Boot and Linux. Technicalities aside, you must use it to boot Linux, so it's a big deal. 

Shim exists because Secure Boot, a computer security standard to replace older computers' BIOS firmware, wouldn't work with most  Linux distributions when it was introduced in 2012. Secure Boot used -- and still uses -- a Windows-friendly secure key database with no easy way for Linux distros to get it in. Matthew Garrett, a well-known Linux and security developer, created a fix. This was the shim, a signed boot-loader that can add keys to its own database. 

Also: 7 things even new Linux users can do to better secure the OS

Fast forward a dozen years: Microsoft Security Response Center's Bill Demirkapi found a security hole -- CVE-2023-40547 -- a classic buffer overflow. With a buffer overflow, an attacker can break into a system and potentially install the malware of their choice. 

Specifically, the vulnerable part of the shim code is the one that deals with systems using HTTP to boot from a central server on a network. Since you live and work in the 21st century and you'd never boot from a server running insecure HTTP, you have nothing to worry about - right?Wrong.

On Twitter. Demirkapi explained: "A common misconception I've seen is that this only affects you if you use HTTP boot. if that were true, this wouldn't be a Critical bug."

In short, this vulnerability requires a specific set of conditions to be exploitable. An attacker would need the ability to direct the system to boot from an HTTP source, which could involve compromising a server or executing a man-in-the-middle attack. Then, to exploit it, the attacker would have to overcome several hurdles, such as gaining physical access to the device or administrative control; it's not out of the realm of possibility, especially if the attacker has already breached the network perimeter.

So, how bad is it really? As Garrett told Ars Technica. 

In theory, this shouldn't give an attacker the ability to compromise the firmware itself, but in reality, it gives them code execution before ExitBootServices (the handoff between the firmware still running the hardware and the OS taking over), and that means a much larger attack surface against the firmware -- the usual assumption is that only trusted code is running before ExitBootServices. I think this would still be called a boot kit -- it's able to modify the OS bootloader and kernel before execution. But it wouldn't be fully persistent (if you wipe the disk it'd be gone).

The National Vulnerability Database (NVD), which thinks it's awful, first assigned the vulnerability a near-top rating on the Common Vulnerability Scoring System (CVSS) of 9.8.

Also: Linux security: What is sudo and why is it so important?

Red Hat, which maintains shim, takes a more sensible view. The Linux powerhouse gives CVE-2023-40547 an 8.3 score -- that's still bad, but not awful. 

Why so high a score since it's hard to pull off? Shim is in essentially all Linux distributions and has been for over a decade. That's a lot of potential targets. 

To fix it, you'll want to patch shim in all your Linux systems. Or, if you don't ever boot from a network, you could just disable the network boot option. That would work, too. 

Security

8 habits of highly secure remote workers

How to find and remove spyware from your phone

The best VPN services: How do the top 5 compare?

How to find out if you are involved in a data breach -- and what to do next

• 8 habits of highly secure remote workers
• How to find and remove spyware from your phone
• The best VPN services: How do the top 5 compare?
• How to find out if you are involved in a data breach -- and what to do next