"Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation" Fuck you
«While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot" Good, nobody wants that piece of garbage
@hfaust Of course they never name the GNU (there would be no mention of GNU if it wasn't for the 2 gnu.org URLs).
>extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2 Considering you cannot combine GPLv3-or-later with GPLv2-only, this doesn't seem correct.
They also write about "saving a weeks worth of time", but they've clearly wasted more than a weeks worth of time filing pointless CVEs (which are only useful if you want to embarrass a proprietary software developer into fixing bugs).
>The dangers of a GRUB2 >Since bootloaders run before operating systems run Of course it's sooo dangerous to run GRUB and GRUB isn't an OS.
If you want NX, ASLR, pointer authentication or stack cookies/canaries, it's simply a matter of enabling that in GCC or implementing it in the GRUB OS.
>Suggestion of completely junk integer overflow detection like; if (size + 1 < size) It looks convincing, but those sort of checks *do not work*.
Most of these can not exploited in practise and require physical access to the hardware.
Nobody cares and it's a literal nothing burger and only displays that "AI" can do baby's first C programming stuff.
You could've easily found these without Microsoft's Copilot garbage if people actually cared about fixing obscure bugs that never are a problem are in practise.
@SuperDicq@hfaust >to mitigate using (var + 1 < size). GCC's optimizer is so good it will detect that there's no way var + 1 will be smaller than var (signed integer overflow is undefined), therefore it optimizes out such check.
In the case where you have to add something to a variable from an input file that can be crafted by an attacker, you must use either use unsigned integers, or use __builtin_add_overflow() to avoid overflows.
@Suiseiseki@freesoftwareextremist.com@hfaust@shitposter.world The funniest line in this article is the following: Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation.I wonder which language Windows is mostly written with :thinkerman:
@hfaust Note how they fail to mention that "Secure Boot" and UEFI has made security much worse than BIOS, as it allows crafting a single bootkit in an image file that will work across architectures, as well everyone uses the same UEFI implementation with the same vulnerable jpeg library (while an attacker had to craft an attack per BIOS implementation at least).
@nachtrabe@hfaust Sure, but every motherboard manufacturer made quite a few changes to make their own custom versions, meaning a generic rootkit wasn't really possible.
Security nuts do not understand that when you run free software only, "memory safety" is an afterthought, most of us would rather stick with a truly free, matured, reliable and performant software written in C than adopt proprietary, slow and unreliable Rust codebase.
...GPLv3 is not proprietary. Ken's compiler is pure.
> worse functionally in every way
It's a nice compiler, it's comfortable, and it's a tool instead of some product of a committee of UB-Nazis trying to shove their opinion into your program. It is also fast, it produces good machine code, and cross-compilation is *trivial*.
@p@Suiseiseki@hfaust Plan 9: >compile quickly, load slowly, and produce medium quality object code.
gcc: >produce bad machine code until Apple pours millions into you >fragile codebase, a lot of tech debt >cross-compiling can be a pain depending on how esoteric your target is (literally anything that isn't a Linux host)
@p@Suiseiseki@hfaust Hey, I saw you passed --disable-shared to the autotools script. Therefore I'll dynamically link against the libc on your system, or if you are crosscompiling I'll link to the sysroot libc with headers I broke during the fix-includes target.
@eliseo01 That's why I don't trust when people push for a Rust rewrite, every time they do, you find a piece of software licensed in MIT just they will be able to close it later.