Firmware vendors, the last bastion of high quality memory-safe C code, solving complex problems. Code firmly audited and formally verified to the highest degree. And now you tell me these people, with the highest known software quality got "parsing image formats" wrong?
It's truly zebras all the way down https://youtu.be/fE2KDzZaxvE
[0] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
Showing your age there, pal. And yes, the '90s were awesome.
That always produces the best software, unlike the "move fast, break things" people in other domains.
You have a valid point about red tape, but does it really amount to 2 steps forward, or is it the same one step, but 2 forward, 1 back?
I work in environments where moving fast is usually bad (Enterprise/Healthcare), so I'm honestly asking.
Knowing where you want to go and keeping your focus on that direction is probably the most important aspect of any environment. Iterating fast is a double edged sword that both allows quick fixes to happen while also encouraging an environment where those quick fixes are needed.
Iterating more meticulously feels a lot slower but can produce just as fast… sometimes a lot faster. For me, there is also an inherent stability component to slower iteration.
Perhaps, the best is neither approach on their own but a clever combination of the two?
I work in Healthcare, so the needs are a little different.
I'm glad I work in the field I do. I'm not sure my personality lends itself to move fast and break shit.
Like all things, YMMV. :)
Thanks for answering my question.
That's just life. :)
Welcome aboard!
I kid...or do I?
The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/
u-boot supports specifying splash screens via "splashfile", but it seems only bmp and maybe some raw image format are supported: https://github.com/u-boot/u-boot/blob/2f0282922b2c458eea7f85...
In other words, no support for png, which this exploit uses :). That doesn't mean that coreboot/u-boot aren't written in C though which is a language known for its vulnerabilities.
C is not known for its vulnerabilities, it's known for being fast, portable, and low on abstractions. It's a perfect fine language to write this kind of code. There are techniques like fuzzing and using things like valgrind that can catch invalid input and memory issues quite quickly.
C is not known for vulnerabilities, it simply makes it easy to shoot yourself in the foot. The tooling exists to improve code safety, but generally if you don't do anything crazy, nothing crazy happens.
Lasers, chainsaws and pressure washers are all easy to hurt one's self with but I wouldn't say they're known for creating injuries. It's more like people are stupid enough to hurt themselves with tools regularly.
It's not hard to check a value before dereferencing or freeing it. It's hard to remember to do it.
Chainsaws are so known for accidents they come with warning pamphlets instructing you in how to use them in ways that minimize the risk -- including recommendations for wearing reinforced chaps to protect your legs.
So, following your comparison, it should be perfectly valid to apply a warning sticker to C that says "Warning: Known to state of California to cause data corruption and accidental code execution".
Are we gonna include warnings for SQL injection risk? This is a stupid premise.
No, we've moved to calling conventions that avoid SQL injections: bind params. That argument speaks for minimizing use of C, not in its defense.
It's okay to admit you don't like a programming language.
I'm anticipating the time when Rust and Zig will displace C as the default language for writing hardware-interfacing code. It's not going to happen tomorrow, though.
With payloads, some are more at risk than others. edk2 might run into issues here, grub2 has tons of features where stuff like this might hide in, other payloads (e.g. ChromeOS' depthcharge) are more limited in their functionality and therefore in their attack surface, too.
(and yes it should have been written in it, arduous it is, it's a "you had one job" situation)