Linux: vulnerability in Shim exposes most distributions to attacks


Image: Andrew Brookes/Getty Images.

A new security vulnerability has been discovered, which could affect Linux systems. This time, it’s a critical vulnerability in Shim, an open-source bootloader that links a computer’s operating system and firmware when it boots.

If this vulnerability is not fixed, an attacker could bypass Secure Boot and take control of the system.

Vulnerability in Shim

First things first: Shim question is not part of Linux as such. It is a gateway between the Unified Extensible Firmware Interface (UEFI) secure boot system of modern PCs and servers and Linux. Technical aspects aside, it’s required to boot Linux, so it’s an important item.

Shim exists because Secure Boot, a computer security standard intended to replace BIOS firmware in older computers, did not work with most Linux distributions when it was introduced in 2012. Secure Boot used – and still uses – a secure key database tailored for Windows, with no easy way for Linux distributions to access it. Matthew Garrett, a well-known Linux developer, has created a patch: Shim, a bootloader that can add keys to its own database.

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

Specifically, the vulnerable part of Shim’s code is that which relates to systems using HTTP to boot from a central server on a network.

A flaw that can be exploited “under conditions”

You would think that in this day and age, when you never boot from a server using an insecure HTTP protocol, there is nothing to worry about. Unfortunately, this is false, as explained on Twitter Bill Demirkapi : Some people believe that this flaw “only affects you if you use HTTP boot.” If this were true, it would not be a critical flaw.”

In summary, this vulnerability requires a specific set of conditions to be exploitable. An attacker must be able to direct the system to boot from an HTTP source, which may involve compromising a server or executing a man-in-the-middle attack. .

Then, to exploit it, the attacker will have to overcome several obstacles, such as gaining physical access to the device or administrative control; it’s not completely impossible, especially if the attacker has already breached the network perimeter.

A critical vulnerability

So how serious is the situation really? “In theory, the vulnerability should not allow an attacker to compromise the firmware itself. But, in reality, it can allow it to execute code before ExitBootServices (the transition between the firmware still running the hardware and the operating system taking over). Which means the attack surface is much larger against firmware – the usual assumption is that only trusted code executes before ExitBootServices. I think you could still call this a boot kit – it’s capable of modifying the bootloader and operating system kernel before execution. But it wouldn’t be totally persistent (if you erase the disk it would disappear),” explains Matthew Garrett to Ars Technica.

The National Vulnerability Database (NVD) initially gave the vulnerability a score of 9.8 on the Common Vulnerability Scoring System (CVSS) – almost the maximum score.

Red Hat, which manages Shim, takes a more moderate view, giving CVE-2023-40547 a score of 8.3. A score still high, but less alarming.

How to protect yourself from it?

So why such a high score for this difficult-to-exploit security flaw? Well, simply because Shim is present in practically every Linux distribution, and has been for over a decade. Which makes a lot of potential targets.

To prevent your system from being vulnerable, you can patch Shim in all your Linux systems. Or, if you never boot from a network, you can simply disable the network boot option.

Source: ZDNet.com





Source link -97