11 ms·

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to

by titzer 5y ago

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long.

speed_spread 5y ago
At least Asbestos is inert once in place.
- masklinn 5y ago
  Isn’t asbestos always inert unless you matchmake it to a ridiculously strong oxidiser? In my recollection it dealt purely physical damage, and its inability to react with much of anything is what leads to its accumulation in dwellings.
  - afiori 5y ago
    I believe they mean inert as it relate to health, not chemically.
adrianN 5y ago
Unfortunately it's too much work to throw away all code written in unsafe languages. So it's valuable to try and improve tools and techniques that make these languages less unsafe.
- pjmlp 5y ago
  One reason why we are getting hardware memory tagging to transform modern computers into basically C Machines, is that everyone kind of gave up doing it at sofware level in regards to C and C++.
  - titzer 5y ago
    Just compile it all to Wasm and we'll run it in virtualization. Give us memory segments back and I think we have a shot of making this a reality.
    - pjmlp 5y ago
      Except WASM made the big mistake of not having bounds checking on linear memory, so attacks with input data that corrupt internal state and by it try to influence the outcome of WASM modules behaviour are still a good attack vector. Being sandboxed is good, however if one can start an internal fire from the outside, not so much.
      - titzer 5y ago
        Not sure what you were expecting, but no, Wasm doesn't magically make memory-unsafe languages internally uncorruptible, it limits all corruption to internal state. If you look at the PL research stretching back a couple decades on how to do that for C, you are looking at integer factor performance overheads in the general case. Wasm also doesn't make anything less safe than it was before (ok, ok, modulo the current lack of read-protected memory), and since we wisely chose to make the execution stack non-addressable, has CFI by default. Wasm's sandboxing makes it impossible to escalate the privilege of a program or acquire capabilities that it didn't have before (i.e. were not explicit imported and granted). That's a strictly stronger primitive than a random userspace Unix process.
        pjmlp 5y ago
        I was expecting that people don't oversell WebAssbemly as some kind of magic pixie dust of security, anyone that knows a bit about security spots those flaws. You know what is also sandboxed? An OS process. Ah, but an OS process has a wider syscalls surface, well lets than bring WASI or JavaScript bindings into the picture.
        titzer 5y ago
saurik 5y ago
More strongly: the idea that "fuzzing" is "doing all the right things" is insane and disappointing of a narrative. The code snippets I am seeing here are ridiculous with manual, flag-based error handling? There is a use of something like memcpy that isn't hidden behind some range abstraction that manages all of the bounds?! This code probably is riddled with bugs, because they are doing all the wrong things, and fuzzing the result counts for nothing. C++ sucks, but it is way better than this.
- ehsankia 5y ago
  I don't think anyone is under the illusion that "fuzzing is doing all the things" or that it is a replacement for actual unit, integration and E2E tests. It still is true that fuzzing has managed to find a whole slew of bugs that were otherwise not found, and it is generally easier to automate and add without requiring a ton of engineer time. It is meant to be an addition on top, not a replacement for other techniques.
- lrem 5y ago
  "All the right things" included, according to the actual narrative in the post: - Extensive non-fuzzing testing. - Regular static analysis. - Being actively maintained and overseen by a competent security team, with a bug bounty program on top. I believe I've also seen mentions of independent security audits outside the post. Edit: emphasis is on the fuzzing, because that is how the bug was finally discovered.
nineteen999 5y ago
No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task over 50 years to write this kind of software, organize standards bodies for their languages and platforms, get their software packaged as part of mainstream operating systems and out into the world, deal with patches from users, and help millions of other people make a living, enable the internet to happen, etc. We will wonder why with all the millions of lines of C/C++ reference code available to be perused and then rewritten in Rust, Pascal, C#, Zig or Nim, and the vociferousness of their advocates, why that didn't happen in a reasonable timeframe. We will wonder why all the Lisp and Haskell programmers who sneer down their nose at working C/C++ programmers in forums like this on a daily basis, didn't get off their asses with their One True Language (TM) and come to the worlds rescue. The answer will be: these people aren't doers - they are talkers. It's one thing to get a toy proof of concept OS in your favourite language of choice that supports like 5 drivers. It's another thing to contribute to and build an ecosystem depended on by millions of developers daily. C/C++ people may not always be the sharpest tools in the shed, and they may be a dime a dozen. But they know how to organize themselves in loose groups of more than just a few developers, and work with other people. We may have issues with the quality of what they ship on a frequent basis, but at least they ship instead of posting endless comments on internet forums about how it's all the others peoples fault.
- kovac 5y ago
  I like this man. I think the only thing we'll look back on is, considering how those who came before us delivered so much with so little (compute power, parallism, safety, tooling), how we fell so far from grace and fuck things right into the ground with slow, unsafe, useless piles of garbage that don't even perform their primary duties well other than collect data.
- FeepingCreature 5y ago
  I don't think this is fair. First-mover advantage is absolutely a thing at the ecosystem level.
lenkite 5y ago
Is it OK to remove modern C++ from your statement ? Using a `std::vector<std::byte>` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.
- raverbashing 5y ago
  > Using a `std::vector<std::byte>` And herein lies the problem. Your statement is correct. But that type definition is exactly why C++ feels like a 50's car retrofitted with an electric drivetrain and a DVD player on the dash It will almost run like a modern thing but it will fail when it shouldn't.
- sebcat 5y ago
  It wouldn't cause the problem in itself perhaps, but I find it a bit reductive to look at the type in isolation like that. Sometime, somewhere, someone will call std::vector<T,Allocator>::data on that vector and use the resulting pointer as the src argument to memcpy (or some other function), and someone else will make a change that causes an overflow of the dst buffer. Shit happens and code written in modern C++ also has bugs and some of those bugs have security implications.
  - Animats 5y ago
    Sometime, somewhere, someone will call ... I call this the mold seeping through the wallpaper. C++ tries to paper over C's terrible array model by using collection class templates, but those constructs leak. Too many things need raw pointers.
  - snovv_crash 5y ago
    You're just talking about more C interfaces, not C++. The same thing would happen in Rust if you tried to pass a chunk of memory to C.
    - pjmlp 5y ago
      True, except the code will be tainted and it is easy to find it.
Woodi 5y ago
> but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. Maybe. But there is good reason for C dominance - it's low level and close to systems as in "syscalls and stuff". And we need that level of systems control, not only for max performance but also for not loosing what is available in hw and os. Asm is the other option to have full functionality :) Maybe it's just case of available libraries but still C is curently only one option for feature completness. And on low levels all you have is bytes and bits and calls and that allows to do everything with bits, bytes and calls - Core Wars style - and most of languages try to prevent or easy use of that by cutting possibilities, eg. "goto is so nono !11". And yes, C is not perfect and bullshit even grows, eg. in last years NULL checks are "optimized-out"... C actually should be improved and not fucked up into forced disuse...
- oblio 5y ago
  > C actually should be improved and not fucked up into forced disuse... It can't, it won't, it isn't. The last major update has C99 and even that was minor from a security point of view. For better or worse, it's frozen.
- native_samples 5y ago
  C isn't dominant in a lot of areas of software, obviously. As for NSS. It's a pure data manipulation library. Algorithms, data structures, not more. It doesn't need to do syscalls and stuff. There's not much benefit to writing it in C and as we just saw, a lot of downsides. It could have been written in many other languages.
- pas 5y ago
  Memory is cheap. (But not free of course!) Scala, Kotlin, and Java exist. The HotSpot VM is amazing, its JIT is mindblowing. (Probaly even TS + V8 would do the job for high level stuff.) It's complete nonsense that C is needed for accessing the HW. High level languages can do low-level bibanging just fine. So yes, there's a good reason, but that is inertia. Literally too big to fail, so it keeps on living. Even if we tomorrow outlawed C, drafted people to start rewriting things in a memory-managed language, and so on, it would take decades to get rid of it.
pjmlp 5y ago
One of Bjarne's talks at CppCon 2021, is yet advocating again for the Code Guidelines, because they just keep being ignored by the community at large.
GoblinSlayer 5y ago
Ironically STL supports bound checking, but is always turned off.
gotbeans 5y ago
Imagine maintaining a long-term project in the first place. Such crazyness, like why?
wheelerof4te 5y ago
C ABI is still stable after all these years. Programs written in "The C Programming Language" bible still compile and work fine. That's why.

by titzer 5y ago

speed_spread 5y ago

At least Asbestos is inert once in place.

masklinn 5y ago
Isn’t asbestos always inert unless you matchmake it to a ridiculously strong oxidiser? In my recollection it dealt purely physical damage, and its inability to react with much of anything is what leads to its accumulation in dwellings.
- afiori 5y ago
  I believe they mean inert as it relate to health, not chemically.

adrianN 5y ago

Unfortunately it's too much work to throw away all code written in unsafe languages. So it's valuable to try and improve tools and techniques that make these languages less unsafe.

pjmlp 5y ago
One reason why we are getting hardware memory tagging to transform modern computers into basically C Machines, is that everyone kind of gave up doing it at sofware level in regards to C and C++.
- titzer 5y ago
  Just compile it all to Wasm and we'll run it in virtualization. Give us memory segments back and I think we have a shot of making this a reality.
  - pjmlp 5y ago
    Except WASM made the big mistake of not having bounds checking on linear memory, so attacks with input data that corrupt internal state and by it try to influence the outcome of WASM modules behaviour are still a good attack vector. Being sandboxed is good, however if one can start an internal fire from the outside, not so much.
    - titzer 5y ago
      Not sure what you were expecting, but no, Wasm doesn't magically make memory-unsafe languages internally uncorruptible, it limits all corruption to internal state. If you look at the PL research stretching back a couple decades on how to do that for C, you are looking at integer factor performance overheads in the general case. Wasm also doesn't make anything less safe than it was before (ok, ok, modulo the current lack of read-protected memory), and since we wisely chose to make the execution stack non-addressable, has CFI by default. Wasm's sandboxing makes it impossible to escalate the privilege of a program or acquire capabilities that it didn't have before (i.e. were not explicit imported and granted). That's a strictly stronger primitive than a random userspace Unix process.
      - pjmlp 5y ago
        I was expecting that people don't oversell WebAssbemly as some kind of magic pixie dust of security, anyone that knows a bit about security spots those flaws. You know what is also sandboxed? An OS process. Ah, but an OS process has a wider syscalls surface, well lets than bring WASI or JavaScript bindings into the picture.
        titzer 5y ago

saurik 5y ago

More strongly: the idea that "fuzzing" is "doing all the right things" is insane and disappointing of a narrative. The code snippets I am seeing here are ridiculous with manual, flag-based error handling? There is a use of something like memcpy that isn't hidden behind some range abstraction that manages all of the bounds?! This code probably is riddled with bugs, because they are doing all the wrong things, and fuzzing the result counts for nothing. C++ sucks, but it is way better than this.

ehsankia 5y ago
I don't think anyone is under the illusion that "fuzzing is doing all the things" or that it is a replacement for actual unit, integration and E2E tests. It still is true that fuzzing has managed to find a whole slew of bugs that were otherwise not found, and it is generally easier to automate and add without requiring a ton of engineer time. It is meant to be an addition on top, not a replacement for other techniques.
lrem 5y ago
"All the right things" included, according to the actual narrative in the post: - Extensive non-fuzzing testing. - Regular static analysis. - Being actively maintained and overseen by a competent security team, with a bug bounty program on top. I believe I've also seen mentions of independent security audits outside the post. Edit: emphasis is on the fuzzing, because that is how the bug was finally discovered.

nineteen999 5y ago

No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task over 50 years to write this kind of software, organize standards bodies for their languages and platforms, get their software packaged as part of mainstream operating systems and out into the world, deal with patches from users, and help millions of other people make a living, enable the internet to happen, etc. We will wonder why with all the millions of lines of C/C++ reference code available to be perused and then rewritten in Rust, Pascal, C#, Zig or Nim, and the vociferousness of their advocates, why that didn't happen in a reasonable timeframe. We will wonder why all the Lisp and Haskell programmers who sneer down their nose at working C/C++ programmers in forums like this on a daily basis, didn't get off their asses with their One True Language (TM) and come to the worlds rescue. The answer will be: these people aren't doers - they are talkers. It's one thing to get a toy proof of concept OS in your favourite language of choice that supports like 5 drivers. It's another thing to contribute to and build an ecosystem depended on by millions of developers daily. C/C++ people may not always be the sharpest tools in the shed, and they may be a dime a dozen. But they know how to organize themselves in loose groups of more than just a few developers, and work with other people. We may have issues with the quality of what they ship on a frequent basis, but at least they ship instead of posting endless comments on internet forums about how it's all the others peoples fault.

kovac 5y ago
I like this man. I think the only thing we'll look back on is, considering how those who came before us delivered so much with so little (compute power, parallism, safety, tooling), how we fell so far from grace and fuck things right into the ground with slow, unsafe, useless piles of garbage that don't even perform their primary duties well other than collect data.
FeepingCreature 5y ago
I don't think this is fair. First-mover advantage is absolutely a thing at the ecosystem level.

lenkite 5y ago

Is it OK to remove modern C++ from your statement ? Using a `std::vector<std::byte>` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.

raverbashing 5y ago
> Using a `std::vector<std::byte>` And herein lies the problem. Your statement is correct. But that type definition is exactly why C++ feels like a 50's car retrofitted with an electric drivetrain and a DVD player on the dash It will almost run like a modern thing but it will fail when it shouldn't.
sebcat 5y ago
It wouldn't cause the problem in itself perhaps, but I find it a bit reductive to look at the type in isolation like that. Sometime, somewhere, someone will call std::vector<T,Allocator>::data on that vector and use the resulting pointer as the src argument to memcpy (or some other function), and someone else will make a change that causes an overflow of the dst buffer. Shit happens and code written in modern C++ also has bugs and some of those bugs have security implications.
- Animats 5y ago
  Sometime, somewhere, someone will call ... I call this the mold seeping through the wallpaper. C++ tries to paper over C's terrible array model by using collection class templates, but those constructs leak. Too many things need raw pointers.
- snovv_crash 5y ago
  You're just talking about more C interfaces, not C++. The same thing would happen in Rust if you tried to pass a chunk of memory to C.
  - pjmlp 5y ago
    True, except the code will be tainted and it is easy to find it.

Woodi 5y ago

> but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. Maybe. But there is good reason for C dominance - it's low level and close to systems as in "syscalls and stuff". And we need that level of systems control, not only for max performance but also for not loosing what is available in hw and os. Asm is the other option to have full functionality :) Maybe it's just case of available libraries but still C is curently only one option for feature completness. And on low levels all you have is bytes and bits and calls and that allows to do everything with bits, bytes and calls - Core Wars style - and most of languages try to prevent or easy use of that by cutting possibilities, eg. "goto is so nono !11". And yes, C is not perfect and bullshit even grows, eg. in last years NULL checks are "optimized-out"... C actually should be improved and not fucked up into forced disuse...

oblio 5y ago
> C actually should be improved and not fucked up into forced disuse... It can't, it won't, it isn't. The last major update has C99 and even that was minor from a security point of view. For better or worse, it's frozen.
native_samples 5y ago
C isn't dominant in a lot of areas of software, obviously. As for NSS. It's a pure data manipulation library. Algorithms, data structures, not more. It doesn't need to do syscalls and stuff. There's not much benefit to writing it in C and as we just saw, a lot of downsides. It could have been written in many other languages.
pas 5y ago
Memory is cheap. (But not free of course!) Scala, Kotlin, and Java exist. The HotSpot VM is amazing, its JIT is mindblowing. (Probaly even TS + V8 would do the job for high level stuff.) It's complete nonsense that C is needed for accessing the HW. High level languages can do low-level bibanging just fine. So yes, there's a good reason, but that is inertia. Literally too big to fail, so it keeps on living. Even if we tomorrow outlawed C, drafted people to start rewriting things in a memory-managed language, and so on, it would take decades to get rid of it.

pjmlp 5y ago

One of Bjarne's talks at CppCon 2021, is yet advocating again for the Code Guidelines, because they just keep being ignored by the community at large.

GoblinSlayer 5y ago

Ironically STL supports bound checking, but is always turned off.

gotbeans 5y ago

Imagine maintaining a long-term project in the first place. Such crazyness, like why?

wheelerof4te 5y ago

C ABI is still stable after all these years. Programs written in "The C Programming Language" bible still compile and work fine. That's why.