3 ms·

The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into t

by Verdex 3y ago

The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.

kimixa 3y ago
that's what I meant by: > better way than "Crash" or worse - silent corruption My point is that the current crop of c++ compilers and standard library implementations have the ability to check for the vast majority of these issues, just they're relegated to non-default "debug" options. Just flipping that, so you had some level of checking on by default and you had to explicitly ask for "Go fast and break things" mode would help - as it feels like the vast majority of native code doesn't need to get that last few percent. And even that is questionable, I remember doing some (micro-)benchmarks on simple stuff like array bounds checking and the performance difference on modern big CPUs was pretty much within noise. Maybe it's a big deal on microcontrollers or small embedded systems, but that's the "I Know What I'm Doing" non-default mode is for.
- Verdex 3y ago
  > better way than "Crash" or worse - silent corruption My apologies, I could have sworn that your text was 'better way than "Crash" <end>'. And not in fact, 'better way than "Crash" or worse - silent corruption'. Although, silent corruption is a possible problem in memory safe languages. True, memory safety gives you some sort of protections, but threads and/or setting the wrong value can still give a memory safe corruption. No, I was talking about the ability for an attacker to craft malicious input such that a memory unsafe program begins executing that input as if it were the program. Something that you generally do not have to worry about in a memory safe language.
  - kimixa 3y ago
    I think I edited it within seconds of posting, it was just "Or worse" IIRC, and noticed I'd missed it when rewording it just before posting. I guess you were lucky enough to see it immediately :P It's a bad habit of mine to post then re-read with fresher eyes and notice problems in my comments - exactly like this clarification. Security of technology is really a process, not a boolean. "Memory Safe" doesn't mean "Safe", and "Not the current crop of Memory Safe" languages doesn't mean "Unsafe". There's so much we can do with the tools we have right now to help with current codebases and apps, too many people seem to have the idea you have to do a ground up rewrite using the latest and greatest language, or you're an idiot and/or lazy. Honestly, the whole world isn't going to be rewritten in rust tomorrow, imagine the time and effort that would take and all the other errors a ground-up rewrite of well-tested systems would cause. But we can probably rebuild 90% of the existing world in a "Safer" manner right now. We should be promoting that too, and not let perfection be the enemy of better.
    - Verdex 3y ago
      > Security of technology is really a process > But we can probably rebuild 90% of the existing world in a "Safer" manner right no I strongly agree with this mindset. The only caveat I would offer is that some architectural structures that c and c++ allow probably don't amend themselves to fixing even if you can detect them. Although just like you can write any language horribly, I think you can write almost any language well. It's hard to see how tools that allow you to do that can be a bad thing. I'm certainly not going to be paying to rewrite everything from the ground up in rust or otherwise.

by Verdex 3y ago

The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.

kimixa 3y ago

that's what I meant by: > better way than "Crash" or worse - silent corruption My point is that the current crop of c++ compilers and standard library implementations have the ability to check for the vast majority of these issues, just they're relegated to non-default "debug" options. Just flipping that, so you had some level of checking on by default and you had to explicitly ask for "Go fast and break things" mode would help - as it feels like the vast majority of native code doesn't need to get that last few percent. And even that is questionable, I remember doing some (micro-)benchmarks on simple stuff like array bounds checking and the performance difference on modern big CPUs was pretty much within noise. Maybe it's a big deal on microcontrollers or small embedded systems, but that's the "I Know What I'm Doing" non-default mode is for.

Verdex 3y ago
> better way than "Crash" or worse - silent corruption My apologies, I could have sworn that your text was 'better way than "Crash" <end>'. And not in fact, 'better way than "Crash" or worse - silent corruption'. Although, silent corruption is a possible problem in memory safe languages. True, memory safety gives you some sort of protections, but threads and/or setting the wrong value can still give a memory safe corruption. No, I was talking about the ability for an attacker to craft malicious input such that a memory unsafe program begins executing that input as if it were the program. Something that you generally do not have to worry about in a memory safe language.
- kimixa 3y ago
  I think I edited it within seconds of posting, it was just "Or worse" IIRC, and noticed I'd missed it when rewording it just before posting. I guess you were lucky enough to see it immediately :P It's a bad habit of mine to post then re-read with fresher eyes and notice problems in my comments - exactly like this clarification. Security of technology is really a process, not a boolean. "Memory Safe" doesn't mean "Safe", and "Not the current crop of Memory Safe" languages doesn't mean "Unsafe". There's so much we can do with the tools we have right now to help with current codebases and apps, too many people seem to have the idea you have to do a ground up rewrite using the latest and greatest language, or you're an idiot and/or lazy. Honestly, the whole world isn't going to be rewritten in rust tomorrow, imagine the time and effort that would take and all the other errors a ground-up rewrite of well-tested systems would cause. But we can probably rebuild 90% of the existing world in a "Safer" manner right now. We should be promoting that too, and not let perfection be the enemy of better.
  - Verdex 3y ago
    > Security of technology is really a process > But we can probably rebuild 90% of the existing world in a "Safer" manner right no I strongly agree with this mindset. The only caveat I would offer is that some architectural structures that c and c++ allow probably don't amend themselves to fixing even if you can detect them. Although just like you can write any language horribly, I think you can write almost any language well. It's hard to see how tools that allow you to do that can be a bad thing. I'm certainly not going to be paying to rewrite everything from the ground up in rust or otherwise.