Linux Vendors Squawk: PATCH NOW — CVSS 9.8 Bootkit Bug in shim.efi

A Microsoft researcher found it—and it’s somehow Microsoft’s fault.

A critical vulnerability in most Linux distributions now has a patch ready. Enterprise users especially need this if booting using HTTP or PXE.

So go get it. In today’s SB Blogwatch, we patch shim and update the DBX.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: White Stripes locations.

Snow Joke

What’s the craic? Dan Goodin broke the story—“Critical vulnerability affecting most Linux distros”:

“Constitutes a major escalation”
Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they’re hard to detect or remove. [It] could prove useful if an attacker has already gained some level of access inside a network and is looking to take control of connected end-user devices.
…
The vulnerability resides in shim … a small component that runs … early in the boot process before the operating system has started. [It] resides in a part of the shim that processes booting up from a central server on a network using … HTTP.
…
The ability to execute code during the boot process … constitutes a major escalation of whatever access an attacker already has. It means the attacker can neutralize many forms of endpoint protection. … The harm from successful exploitation is serious [hence] the severity rating of 9.8 out of … 10.

Who found it? Bill Toulas explains—“Critical flaw in Shim bootloader”:

“Not a bug that should be ignored”
The new Shim flaw … was discovered by Microsoft’s security researcher Bill Demirkapi, who first disclosed it on January 24, 2024. … Shim is a small open-source bootloader maintained by Red Hat that is designed to facilitate the Secure Boot process on computers using Unified Extensible Firmware Interface (UEFI).
…
Linux users are advised to update to the latest version of Shim, v15.8, which contains a fix for CVE-2023-40547 and five other important vulnerabilities. … Although unlikely to be mass-exploited, [it] is not a bug that should be ignored, as executing code before OS boot is one of the strongest and stealthiest forms of system compromise.

Somebody had to make the obvious gag. And somebody did—“The Real Shim Shady”:

“Revocation list”
On February 2, 2024 details about a new vulnerability … was released for shim, a critical piece of software used by most Linux distributions in the boot process to support Secure Boot. … While on the surface this may look like an issue only affecting Red Hat … this vulnerability impacts all Linux distributions that support Secure Boot … including Debian, Ubuntu, SUSE, and others.
…
Alongside updating to the new shim version containing the patch … the Secure Boot chain of trust must [also] be updated. This means the UEFI Secure Boot DBX (revocation list) must be updated to include the hashes of the vulnerable shim software. … The order of operations here is important.

Could we see this coming? sixoh1 gives off an I-told-you-so vibe:

The issue is in “shim.efi” which technically isn’t Linux. [It’s] a piece of code that is jointly-terrible—a bad compromise forced on the Linux community by Intel/Microsoft through the UEFI architecture … (Secure Boot).
…
It’s a direct outcome of trying to code a perfect boot security system … while ignoring many many many years of experience that screams, “NEVER TRUST THE INTERNET.” Actually it’s worse, Secure Boot turns that on its head and says, “NEVER TRUST THE OWNER OF THE HARDWARE, WE KNOW BETTER.”

Surely there’s limited exposure? u/Hrmbee thinks so:

If an organization is so behind the times that they’re still deploying boot images over an unencrypted HTTP server, then it’s fairly likely that they also won’t … have the ability to deal with these current issues either.

And mogbert goes further:

This looks like it only would affect machines that are either already booting from HTTP, or that they already have enough access to force it to boot from HTTP. … Am I reading this wrong?

Yes you are reading it wrong. So says the horse’s mouth—Bill Demirkapi:

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. [There are other] local/adjacent network/remote vectors.

Oh, I see. Kindly exit u/QuipVirtuosoEccentri’s grassed area:

[For] all the at-home tinkerers who have zero experience in the Enterprise world:
1. This is in shim. Literally almost ground zero for the whole chain of trust when it comes to booting with secure boot.
2. How do you think all the servers/containers/VMs/etc that host almost everything most people use on a daily basis boot?
…
Just because you aren’t creative enough to know how to exploit this, doesn’t mean other people lack your creativity. Networks are big and scary places, and once you break the secure boot process, you can make it load binaries from across the globe over simple http.

Meanwhile, this Anonymous Coward is more mature (and also less):

Neglects to mention that this is known as the Shimmy, Shimmy, Ko Ko Bop exploit.

And Finally:

Isaac says, “Use this video for ideas on where to go on holiday.”

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi, @richij or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Cornelius Ventures (via Unsplash; leveled and cropped)