BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[wswartzendruber]

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.

That is antithesis to the core of the language.

[cl333r]

That is antithesis to the core of the language.

Exactly, which is why I said it's a trade-off, which means it solves one problem at the expense of another. And this means that sometimes it's far easier to just have a pointer and call delete on it when needed without having the borrow checker up your ass. And nothing in Rust allows you this, not even "unsafe".

[bug77]

Exactly, which is why I said it's a trade-off, which means it solves one problem at the expense of another. And this means that sometimes it's far easier to just have a pointer and call delete on it when needed without having the borrow checker up your ass. And nothing in Rust allows you this, not even "unsafe".

They also don't sell meat in a vegan market. That's not a trade-off, it's the only way of doing some things.
You want safety? Someone has to enforce it. Can't be done with raw pointers lying around anymore than you can cook a veggie meal with only bits of meat in it

[lucrus]

The name "BootHole" is priceless.

[cl333r]

They also don't sell meat in a vegan market. That's not a trade-off, it's the only way of doing some things.
You want safety? Someone has to enforce it. Can't be done with raw pointers lying around anymore than you can cook a veggie meal with only bits of meat in it

No, it's a trade-off, and yes they sell meat at the vegan market, fake meat, fake milk, fake burgers.

[Guest]

This right here is why some of us are crying out for things to be made in Rust. Is it perfect? Hell no! It shows signs of being maintained by drug addicts. But it is an improvement over C for security, however.

True. That Heartbleed vulnerability was cringy, and pretty much due to how strings are normally handled in C. You either need to know the character length in advance, or have a null terminator. And the developer directly translated that into communicating over the network. If they'd just used XML or JSON instead of raw character bytes, they wouldn't need the other side to tell them how long the string actually is.

Ok yes to be fair not a C language problem, but more the mentality you develop when programming in C. The object oriented train arrived 20-30 years ago, and some people are still too scared and stubborn to get on it.

[skeevy420]

No, it's a trade-off, and yes they sell meat at the vegan market, fake meat, fake milk, fake burgers.

Does that mean I engaged in sex trafficking when I bought my RealDoll? Will I be going to jail for keeping a fake woman in the basement?

Will my family disown me if I substitute turkey with tofurky on Thanksgiving? Or will the RealDoll do that for me?

But this is really a non-issue. If someone has access to a system's grub.cfg, that system has bigger problems than GRUB having a bug.

[Guest]

No, it's a trade-off, and yes they sell meat at the vegan market, fake meat, fake milk, fake burgers.

That's for all of the meat eaters. It's annoying that no matter which market you go to, it always caters towards meat eaters. This vegan meat stuff tastes like crap even to a vegetarian like me. Just drop this fake meat crap, and serve people normal vegan food. If they whine about wanting meat taste like immature people, they can go starve themselves or go hog on meat as usual.

I'd rather eat tasty tofu chili stir fry and garlic beans.

[Guest]

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.

Exactly! The people reporting this vulnerability make it out to be some huge problem. I mean, it kind of is, but only if the attacker gains root access, modifies the boot.cfg file, and then the system is rebooted without checking the grub.cfg file...........I fail to see how it's a huge practical concern.

Obviously whatever parsing bug it is should be fixed, but practically, if the attacker has that much access, they can already steal existing data, and install a lot of other malware besides.......and it doesn't survive OS reinstallation like they claim it does. It doesn't change UEFI in any way, it merely takes advantage of GRUB to boot whatever at the beginning.

[tuxd3v]

Unfortunately, the flex code has been written with the expectation that any calls to YY_FATAL_ERROR() will never return. This results in yy_flex_strncpy() being called and copying the source string from the configuration file into a buffer that is too small to contain it.

Why is YY_FATAL_ERROR() helper function returning in a ERROR situation??

Anyway,
If the parser detected that a string is too big to be loaded( and it indeed detect that.. ), even if it calls YY_FATAL_ERROR(), it shouldn't proceed.. since it knows, in advance, that it cannot hold the string..