BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot

[cl333r]

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.

I know, I agree, I've been vegetarian for 10 years (one of the most pointless decisions I ever made), but I understand this - the people among vegans (and any other group for that matter) vary a lot mentally and physically, some need it, some think it will help convert other people.

[Guest]

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..

Well you see, C doesn't have the concept of exceptions. You have to return error codes and have the calling code exit by calling exit() function or something.

[tuxd3v]

It doesn't change UEFI in any way, it merely takes advantage of GRUB to boot whatever at the beginning.

Well, even with EFI, grub will load that file, so it indeed is affected by that..

I understand that the grub.cfg is something configurable,
And being configurable means that it would take the user to sign it every time that the user changes it( which in a majority of cases is impossible.. )..
EFI implementation should enforce that, but it doesn't happen..

With the sole exception of one bootable tool vendor who added custom code to perform a signature verification of the grub.cfg config file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable.

[Guest]

Well, even with EFI, grub will load that file, so it indeed is affected by that..

I understand that the grub.cfg is something configurable,
And being configurable means that it would take the user to sign it every time that the user changes it( which in a majority of cases is impossible.. )..
EFI implementation should enforce that, but it doesn't happen..

Sure.......I'm just saying that it's not THAT bad. It can be bad, but only if the attacker already has root access, and then they can access everything.

And it can't actually survive an OS reinstallation, not unless they mean the special case where you decide to reinstall but leave your existing GRUB executable and grub.cfg intact. I can see people doing that, but most people are just going to do the normal install route which will delete and recreate all partitions.

it also definitely doesn't require revocation of keys and all of that bullshit, it merely requires re-creating grub.cfg and signing it, or if you want to be extra sure, reinstall the OS from a secure install disk. Which is only if some malware was able to run as root and then attempted some attack like this.

Yes it's a security vulnerability, just not as big a deal as they're claiming it is.

[polarathene]

Cocaine, specifically. The language moves fast, but not necessarily with attention to detail.

I don't really agree. Some features cook for years, take GAT (Generic Associated Types) for example.. I think similar case with const generics. Hardly fast or rushed for those.

without having the borrow checker up your ass. And nothing in Rust allows you this, not even "unsafe".

I would have thought unsafe keyword would have been the escape hatch for that, ah well. I have heard of mrustc which apparently lacks borrow checker support, so technically, you'd get it working there I guess? Bit of a bigger tradeoff though.

[Guest]

Ok so apparently even if you have your grub.cfg in an encrypted partition, GRUB will happily use any grub.cfg that's on the same partition it's loaded from. So anyone can drop a modified grub.cfg file into your unencrypted ESP and GRUB will just use that. Facepalm. (Got this info from Matthew Garrett).

[skeevy420]

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.

I've never really cared for any of the fake meat products and I've always gotten this feeling like someone is trying to insult my intelligence when they feed that stuff to me, like they're trying to trick me into thinking I'm eating a generic hot dog and not a tofu dog.

Throw some zucchini in the convection oven, make some green bean casserole, grill up some corn, but don't give me the fake, nasty versions of stuff I like.

Don't get me wrong, I totally get where cl333r is coming from and see that point of view, but as a primarily meat eating person I'd rather a vegan make me a good tasting vegan dish over serving me faux meat. Either situation, the worst case scenario is I'll go hungry for an extra hour and swing by a fast food joint afterwards so I'd rather you do you versus an attempt to please me with stuff I know I don't like to begin with.

[tuxd3v]

it also definitely doesn't require revocation of keys and all of that bullshit, it merely requires re-creating grub.cfg and signing it, or if you want to be extra sure, reinstall the OS from a secure install disk. Which is only if some malware was able to run as root and then attempted some attack like this.

Yes it's a security vulnerability, just not as big a deal as they're claiming it is.

It will require,
Or the helper functions or the parser flex/Bison DSL code, need to change, and so they need to revoke the earlier keys, and sign it again( the new version )..
This for EFI, of course..
basically they need to add the previous keys to the dbx database( disallow database )
remove the previous keys from the db( Allow Database )
Sign the new software versions, and put the key in db( Allow Database )

The signing of grub.cfg, is yet a problem to solve.. like I quoted above, almost no one is verifying the grub.cfg keys..
The default parser code seems that, doesn't do that..

yes, root will be needed, or you could just boot with other OS that has filesystem support, and infect the mounted partition from that..
Or yet, if you have access to the machine( which this attack almost suggests..), you can just boot to the initramfs, and mount the /boot partition and voilá

This is a crazy "Christmas attack" to do on your friends computer, one that you don't like much..or by some reason you want revenge for something
They will fume over it

[ssokolow]

What drove the sense of urgency?

It's been a while, so I may be misremembering but, from what I remember, it was basically a case of "We could work on this for another ten years and find things we think we can improve. We think it's close enough to lay out a forward-compatible Minimum Viable Product now, so let's set a deadline and stabilize" which prompted people to start looking more closely than they had been before, prompting a crunch-time scenario.

I would have thought unsafe keyword would have been the escape hatch for that, ah well. I have heard of mrustc which apparently lacks borrow checker support, so technically, you'd get it working there I guess? Bit of a bigger tradeoff though.

unsafe allows five things that you can't do in safe Rust:

• Dereferencing raw pointers
• Calling unsafe functions (including doing FFI)
• Implementing unsafe traits
• Mutating statics (The safe way is to use something like Mutex<T> which provides "interior mutability" from an immutable reference.)
• Accessing fields of unions (enum being a tagged union if any of its variants contain data fields and union being the untagged version for C FFI)

Even with unsafe, standard Rust references still get tagged as noalias in the LLVM IR, which means that it's still Undefined Behaviour (example) if you use unsafe to forcibly synthesize multiple &mut for the same memory at the same time by typecasting through a raw pointer.

See this page for more information.

I expect mrustc would probably also apply equivalent annotations when transpiling Rust, since its primary purpose is to re-bootstrap the Rust toolchain to prove it free of trusting trust attacks.

[tuxd3v]

You have to return error codes and have the calling code exit by calling exit() function or something.

If you know in advance that something cannot happen, you need to exit()..
exactly, that should be the default behaviour