BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[starshipeleven]

Perhaps I was wrong all along or Microsoft quietly shifted their position from earlier press releases or opinion......
....
I do remember reading it other press.

Yeah I remember that too but I always thought it was journalists misreading something and then all citing each other as a source, or something like that. I never found any form of first-hand material where MS actually said anything different from their Win8 specification, that also became the Win10 specification.

Hilariously at the end of the document you refer too...

Secure Boot, Trusted Boot, and Measured Boot create an architecture that is fundamentally resistant to bootkits and rootkits. In Windows 10, these features have the potential to eliminate kernel-level malware from your network. This is the most ground-breaking anti-malware solution that Windows has ever had; it’s leaps and bounds ahead of everything else. With Windows 10, you can truly trust the integrity of your operating system.

It's technically right. The issue isn't in Secure Boot itself, it's in the UEFI firmware, a cesspool of copypasta and security by obscurity, so yeah the boot process is pretty safe, but installing firmware-based rootkits has never been easier, so yeah, cool, you still lose.

Really, if we are talking of board firmware and hardware interfaces in general, Microsoft has been a very positive force, ruling with an iron fist and slapping the OEMs into compliance of some standards for booting, discovering hardware and such. Just look at what happens outside of their area of influence (average ARM board), complete and total NIH shitshow with 5 different ways of booting and hacking hardware-specific information and blobs into the kernel all over the place.

[starshipeleven]

3) Could you recommend an alternative that supports dm-crypt/LUKS boot partition?

Why do you even need that? UEFI forces you to have a "boot partition" where you must drop a bootloader and you must sign it because you can't encrypt the EFI partition, what's the difference between using GRUB and just dropping the whole kernel in EFI?

[starshipeleven]

I believe that grub will call a predefined file, its how it works..

You can sign it, keep it in /boot (in an encrypted root setup) or do whatever. There are many ways to make it safe.

The Grub DSL Parser, doesn't verify( by default ), the grub.cfg signature..
Of course if it is signed, you have another problem( each time you change it ), that file is there to be changed.. some sort of chicken-egg problem..

You need to run grub-update scripts anyway after each edit, just make them sign again the file.

We need to find a way out of this Secure boot Madness,
With Microsoft in Control even in the server Market( servers brought to use Linux exclusively )...its madness..

Just disable it? Use the shim?

Some years Ago, maybe Microsoft could dictate, nowadays the unix/Linux/BSD market is HUGE,
I don't understand why we don't have more control over our own ecosystem hardware..

Because on servers none is giving a fuck, it's probably going to be running blobs for the cards and stuff anyway.

[Slartifartblast]

MS UEFI Secure boot specification disagrees https://docs.microsoft.com/en-us/win...0-boot-process
All x86-based Certified For Windows 10 PCs must meet several requirements related to Secure Boot:

• They must have Secure Boot enabled by default.
• They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
• They must allow the user to configure Secure Boot to trust other bootloaders.
• They must allow the user to completely disable Secure Boot.

If something has changed, please link a statement or something.

Perhaps I was wrong all along or Microsoft quietly shifted their position from earlier press releases or opinion......

"For Windows 10 PCs, this is no longer mandatory. PC manufacturers can choose to enable Secure Boot and not give users a way to turn it off. However, we’re not actually aware of any PC manufacturers that do this."

https://www.howtogeek.com/116569/htg...ans-for-linux/

I do remember reading it other press.

Hilariously at the end of the document you refer too...

Secure Boot, Trusted Boot, and Measured Boot create an architecture that is fundamentally resistant to bootkits and rootkits. In Windows 10, these features have the potential to eliminate kernel-level malware from your network. This is the most ground-breaking anti-malware solution that Windows has ever had; it’s leaps and bounds ahead of everything else. With Windows 10, you can truly trust the integrity of your operating system.

[tuxd3v]

This is a GRUB problem, not a ESP partition problem. It's not hard to make a safe configuration file that is tamper-proof, but GRUB2 lives in 1999 so they just read whatever text file called "grub.cfg".

I believe that grub will call a predefined file, its how it works.. it need to find a predefined file.. with grub its 'grub.cfg'..
Now the problem is that grub.cfg is not signed, only one vendor signs grub.cfg..

The Grub DSL Parser, doesn't verify( by default ), the grub.cfg signature..
Of course if it is signed, you have another problem( each time you change it ), that file is there to be changed.. some sort of chicken-egg problem..

We need to find a way out of this Secure boot Madness,
With Microsoft in Control even in the server Market( servers brought to use Linux exclusively )...its madness..

Some years Ago, maybe Microsoft could dictate, nowadays the unix/Linux/BSD market is HUGE,
I don't understand why we don't have more control over our own ecosystem hardware..

[Jabberwocky]

After reading through the disclosures, this really isn't as big a problem as some people in the tech press are making out. This requires someone to already have administrative and/or hardware access to pull this off. The only people that have access to grub.cfg in any sane configuration is root. That being the case, it's already possible to disable secure boot entirely in many systems via various mechanisms. Such a person can already insert malicious modules, divers, boot kits, etc. Naturally, you can have a potential chain of vulnerabilities in which this plays one part of that chain, but that would have to be a very targeted attack for a known target that has known versions of vulnerable software that have yet to be patched.

Certainly Rust would likely have prevented this particular vulnerability since it seems to be a classic buffer overflow attack on a problematic case: arbitrary text parsers. That said, UEFI doesn't actually need Grub to boot a kernel any more. We might consider ditching Grub entirely, which has been an Achilles heel in the Linux boot process for ages. You can argue endlessly about Rust v. C (or any other such language), but the fundamental problem would be solved by having a less complex boot chain for Linux to begin with.

It's so much fun arguing. It is the fuel to my hubris: C is bad because it can't catch mistakes like these. Rust could have caught this mistake but it's a stupid language. C++ is the best and all who disagree are ignorant or scared. It is logical to make abstractions based on frequently mutating logic! OOP! OOP! OOP!

Your comment is my favorite so far.

1) What do you think would be the path of least resistance to increase use of alternatives?

2) What is your favorite alternative?

3) Could you recommend an alternative that supports dm-crypt/LUKS boot partition?

This is a GRUB problem, not a ESP partition problem. It's not hard to make a safe configuration file that is tamper-proof, but GRUB2 lives in 1999 so they just read whatever text file called "grub.cfg".

Yeah, that's the problem, too many people are afraid of change. Don't want to use object oriented languages, don't want to follow good software development practices, don't want to use nice things like pulseaudio, systemd, Wayland etc.

[starshipeleven]

yeah, the ESP partition is crazy stuff indeed..

This is a GRUB problem, not a ESP partition problem. It's not hard to make a safe configuration file that is tamper-proof, but GRUB2 lives in 1999 so they just read whatever text file called "grub.cfg".

[tuxd3v]

Yeah, it took me a while to understand that they're talking about different OS and system vendors having their own binaries of GRUB signed with some Microsoft key, so that they can boot it.

This means even big companies (say those who buy desktop/server hardware) aren't using their own keys instead of Microsoft's, they're just buying the machines with Microsoft keys pre-installed, and depending on Microsoft to sign their bootloaders for them (and that even RHEL and others depend on Microsoft to do so).

This means that Microsoft pretty much has full control over what OS can run on consumer hardware, servers etc. and a bunch of other stuff. And this doesn't bother people?

I could accept SecureBoot as security if atleast some people had the option of having hardware that didn't require Microsoft to approve of the OS being booted. But now it seems clear that SecureBoot is inextricably dependent on Microsoft not being evil and anti-competitive.

Are people really this naive?

yeah, you summarized it well..

Indeed now I think it turns out to be easy to understand the whining from GNU/Linux or BSD's camps( when Microsoft proposed Secure boot ).
People was fuming over it..

[starshipeleven]

Incorrect, as of Win 10 this is no longer required of manufacturers and it's up to them to allow secureboot to be disabled.

MS UEFI Secure boot specification disagrees https://docs.microsoft.com/en-us/win...0-boot-process
All x86-based Certified For Windows 10 PCs must meet several requirements related to Secure Boot:

• They must have Secure Boot enabled by default.
• They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
• They must allow the user to configure Secure Boot to trust other bootloaders.
• They must allow the user to completely disable Secure Boot.

If something has changed, please link a statement or something.