BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[mppix]

Surprise, GRUB OS has security issues..
If only we had simple&effective alternatives.

[wswartzendruber]

lol, but why?

Cocaine, specifically. The language moves fast, but not necessarily with attention to detail. An example of this was the Error trait being unsuitable for use (by the failure crate) until Error::cause was deprecated for Error::source. It was mentioned in the GitHub issue that this was a simple oversight.

[ssokolow]

Cocaine, specifically. The language moves fast, but not necessarily with attention to detail. An example of this was the Error trait being unsuitable for use (by the failure crate) until Error::cause was deprecated for Error::source. It was mentioned in the GitHub issue that this was a simple oversight.

Because it was something that slipped through the cracks back in 2015 during the rush to get everything prepared for the 1.0 release and its API-stability promise. I was there at the time. It was very busy and I was quite surprised how little went wrong.

[wswartzendruber]

Because it was something that slipped through the cracks back in 2015 during the rush to get everything prepared for the 1.0 release and its API-stability promise. I was there at the time. It was very busy and I was quite surprised how little went wrong.

What drove the sense of urgency?

[stormcrow]

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.

[cl333r]

Cocaine, specifically. The language moves fast, but not necessarily with attention to detail. An example of this was the Error trait being unsuitable for use (by the failure crate) until Error::cause was deprecated for Error::source. It was mentioned in the GitHub issue that this was a simple oversight.

Ok that's an oversight, but imho doesn't yet make them drug junkies, any more serious issues?

To me the biggest annoyance is the myriad of types because of memory management, like &MyClass, Rc<MyClass>, Rf<RefCell<MyClass>>, RefCell<Rc<MyClass>>, Box<MyClass>, "cow" stuff, and other, and because of this you constantly have to deal with shitty decisions of unwrapping, wrapping or otherwise disguising your variable to match the function's parameter type.

[wswartzendruber]

Ok that's an oversight, but imho doesn't yet make them drug junkies, any more serious issues?

To me the biggest annoyance is the myriad of types because of memory management, like &MyClass, Rc<MyClass>, Rf<RefCell<MyClass>>, RefCell<Rc<MyClass>>, Box<MyClass>, "cow" stuff, and other, and because of this you constantly have to deal with shitty decisions of unwrapping, wrapping or otherwise disguising your variable to match the function's parameter type.

The language, to me, has always had this aura of being wound up and in a really big hurry. But for what?

[cl333r]

The language, to me, has always had this aura of being wound up and in a really big hurry. But for what?

Like the "fat enums" in Rust - it's a language of trade-offs, but these trade-offs IRL tend to be a lot more annoying than the documentation admits.
I was often thinking - just give me a pointer free of the borrow checker and the code would be a lot cleaner and easier to read.

[cl333r]

Anyway, am I the only one who finds the title of this article a bit perv?

[kaprikawn]

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.

+1

This isn't really a big issue...shock horror...a program has a bug! Big deal, they'll patch it and that will be that. Yes, Rust would have prevented this bug, but that's not necessarily a reason to rewrite Grub in Rust.

But that doesn't change the fact that Grub is a bloated mess. I frequent some sub reddits and it's evident that noobs almost always choose Grub when they've got a choice and don't ask for advice first. That's sad to see, but not surprising. Grub seems synonymous with Linux bootloaders despite being really bad. Going with rEFInd, systemd-boot or an EFI stub solution is almost always the better choice unless you've got some encryption setup that those don't support.