OSDev.org

Hi,

I've run into an interesting issue with Grub2. My problem is, the more I read about it, the more bullshit it smells.

Let's start with the facts. Debian reported lots of bugs with Grub2. This includes memory overflow, use-after-free etc. memory problems, but also a nasty security hole because of the overcomplicated grub.cfg. So far everything is reasonable and proved. But for the latter, both DSA and CVE link to a site, which originally reported the Grub2 problem.

A flaw in the grub.cfg parsing code was found allowing to break UEFI Secure Boot and load arbitrary code. Details can be found at https://www.eclypsium.com/2020/07/29/th ... -the-boot/

That site states, I quote:

The vulnerability affects systems using Secure Boot, even if they are not using GRUB2.

What??? Is there any other boot loader that parses grub.cfg at all???
It becomes even more interesting, watch this:

The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.

Heh? This is the part that smells (very badly).

Seriously, what's going on? Is this really what it really looks like? <paranoid>An attack against the last loophole to boot Open Source systems with UEFI SB?</paranoid>

It is obvious that a bug in Grub parsing grub.cfg can't affect other boot loaders and it most definitely can't affect the Microsoft Third Party UEFI CA... I've read through the linked site, and there's no answer. They talk about lots of things, including DMA attacks, and Grub2 bugs, but I still can't understand why would anyone conclude that a bug in a particular boot loader undermines the CA? This just makes no sense.

What do you think?

Cheers,
bzt

bzt wrote:I still can't understand why would anyone conclude that a bug in a particular boot loader undermines the CA?

Because an attacker can replace the existing bootloader with a compromised version of GRUB.

Octocontrabass wrote:

bzt wrote:I still can't understand why would anyone conclude that a bug in a particular boot loader undermines the CA?

Because an attacker can replace the existing bootloader with a compromised version of GRUB.

How? And replacing the MS CA solves this exactly how? Finally, how could a compromised Grub affect systems which are not booting with Grub at all?

The UEFI SB works like this: the UEFI firmware loads the MS CA (KEK) signed shim. Then shim loads the MOK signed grub. If grub loads a malicious code, that cannot replace shim, because it cannot provide an KEK signed executable. Without replacing shim, it cannot change the MOK key. Without changing the MOK, it cannot provide a MOK signed boot loader either. So, back to my original question, how?

But just for the sake of the argument, let's assume it is possible for a malicious code to provide an KEK signed executable to replace shim. Then why would issuing a new MS CA prevent the same attack in the future? If a system never executes that malicious code (no Grub), then how could that possibly cause any harm?

In short, if what they saying is true (a bug in a certain bootloader affects other loaders and the CA signature architecture), then that would mean the whole Secure Boot infrastructure is meaningless and pointless. I have a feeling they are just using the Grub bug as an excuse to close the firmware.

Cheers,
bzt

bzt wrote:How? And replacing the MS CA solves this exactly how? Finally, how could a compromised Grub affect systems which are not booting with Grub at all?

There are vulnerable versions of GRUB with a signature that was - in the end - provided by the MS CA. Therefore an attacker can replace the current boot loader with a vulnerable version of GRUB, and then have GRUB load whatever they need. Which is exactly the sort of thing Secure Boot was supposed to prevent, so bang up job there.

Replacing the MS CA with another version that has never provided a signature for the compromised version of GRUB prevents that version from being accepted on boot. Therefore the attacker would not be able to compromise the boot process, merely to brick the system.

Systems that don't use GRUB are also at risk since an attacker can just bring GRUB into the system. We are learning here that code signing doesn't help if the code is not secure. Which would be novel, were it not for the Windows Driver signing program, which already learned the same thing. I know of no instance in which code signing prevent exploits. Microsoft Windows, Nintendo Wii, Microsoft Xbox 360, Sony Playstation 3 - none of these were saved by it.

bzt wrote:So, back to my original question, how?

Without having read the articles you provided: By exploiting the signed version of GRUB, unsigned code can be loaded and executed. Therefore the entire chain of trust is broken past GRUB.

Nothing can prevent GRUB from just executing whatever code it wants, except it should be impossible to get a signature for a bootloader that does something like that. However, sometimes problems are hidden. Once an earlier link in the chain of trust passes control to GRUB, and GRUB is vulnerable, all bets are off.

bzt wrote:In short, if what they saying is true (a bug in a certain bootloader affects other loaders and the CA signature architecture), then that would mean the whole Secure Boot infrastructure is meaningless and pointless.

BINGO! The candidate gains 100 points. At 101 points you get a washing machine.

Code signing doesn't help. Software security is a hard problem, and you can't just throw cryptography at it until it goes away.

nullplan wrote:

bzt wrote:How? And replacing the MS CA solves this exactly how? Finally, how could a compromised Grub affect systems which are not booting with Grub at all?

There are vulnerable versions of GRUB with a signature that was - in the end - provided by the MS CA. Therefore an attacker can replace the current boot loader with a vulnerable version of GRUB, and then have GRUB load whatever they need. Which is exactly the sort of thing Secure Boot was supposed to prevent, so bang up job there.

You mean by "replace" that an attacker has access to the boot partition? That's an epic fail, no matter SB or not... On most systems modifying /boot partition requires root access in the first place... or physical access like in evil maid attack (but when the attacker has physical access, no check will save you, because they can simply turn SB off or install their own KEK/MOK).

nullplan wrote:Replacing the MS CA with another version that has never provided a signature for the compromised version of GRUB prevents that version from being accepted on boot.

There are two little problems with this: first, Grub was never signed by the MS CA (it's signed by the MOK), and second you can blacklist (sorry denylist) any executable just by adding its hash to the DBX. This is no reason to revoke and replace the MS CA.

And replacing the MS CA won't help to replace the MOK, meaning you can still install a compromised Grub if you want to...

I feel this is just an excuse to make all the Grub-user Linux distros to pay the singing fee yet AGAIN.

nullplan wrote:Systems that don't use GRUB are also at risk since an attacker can just bring GRUB into the system.

Yeah, but if I were in the attacker's shoes, then I would rather bring Win8 boot manager with a policy that simply turns SB off... Much simpler and easier. Besides, as I've said earlier, modifying the /boot partition requires root privilege.

nullplan wrote:We are learning here that code signing doesn't help if the code is not secure. Which would be novel, were it not for the Windows Driver signing program, which already learned the same thing. I know of no instance in which code signing prevent exploits. Microsoft Windows, Nintendo Wii, Microsoft Xbox 360, Sony Playstation 3 - none of these were saved by it.

Agreed, that's why I call "secure" boot a marketing bullshit, it does not make the system secure at all, just locked in.

nullplan wrote:

bzt wrote:So, back to my original question, how?

Without having read the articles you provided: By exploiting the signed version of GRUB, unsigned code can be loaded and executed. Therefore the entire chain of trust is broken past GRUB.

Yeah, that's clear, my question was more like how could they exploit this on a system that does not use Grub (provided modifying /boot requires superuser privilege).

nullplan wrote:Code signing doesn't help. Software security is a hard problem, and you can't just throw cryptography at it until it goes away.

Well said!

Cheers,
bzt

nullplan wrote:Code signing doesn't help. Software security is a hard problem, and you can't just throw cryptography at it until it goes away.

It helps if:

1) The code is signed by the end-user, not some industry third-party.
2) The hardware allows the end-user to chose what signing keys will and won't be accepted.
3) The end-user's private key is not accessible to the attacker, and the vector for the attack is not social engineering of the end-user.

EDIT: The question, of course, is then "how often are these conditions fulfilled for a machine using secure boot", and the answer is likely "not often".

bzt wrote:You mean by "replace" that an attacker has access to the boot partition? That's an epic fail, no matter SB or not...

It is, but it is the sort of thing SB is supposed to prevent. Using Windows, getting root is possible by just flashing up a message. I once saw an exploited installer program. Like all installers, it would ask for root permission, and then write files into root-only directories. But it would also use the root permission to do its own evil thing. Since getting the UAC prompt is normal for an installer program, the user was none the wiser. And this thing could modify the boot sector.

linguofreak wrote:It helps if:

1) The code is signed by the end-user, not some industry third-party.
2) The hardware allows the end-user to chose what signing keys will and won't be accepted.
3) The end-user's private key is not accessible to the attacker, and the vector for the attack is not social engineering of the end-user.

I know too many end-users that don't know what a file is to think that is a good idea. The end-user likely has less expertise in what they are signing then industry third-parties. At least those usually contract programmers, and could, in theory, audit what they are signing. There are two possibilities for what you are proposing to play out:

(1) Either the boot loader can be signed from things inside the machine. Then an attacker can use a trojan horse attack as outlined above, even if the OS tries to make access to the private key hard.
(2) Or the boot loader cannot be signed from things inside the machine. Then it will be "too difficult to use" (I can already picture the whining faces of users required to plug in their private key dongle once more)

In both cases, code signing is yet another patch. It doesn't help if the signed code isn't secure. No matter what you do, if the code can be subverted into doing that which it isn't supposed to do, then all your security measures are for naught. And if big companies like Microsoft, Nintendo, and Sony, throwing massive money bags at the problem, cannot manage to produce secure code, then it is unlikely anyone else can, either.

linguofreak wrote:EDIT: The question, of course, is then "how often are these conditions fulfilled for a machine using secure boot", and the answer is likely "not often".

That too. However, you can't expect anyone to use cryptography effectively if they don't understand it. I'm an OS programmer, and I don't understand secure boot, so how can I reasonably expect anyone else to understand it? My mom was a network admin most of her life, and she doesn't understand it. And my dad double-clicks all links in the web browser. Last time he understood computers was when he was installing DOS from 5 1/4" floppy disks on his 386.

Putting cryptography in the hands of the unlearned is only wise if they know what to do with it. Not necessarily how it all works in the details, just what it is they are doing. And most people don't know what their computer is doing on boot up, or why it should be necessary to sign anything that is running at the time.

linguofreak wrote:

nullplan wrote:Code signing doesn't help. Software security is a hard problem, and you can't just throw cryptography at it until it goes away.

It helps if:

1) The code is signed by the end-user, not some industry third-party.
2) The hardware allows the end-user to chose what signing keys will and won't be accepted.
3) The end-user's private key is not accessible to the attacker, and the vector for the attack is not social engineering of the end-user.

EDIT: The question, of course, is then "how often are these conditions fulfilled for a machine using secure boot", and the answer is likely "not often".

Wow, great list! I would add one more point, although it should be obvious:

4) the end-user signs only executables that they trust, and they keep those up-to-date, replacing with bug-fixed versions ASAP.

nullplan wrote:But it would also use the root permission to do its own evil thing.

Exactly. Now why would an attacker want to install a compromised boot loader? To gain access on the machine of course. But they already have to have that for this kind of attack And as I've said, replacing the MS CA can't and won't stop this kind of attack.

Thanks guys, it seems I'm not the only one who thinks something is smelling like bullshit around UEFI SB.

Cheers,
bzt

bzt wrote:Now why would an attacker want to install a compromised boot loader? To gain access on the machine of course.

Access isn't much good if you're caught before you get what you want. A compromised bootloader is harder to spot than other attack vectors, so an attacker can maintain that access for a long period of time.

It's the sort of thing you'd use for espionage, not for farming cryptocurrency.

Anyone running a Linux system should take note of this: https://arstechnica.com/gadgets/2020/07 ... e-patches/