Originally posted by cl333r
View Post
BootHole Blows Hole In GRUB2 Bootloader Security, Including UEFI SecureBoot
Collapse
X
-
Originally posted by wswartzendruber View Post
That is antithesis to the core of the language.
Comment
-
-
Originally posted by cl333r View Post
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".
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
Comment
-
-
Originally posted by bug77 View Post
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
Comment
-
-
Guest
Originally posted by wswartzendruber View PostThis 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.
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.
Comment
-
Originally posted by cl333r View Post
No, it's a trade-off, and yes they sell meat at the vegan market, fake meat, fake milk, fake burgers.
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.
Comment
-
-
Guest
Originally posted by cl333r View Post
No, it's a trade-off, and yes they sell meat at the vegan market, fake meat, fake milk, fake burgers.
I'd rather eat tasty tofu chili stir fry and garlic beans.
Comment
-
Guest
Originally posted by stormcrow View PostAfter 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.
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.
Comment
-
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.
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..
Comment
-
Comment