Shim vulnerability exposes most Linux systems to attack

    Published on:

    Andrew Brooks/Getty Images

    Another day, another potential Linux security issue. This time it's a critical vulnerability in shim, the critical link between Linux and a computer's firmware during startup. If left unrepaired, a network attacker could bypass secure boot and take control of the system.

    First of all, the shim in question is not part of Linux itself. It provides a bridge between Unified Extensible Firmware Interface (UEFI) secure boot and Linux on modern PCs and servers. Technicalities aside, this is a big deal because you need to use it to boot Linux.

    Shim exists because when Secure Boot, a computer security standard that replaces BIOS firmware on older computers, was introduced in 2012, it didn't work on most Linux distributions. Secure Boot used and still uses a secure key database suitable for Windows. There is no easy way to introduce it to Linux distributions. Matthew Garrett, a well-known Linux and security developer, has created a fix. This was a shim, a signed bootloader that can add keys to its own database.

    Related article: 7 things even Linux beginners can do to make their OS more secure

    Fast forward a dozen years: Bill Demirkapi of Microsoft Security Response Center I found a security holeCVE-2023-40547 — Classic buffer overflow. A buffer overflow could allow an attacker to compromise your system and install arbitrary malware.

    Specifically, the vulnerable part of the shim code is the part that deals with systems booting from a central server on the network using HTTP. You don't have to worry about anything because you live and work in his 21st century and will never boot from a server running insecure HTTP. mistaken.

    On Twitter.Demirkapi explained: “A common misconception is that this only affects when using HTTP boot. If that's true, this is not a critical bug.”

    This means that certain conditions are required to exploit this vulnerability. The attacker would need the ability to tell the system to boot from her HTTP source, which could include compromising the server or performing a man-in-the-middle attack. Then, to exploit it, an attacker must overcome several hurdles, such as gaining physical access to the device or gaining administrative control. It's not outside the realm of possibility, especially if the attacker has already breached the network perimeter.

    So how bad is it really?like garrett said ars technica.

    In theory, this should not give an attacker the ability to compromise the firmware itself, but in practice, Execute code before ExitBootServices. (handoff between the firmware running the hardware and the OS that takes over), which means the attack surface for the firmware is much larger. It is generally assumed that only trusted code is running before ExitBootServices. I think this is still called a boot kit. It allows you to modify the OS bootloader and kernel before execution. However, it is not completely permanent (it disappears when you erase the disk).

    of National Vulnerability Database (NVD)I think that's terrible, but first assigned This vulnerability has a rating of 9.8, near the highest, on the Common Vulnerability Scoring System (CVSS).

    Related article: Linux Security: What is sudo? Why is it so important?

    red hatMaintaining Sims takes a more enlightened view. Linux powerhouses offer: CVE-2023-40547 Score 8.3 — It's still bad, but not terrible.

    It's hard to pull off, so why does it score so high? Shim is included in basically every Linux distribution and has been around for over a decade. There are many potential targets.

    To fix it: Apply a patch shim to all Linux systems. Alternatively, if you have never booted from the network, you can disable the network boot option. That would work too.


    Leave a Reply

    Please enter your comment!
    Please enter your name here