Critical Vulnerability Affecting Most Linux Distros Allows For Bootkits (arstechnica.com) 51
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. ArsTechnica: The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.
The vulnerability, tracked as CVE-2023-40547, is what's known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the the web is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from. "An attacker would need to be able to coerce a system into booting from HTTP if it's not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it," Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. "An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code)."
The vulnerability, tracked as CVE-2023-40547, is what's known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the the web is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from. "An attacker would need to be able to coerce a system into booting from HTTP if it's not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it," Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. "An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code)."
Critical missing context - UEFI (Score:5, Insightful)
This is not a Linux vulnerability, this is a UEFI vulnerability exposed by a bug in Linux's boot code. Undoubtedly the exact same mechanism might exist in Windows boot code.
The real lesson - network booting is a nifty thing for specialized circumstances for use only by experienced security-aware administrators, and should not be a default install on any consumer grade hardware...
Re: (Score:2)
Desktops have netboot as an choice but most time not an default fallback. Now services seem to have an as an default fall back on by default
Re: (Score:1)
Re: (Score:2)
Whether a windows EUFI boot is impacted is probably more a matter of luck that design. Then again, how many "metal" servers in data centers network boot to windows anymore. If you really need windows in the cloud, it is likely in a virtual.
Re: (Score:2)
Some 40-something% of Azure is Windows...
Re: Critical missing context - UEFI (Score:4, Insightful)
Well, no, it was a shim vulnerability specifically. Evidently they have their own http stack.
In theory, network boot can be used and leave secureboot totally intact (however, the network loaded user space has no protection usually). Here a plain http can manipulate shim executable behavior through headers that should not have been considered part of the executable payload.
The only way to close the user space protection gap currently is to use TPM PCRs to validate integrity and protect the user space.
Re: (Score:1)
Well, no, it was a shim vulnerability specifically.
This is how the problem starts but I'm not sure it's the whole problem.
The only way to close the user space protection gap currently is to use TPM PCRs to validate integrity and protect the user space.
The rest of the problem might be that software that is signed can be modified in memory and still be trusted or that software loaded by the shim is allowed to make changes that it shouldn't have the rights to change. This is the "difficult to remove" part of the problem. If it wasn't part of the problem, the end user would only need to boot a clean environment and do a clean new install.
Re: Critical missing context - UEFI (Score:4, Interesting)
The only way to close the user space protection gap currently is to use TPM PCRs to validate integrity and protect the user space.
LOL, wat?
Since when does Linux allow anyone but root to write to EFI vars by default? If an attacker got enough access to start changing the machine's boot order, you've got far bigger problems to deal with.
As for shim, why the fuck does shim have a network stack!? Most UEFI implementations have PXE / HTTP(s) boot support. Further, there are EFI based HTTP clients out there [github.com]. The only thing shim should need to do to fetch a kernel image, or anything else for that matter, is call exec().
As for the TPM crap, if you need some random chip made by a untrustworthy consortium (The Trusted Computing Group) to tell you that some other untrustworthy consortium (hackers) is trying to take control of your hardware from them, you're in way over your head buddy. (Never mind that said hardware of "yours" is possibly some remote device you've never seen nor had physical possession of.) Operational Security Failures all around.
All of this just makes me more confident in saying that Secure Boot was nothing more than a moving of the goal posts. Instead of hackers trying to overwrite the OS loader on the main storage device (which was a pain to fix, but something any knowledgeable user could do with minimal effort and tools), now we have hackers trying to overwrite the Initial Program Loader (which was made updatable and infinitely more complicated than necessary) on the main board. Which requires complete machine disassembly(on systems that are only getting harder to disassemble because "thin", "light weight", and planned obsolescence), a soldering iron, a chip programmer, and electronics repair skill (a completely different skill set to IT support desk nerds), to reliably fix. It's also cost the industry far more in terms of long term support (need to retain programmers), update logistics (wasn't needed before), and new security requirements (need to protect those precious Platform Keys, forever). Nothing was gained, and everyone's worse off. (Well, maybe not everyone, but that's the kind of "security" a property owner shouldn't want.)
Re: (Score:2)
For TPM, the intent would be to validate the integrity of the pre-OS activity. If someone disables secureboot on you, you can catch it and refuse to allow the LUKS key to unlock the drive. Like if someone boots your laptop to rescue disk while you are in the bathroom, or yanks out your m.2 module if you have a BIOS password.
For why shim has a network stack, well, the open source executables have a history of distrusting the reliability of the firmware, so grub and shim both have embedded http stacks, becau
Re: (Score:2)
For TPM, the intent would be to validate the integrity of the pre-OS activity.
At this point, UEFI is OS activity. It may not be Windows, but it is far more complicated than what is necessary for an IPL embedded in ROM.
If someone disables secureboot on you,
someone boots your laptop to rescue disk while you are in the bathroom
yanks out your m.2 module
All of those situations require physical presence to accomplish. In the world of security, for all intents and purposes you've ceded ownership of the device to the attacker at that point. That's not a system design flaw, it's a unwillingness to accept personal responsibility issue. The system shouldn't protect against that kind of personal failure. Especially one wher
Re:Critical missing context - UEFI (Score:4, Interesting)
OMFG jump to conclusions much? TFA and Ars explicitly place the cause/responsibility on "Linux developers", but as others below point out the issue is in "shim.efi" which technically isn't Linux (and absolutely is not the kernel!), though I'm probably also wrong to state that it is "UEFI" - more like a piece of code that is jointly-terrible, a bad compromise forced on the Linux community by Intel/Microsoft through the UEFI architecture. Its a direct outcome of trying to code a perfect boot security system (SecureBoot) while ignoring many many many years of experience that screams "NEVER TRUST THE INTERNET"... actually it's worse, secure boot turns that on it's head and says "NEVER TRUST THE OWNER OF THE HARDWARE, WE KNOW BETTER"...
I stand by my original point, if your personal non-enterprise, non-cloud computer, can be fooled into looking at insecure internet addresses for boot artifacts (before a single ASM instruction of the Linux kernel itself executes by the way) without requiring evil-maid access to the firmware/FLASH on the motherboard, then the upstream boot processes architects (again Intel/Microsoft and the PCOEMs) are the source of your problem, not "the Linux community".
Re: (Score:3)
OMFG, insecure much? Why is it so hard for Linux community to admit "we had a bug, it's fixed now, go update"? I mean bugs happen, nothnig wrong with that.
Because this shim is only needed if you want to dual boot Windows. Plus this shim was imposed on Linux by Microsoft. If there is any blame, it is with the Linux Foundation allowing this to happen. If the Foundation had b**ls, they would have told Microsoft where to go.
Re: (Score:2)
Yeah, sounds like a non-issue when BIOS booting.
Re: (Score:2)
Yeah, sounds like a non-issue when BIOS booting.
Yeah because BIOS booting is well known for its secure boot process. In other news you can't hack my root password because I don't set one and have auto login enabled. #genius.
Not a bug in UEFI itself (Score:3, Interesting)
This is a bug in shim, the first-stage bootloader used by most Linux distributions when running on UEFI systems. Windows isn't affected because it uses its own first-stage bootloader (well in theory it could contain the same bug, but that would be a strange coincidence). Technically it isn't a Linux vulnerability as it isn't in the Linux kernel itself, but it's a Linux distribution vulnerability as it's in a component used by most Linux distributions.
The bug has nothing to do with UEFI per se. You could
Re: (Score:3)
The bug has nothing to do with UEFI per se. You could end up with the same bug in a BIOS boot option ROM or bootlader for network booting.
I don't think that's quite possible, you would have to literally re-program the BIOS option ROM (usually EEPROM/FLASH connected to the Ethernet MAC device) in order to change the PCI Option-ROM code. It's been a while but I don't recall many Ethernet card vendors allowing you to arbitrarily rewrite PCI Option-ROM addresses from the OS without some pretty special tools (and every vendor was different). Here UEFI includes an explicit mechanism to execute non-OEM supplied code during the boot process, which is
Re: (Score:2)
Here UEFI includes an explicit mechanism to execute non-OEM supplied code during the boot process, which is generic across any UEFI client OS (Linux or Windows), from OS writable disk locations. That makes it a rather large target considering the install base.
No UEFI hasn't included anything. UEFI's job ends when it executes and validates the signature of the shim. Nothing more. The issue at play here is in the shim and the network code of this shim. It is not generic across all OSes, though it is frequently used for Linux it isn't universal there, and it isn't used at all in Windows since secure boot runs a completely different bootloader there.
Re: (Score:2)
No UEFI hasn't included anything. UEFI's job ends when it executes and validates the signature of the shim.
From the original article the faulty shim code has valid UEFI signatures, but that code is allowed to load other remote code which is not signature tested!!!
Worse, this happens "before ExitBootServices" - meaning UEFI his technically still in total control of the CPU. UEFI loads the shim and jumps into the shim code, the shim can be forced to load and execute unsecure/unknown code. Since UEFI has not exited, and there is no "user" context here with reduced privileges and privilege separation that occurs af
Re: (Score:2)
Windows isn't affected because it uses its own first-stage bootloader (well in theory it could contain the same bug, but that would be a strange coincidence)
Yeah, that thing that loads font files from the EFI System Partition? I wouldn't hold my breath. Granted I don't think that it has a network capability, but I also wouldn't put it past Microsoft to add one.
Re: Critical missing context - UEFI (Score:2)
Thanks. When I read the article I wanted to say the very same thing. You've saved me all the typing.
Re: (Score:2)
And you'd be just as wrong as the OP. The issue here isn't a UEFI bug, it's a bug in a shim launched by UEFI to boot a system with secure boot enabled which don't have the MOK set for the boot process. Shims are not UEFI, they are a workaround to secure boot and they come later in the boot process after UEFI has finished doing it's thing. The article has that wrong.
Re: (Score:2)
If I mis-spoke let me re-state, I agree this is not a "bug" in UEFI, its a gaping giant hole in the entire security model of UEFI and secure-boot, and it is enabled (in my opinion strongly encouraged) by the UEFI execution model.
Re-read the original justification for the shim and tell me we didn't intentionally imeplement an insecure "Secure boot" mechanism in order to compete with Microsoft?
Reference: https://www.linux-magazine.com... [linux-magazine.com]
LULZ (Score:2)
When the best you can do with Linux security, is to say that it MIGHT be just as bad as Windows.... Then every single person depending on Linux is FUCKED
Re: (Score:1)
Not people who aren't relying on "Secure Boot," ironically.
Slashdot Submitter quotes the "for dummies" part. (Score:1)
I like how the summary feels like it's trying to talk about this to kindergarteners.
Re: (Score:1)
It neglects to mention that this is known as the Shimmy, Shimmy, Ko Ko Bop exploit.
Re: (Score:2)
It neglects to mention that this is known as the Shimmy, Shimmy, Ko Ko Bop exploit.
And I thought *I* was old... ;-)
Re: (Score:2)
Old, or big?
Both!
Firmware? (Score:3)
Re:Firmware? (Score:5, Informative)
No, tt's not firmware, but it's "close". The bug allows for the installation of a bootkit when one would otherwise be prevented by Secure Boot and related firmware-based protection mechanisms. On Linux systems with Secure Boot enabled, they need to use shim.efi to allow them to boot. shim.efi is signed by Microsoft and is capable of loading a next-stage boot loader, signed or otherwise, dependent on configuration.
This bug impacts shim.efi's HTTP handling when dealing with network booting situations, which impacts a vanishingly small percentage of home/personal users, but may have some impacts in corporate environments. But it requies a MITM presence on the network or some other way of controlling the HTTP traffic going to the target machine.
Does this depend on Secure Boot? (Score:2)
I could be wrong, but I seem to remember that different EFI files are booted if Secure Boot is turned on or off.
If that's right, is the bug also in the other file?
I've never had Secure Boot turned on on my laptop.
Re: Does this depend on Secure Boot? (Score:4, Insightful)
If secureboot is off, then this doesn't matter, as there are far more straightforward ways to inject code.
On most Linux systems with Nvidia and secureboot enabled, its easier to attack by finding the private key that the end user probably accepted into mok manager. The "easy" way to deal with secureboot compatibility with locally built kernel modules pretty much leaves things wide open. It's possible to be more careful with the key material, but the tools and documentation tends to produce a "bad" scenario.
Re: (Score:2)
Good luck writing to the EFI partition without root.
Re: (Score:3)
Well the concept is that, hypothetically, not even 'root' can inject malicious kernel code in a secureboot system. You try to compile your own and modprobe and it'll faiil to pass a signature check. You write a rootkit for grub to run and grub will fail to load it because it doesn't have the signature.
The presumption is that even 'root' can fall before an attacker, and it would sure be swell if the kernel space were protected even then. Of course, relevant xkcd:
https://xkcd.com/1200/ [xkcd.com]
It's of small comfort
Re: (Score:1)
It's a FAT partition, you don't need root for that, just access to the disk (FUSE, boot disk, ...)
Re: (Score:2)
An attacker with physical access to my laptop is not part of my threat model.
I want to know if this is remotely exploitable with Secure Boot off.
Re: (Score:2)
Debian for example installs shim and boots from it, but it can be uninstalled if the user chooses to. (The system will default to grub in that instance.)
Re: Does this depend on Secure Boot? (Score:2)
If secureboot is off, then an attacker in this position could just skip the header game and skip you m malicious content in the payload.
Any attack that could leverage this behavior could just change your kernel.
It's a bit of a technicality to call it a remote attack, the first phase would be to modify things so that shim would http boot. This is not a normal thing for it to do, so attacker would have to tweak content in the boot partition or perhaps mess with uefi variables. So you have to have local physi
Re: (Score:1)
If you have a laptop, then physical access should be part of your threat model. But yes, as I said, any user on the machine with permission to mount/read/write a FAT partition (which is often enabled from user space through FUSE, depending on your operating system settings).
Very few people have their systems locked down to the end where this isn't a problem. CIS/NIST audits often recommend disabling FAT completely and not having FUSE but many people want to be able to plug in a USB stick and have it functio
bare metal (Score:2)
How many people even do bare metal installs these days? How many use PXE and leave PXE on after?
Very limited (Score:3)
To get pw0ned, you must be using secure boot AND booting from an http server (not https) AND someone has to have already pw0ned your network.
The other potential vector is physical access. We've all known for a long time that given physical access, no matter what OS you're running, all bets are off.
It's a bug, it is more Linux adjacent than Linux itself, and it should be fixed, but the vulnerable population is pretty small.
Re: (Score:2)
Indeed. But really bad Linux vulnerabilities are so rare that other stuff has to be blown all out of proportion in order to make the largest "competitor" not look like the abysmal security failure it clearly is.
Buffer Overflow? (Score:2)
I'm only an amateur programmer but it seems to me that preventing a buffer overflow is trivial.
Is this just lazy programming?
Re: (Score:2)
I too am an amateur programmer and like you my code is always 100% perfect and bug free. Yes all these "professionals" are just "lazy". /s
Re: (Score:2)
Hahaha, not vulnerable! (Score:2)
I do not use "secure" boot. It is at best fake security anyways.