5 ms·

I'm shocked! Firmware vendors, the last bastion of high quality memory-safe C code, solving complex problems. Code firmly audited and formally verified to the

I'm shocked! 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 https://youtu.be/fE2KDzZaxvE

seemaze 3y ago
Thank you for that reference. As someone outside of tech, I still found Bryan Cantrill's presentation to thoroughly engaging and entertaining.
- kbenson 3y ago
  You'd enjoy most his talks, even if you don't understand the source material. They're half anecdotes and bashing Oracle in a very entertaining way.
pwdisswordfishc 3y ago
I fear your sarcasm may be a bit too subtle.
nine_k 3y ago
On topic: does the open-source Coreboot fare any better here? (I hope it does; the article does not mention it.)
- est31 3y ago
  coreboot just initializes the hardware, the logo is something that the payload displays: https://www.coreboot.org/Payloads https://www.coreboot.org/Payloads The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/ 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/2f0282922b2c458eea7f85c500a948a587437b63/common/splash_source.c#L4 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.
  - a1o 3y ago
    > 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.
    - zlg_codes 3y ago
      Yeah that stuck out to me, too. The fucking kernel is written in C. 90% or more of the networking stack is written in C. Graphics APIs are written in C. Compilers, databases, firmwares, older video games, everything. 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.
      - yencabulator 3y ago
        Lasers are so known for creating eye injuries they come with warning stickers. 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".
        zlg_codes 3y ago
        Except all programming languages can corrupt data. Even knives with sheaths can be misused to harm one's self. Are we gonna include warnings for SQL injection risk? This is a stupid premise.
- pgeorgi 3y ago
  coreboot has a rather fragile JPEG parser for splash screens but the saving grace is that barely anybody uses it because that's normally the payload's job (the jpeg + display thing was mostly added for a proof of concept "look how fast we can boot" demo in 2005) 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.
_ugfj 3y ago
C code? Nah, my friend, firmware is written in SPARK to achieve the highest possible quality. /s (and yes it should have been written in it, arduous it is, it's a "you had one job" situation)
gpderetta 3y ago
Firmware and BIOS vendors, world renown for the quality of their software.
- deleted 3y ago
  [deleted]
- dingnuts 3y ago
  genuine question: is this sarcasm? how dumb am i for not being able to tell?
  - jacquesm 3y ago
    Yes.
  - sonicanatidae 3y ago
    You're not dumb. You simply lack the specific body of knowledge and industry experience that provides the context for you to determine this. That's just life. :)
- _ea1k 3y ago
  Of course their software is the best. Some of these vendors are subject to regulatory, contractual legal requirements. That always produces the best software, unlike the "move fast, break things" people in other domains.
  - imoverclocked 3y ago
    I’ve been in the move fast and break things domain. Unsurprisingly, things are often broken there too.
    - _ea1k 3y ago
      I've yet to run into place where they aren't. But run fast, fix fast often works better than constant debate and red tape.
themaninthedark 3y ago
We need UEFI! With out it everything is ancient. And it needs to be updateable from the internet and the OS.
- forgetfreeman 3y ago
  Not sure if sarcasm...
- loxias 3y ago
  Yeah, and it should (somehow) involve javascript/wasm and Big YAML.
baz00 3y ago
As a former firmware developer I would like to point out that I lacked the competence and interest to have done a good enough job of it past getting paid at the end of the month.
- danparsonson 3y ago
  Well that's a relief - I was worried I'd never be good enough to get firmware dev job.
  - sonicanatidae 3y ago
    Do you breathe air? Are you capable of making noises, intelligible or not? Welcome aboard! I kid...or do I?
bcantrill 3y ago
Indeed -- and not coincidentally, this is why we don't have UEFI at all on the Oxide compute sled.[0] [0] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
- Voultapher 3y ago
  Hey, big fan of your work. Keep up the great work.
anitil 3y ago
My time in firmware has thoroughly broken my brain. All those things that we rely on to live our lives? I don't think people understand The Horrors that live within them

seemaze 3y ago

Thank you for that reference. As someone outside of tech, I still found Bryan Cantrill's presentation to thoroughly engaging and entertaining.

kbenson 3y ago
You'd enjoy most his talks, even if you don't understand the source material. They're half anecdotes and bashing Oracle in a very entertaining way.

pwdisswordfishc 3y ago

I fear your sarcasm may be a bit too subtle.

nine_k 3y ago

On topic: does the open-source Coreboot fare any better here? (I hope it does; the article does not mention it.)

est31 3y ago
coreboot just initializes the hardware, the logo is something that the payload displays: https://www.coreboot.org/Payloads https://www.coreboot.org/Payloads The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/ 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/2f0282922b2c458eea7f85c500a948a587437b63/common/splash_source.c#L4 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.
- a1o 3y ago
  > 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.
  - zlg_codes 3y ago
    Yeah that stuck out to me, too. The fucking kernel is written in C. 90% or more of the networking stack is written in C. Graphics APIs are written in C. Compilers, databases, firmwares, older video games, everything. 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.
    - yencabulator 3y ago
      Lasers are so known for creating eye injuries they come with warning stickers. 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".
      - zlg_codes 3y ago
        Except all programming languages can corrupt data. Even knives with sheaths can be misused to harm one's self. Are we gonna include warnings for SQL injection risk? This is a stupid premise.
pgeorgi 3y ago
coreboot has a rather fragile JPEG parser for splash screens but the saving grace is that barely anybody uses it because that's normally the payload's job (the jpeg + display thing was mostly added for a proof of concept "look how fast we can boot" demo in 2005) 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.

_ugfj 3y ago

C code? Nah, my friend, firmware is written in SPARK to achieve the highest possible quality. /s (and yes it should have been written in it, arduous it is, it's a "you had one job" situation)

gpderetta 3y ago

Firmware and BIOS vendors, world renown for the quality of their software.

deleted 3y ago
[deleted]
dingnuts 3y ago
genuine question: is this sarcasm? how dumb am i for not being able to tell?
- jacquesm 3y ago
  Yes.
- sonicanatidae 3y ago
  You're not dumb. You simply lack the specific body of knowledge and industry experience that provides the context for you to determine this. That's just life. :)
_ea1k 3y ago
Of course their software is the best. Some of these vendors are subject to regulatory, contractual legal requirements. That always produces the best software, unlike the "move fast, break things" people in other domains.
- imoverclocked 3y ago
  I’ve been in the move fast and break things domain. Unsurprisingly, things are often broken there too.
  - _ea1k 3y ago
    I've yet to run into place where they aren't. But run fast, fix fast often works better than constant debate and red tape.

themaninthedark 3y ago

We need UEFI! With out it everything is ancient. And it needs to be updateable from the internet and the OS.

forgetfreeman 3y ago
Not sure if sarcasm...
loxias 3y ago
Yeah, and it should (somehow) involve javascript/wasm and Big YAML.

baz00 3y ago

As a former firmware developer I would like to point out that I lacked the competence and interest to have done a good enough job of it past getting paid at the end of the month.

danparsonson 3y ago
Well that's a relief - I was worried I'd never be good enough to get firmware dev job.
- sonicanatidae 3y ago
  Do you breathe air? Are you capable of making noises, intelligible or not? Welcome aboard! I kid...or do I?

bcantrill 3y ago

Indeed -- and not coincidentally, this is why we don't have UEFI at all on the Oxide compute sled.[0] [0] https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/ https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...

Voultapher 3y ago
Hey, big fan of your work. Keep up the great work.

anitil 3y ago

My time in firmware has thoroughly broken my brain. All those things that we rely on to live our lives? I don't think people understand The Horrors that live within them