4 ms·

So there's a C program. There's a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. And they w

So there's a C program. There's a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. And they write code with memory safety bugs. They are eventually forced to transition to a new language, which makes the memory safety bugs moot. Without addressing the fact that they're still sub-par, or why they were to begin with, why they didn't use the memory safe functions, why we let them ship code to begin with. They go on to make more sub-par code, with more avoidable security errors. They're just not memory safety related anymore. And the hackers shift their focus to attack a different way. Meanwhile, nobody talks about the pink elephant in the room. That we were, and still are, completely fine with people writing code that is shitty. That we allow people to continuously use the wrong methods, which lead to completely avoidable security holes. Security holes like the injection attacks, which make up 40% of all CVEs now, when memory safety only makes up 25%. Could we have focused on a default solution for the bigger class of security holes? Yes. Did we? No. Why? Because none of this is about security. Programmers just like new toys to play with. Security is a red herring being used to justify the continuation of allowing people to write shitty code, and play with new toys. Security will continue to be bad, because we are not addressing the way we write software. Rather than this one big class of bugs, we will just have the million smaller ones to deal with. And it'll actually get harder to deal with it all, because we won't have the "memory safety" bogey man to point at anymore.

tptacek 2y ago
No, this just isn't how it works. You'll find business logic, domain-specific, and systems programming security errors on every platform, but you don't find them with the density and the automatic severity you do memory safety issues. This is not about "language hipsters".
- 0xbadcafebee 2y ago
  If the impetus behind moving to new languages was primarily focused on improving security, we could have first attempted to address the underlying cause of programming security issues. The underlying cause is not "it's hard to check buffer boundaries". If you don't believe me, do a 5 Whys on the average buffer overflow, and tell me the best solution is still a new language.
  - tptacek 2y ago
    "It's hard to check buffer boundaries" is memory corruption circa 1998.
  - steveklabnik 2y ago
    > we could have first attempted to address the underlying cause of programming security issues. A lot of the recent moves here are motivated by multiple large industry players noticing a correlation between security issues and memory-unsafe language usage. "70% of security vulnerabilities are due to memory unsafety" is a motivating reason to move towards memory safe languages. What do you believe the underlying cause to be?
    - 0xbadcafebee 2y ago
      Security bugs are just a quality defect. Quality defects have many causes, but they all roll up to three root causes: 1) lack of a process to ensure quality, 2) a process which does not address the defect, and 3) inability to follow the process. If there is no process to eliminate the defects, then they will always appear. Based on my knowledge and experience of this kind of software development, I have noticed that a majority of the time, there is no process applied to the development which would eliminate these defects. We just expect, or hope, that the developers are smart enough and rigorous enough to do it by themselves without anyone asking. Well, in the real world, you can't just hope for quality. The results speak for themselves. Even when there is a process applied to eliminate the defect, it is often not effective. Either the process doesn't go far enough (many still don't even use Valgrind), or the people applying the process either don't follow it, or not well enough. Many in the industry have decided that the solution to these defect issues is to use a new system [programming language] which avoids the need for the process to begin with. That's not a bad idea in principle. But they've only done that for a single class of quality defect. The rest of the security bugs, and every other kind of defect imaginable, is still there. And new ones will appear over time. So rather than play whack-a-mole very slowly designing brand new systems to eliminate one single class of defect at a time, my proposal is we change the way we do development fundamentally. Regardless of the system in use, we should be able to define processes, ensure they are applied correctly, and continuously improve them, to eliminate quality defects. This would not only solve security issues, but all kinds of bugs. If this method was standard practice (and mandatory), the Crowdstrike issue never would have happened, because they would have been required to be looking for quality defects and eliminating them.
uid65534 2y ago
Having the tool actively prevent classes of errors is a worthwhile endeavor, but I do agree it gets overly focused on alone when several other _massive_ classes of vulnerabilities continue to be introduced. At a high level though, it is a lot easier to just have a framework enforce 'x' on all devs to raise the minimum bar. It doesn't help that the average Rust-bro, from which a lot of these memory safety arguments come from, is utterly terrible at making that case in reality. Case example: https://github.com/pyca/cryptography/issues/5771 https://github.com/pyca/cryptography/issues/5771. I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features. Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.
- alpire 2y ago
  > its trivial to write memory safe C++ It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects. Some of the reasons include: - C++ does little to prevent out-of-bounds vulns - Preventing use-after-free with smart pointers requires heavy use of shared pointers, which often incurs a performance cost that is unacceptable in the environment C++ is used.
  - Dylan16807 2y ago
    > It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects. I don't think that's really a rebuttal to what they're trying to say. If the vast majority of C++ devs don't follow those two rules, then that's not much evidence against those two rules providing memory safety.
    - adgjlsfhk1 2y ago
      Right but the reason they don't follow those 2 rules is that using them would require not using most C++ libraries that don't follow the rules, and would introduce performance regressions that negate the main reason they chose C++ in the first place.
jnwatson 2y ago
It is 100-1000 times harder to find application-level security bugs than it is to find memory safety bugs. It is also far easier to apply formal analysis to code if you don't have to model arbitrary pointers. Android has hard evidence that just eliminating memory safety makes a significant difference.
bcoates 2y ago
I mostly agree with you but take the opposite position: attacking memory safety bugs has been so successful that we should use the same pattern on other large classes of bugs. It's absolutely possible to write a reasonably usable language that makes injection/escaping/pollution/datatype confusion errors nearly impossible, but it would involve language support and rewriting most libraries--just like memory safety did. Unfortunately we are moving in the opposite direction (I'm still angry about javascript backticks, a feature seemingly designed solely to allow the porting of php-style sql injection errors)
- 0xbadcafebee 2y ago
  Take that to its logical end: a language designed with high-level functions to automate all possible work that, if left to a human to craft, would expose security vulnerabilities. You know what you have there? A new method for developing software. If we just switch languages every time we have another class of vuln that we want to eliminate, it will take us 1,000 years to get them all. Or we could just get them all today by fundamentally rethinking how we write software. The problem isn't software. The problem is humans writing software. There are bugs because we are using a highly fallible process to create software. If we want to eliminate the bugs, we have to change how the software is created.
alpire 2y ago
> You have a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. They write code with memory safety bugs. We should really stop putting the blame on developers. The issue is not that developers are sub-par, but that they are provided with tools making it virtually impossible to write secure software. Everyone writes memory safety bugs when using memory-unsafe languages. And one helpful insight here is that the security posture of a software application is substantially an emergent property of the developer ecosystem that produced it, and that includes having secure-by-design APIs and languages. https://queue.acm.org/detail.cfm?id=3648601 https://queue.acm.org/detail.cfm?id=3648601 goes into more details on this.
pornel 2y ago
People have a finite amount of time and effort they can spend on making the code correct. When the language is full of traps, spec gotchas, antiquated misfeatures, gratuitous platform differences, fragmented build systems, then a lot of effort is wasted just on managing all of that nonsense that is actively working against writing robust code, and it takes away from the effort to make a quality product beyond just the language-wrangling. You can't rely on people being perfect all the time. We've been trying that for 50 years, and only got an endless circle of CVEs and calls to find better programmers next time. The difference is how the language reacts to the mistakes that will happen. It could react with "oops, you've made a mistake! Here, fix this", and let the programmer apply a fix and move on, shipping code without the bug. Or the language could silently amplify smallest mistakes in the least interesting code into corruption that causes catastrophic security failures. When concatenating strings and adding numbers securely is a thing that exists, and a thing that requires top-skilled programmers, you're just wasting people's talent on dumb things.
deleted 2y ago
[deleted]
uecker 2y ago
I think it is somewhat about security. The "Nobody can write secure C/C++ code" nonsense translates to "We are not at fault that are products are broken garbage, because it is simply impossible to write secure code." Now we can pretend to fix "a whole class of errors" (as long as there is no "unsafe" anywhere) by imposing Rust on programmers (and the open-source community that then will produce memory safe code for free for some to use) and while this may indeed help a bit, one can hope to avoid being really being held responsible for product security for another decade or so.
saagarjha 2y ago
> There's a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. …which are?
pjc50 2y ago
> old, well documented, stable, memory-safe functions and techniques. I'm sorry, are we still talking about C here? Where the old functions are the ones that are explicitly labelled as too dangerous to use, like strcmp()?

tptacek 2y ago

No, this just isn't how it works. You'll find business logic, domain-specific, and systems programming security errors on every platform, but you don't find them with the density and the automatic severity you do memory safety issues. This is not about "language hipsters".

0xbadcafebee 2y ago
If the impetus behind moving to new languages was primarily focused on improving security, we could have first attempted to address the underlying cause of programming security issues. The underlying cause is not "it's hard to check buffer boundaries". If you don't believe me, do a 5 Whys on the average buffer overflow, and tell me the best solution is still a new language.
- tptacek 2y ago
  "It's hard to check buffer boundaries" is memory corruption circa 1998.
- steveklabnik 2y ago
  > we could have first attempted to address the underlying cause of programming security issues. A lot of the recent moves here are motivated by multiple large industry players noticing a correlation between security issues and memory-unsafe language usage. "70% of security vulnerabilities are due to memory unsafety" is a motivating reason to move towards memory safe languages. What do you believe the underlying cause to be?
  - 0xbadcafebee 2y ago
    Security bugs are just a quality defect. Quality defects have many causes, but they all roll up to three root causes: 1) lack of a process to ensure quality, 2) a process which does not address the defect, and 3) inability to follow the process. If there is no process to eliminate the defects, then they will always appear. Based on my knowledge and experience of this kind of software development, I have noticed that a majority of the time, there is no process applied to the development which would eliminate these defects. We just expect, or hope, that the developers are smart enough and rigorous enough to do it by themselves without anyone asking. Well, in the real world, you can't just hope for quality. The results speak for themselves. Even when there is a process applied to eliminate the defect, it is often not effective. Either the process doesn't go far enough (many still don't even use Valgrind), or the people applying the process either don't follow it, or not well enough. Many in the industry have decided that the solution to these defect issues is to use a new system [programming language] which avoids the need for the process to begin with. That's not a bad idea in principle. But they've only done that for a single class of quality defect. The rest of the security bugs, and every other kind of defect imaginable, is still there. And new ones will appear over time. So rather than play whack-a-mole very slowly designing brand new systems to eliminate one single class of defect at a time, my proposal is we change the way we do development fundamentally. Regardless of the system in use, we should be able to define processes, ensure they are applied correctly, and continuously improve them, to eliminate quality defects. This would not only solve security issues, but all kinds of bugs. If this method was standard practice (and mandatory), the Crowdstrike issue never would have happened, because they would have been required to be looking for quality defects and eliminating them.

uid65534 2y ago

Having the tool actively prevent classes of errors is a worthwhile endeavor, but I do agree it gets overly focused on alone when several other _massive_ classes of vulnerabilities continue to be introduced. At a high level though, it is a lot easier to just have a framework enforce 'x' on all devs to raise the minimum bar. It doesn't help that the average Rust-bro, from which a lot of these memory safety arguments come from, is utterly terrible at making that case in reality. Case example: https://github.com/pyca/cryptography/issues/5771 https://github.com/pyca/cryptography/issues/5771. I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features. Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.

alpire 2y ago
> its trivial to write memory safe C++ It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects. Some of the reasons include: - C++ does little to prevent out-of-bounds vulns - Preventing use-after-free with smart pointers requires heavy use of shared pointers, which often incurs a performance cost that is unacceptable in the environment C++ is used.
- Dylan16807 2y ago
  > It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects. I don't think that's really a rebuttal to what they're trying to say. If the vast majority of C++ devs don't follow those two rules, then that's not much evidence against those two rules providing memory safety.
  - adgjlsfhk1 2y ago
    Right but the reason they don't follow those 2 rules is that using them would require not using most C++ libraries that don't follow the rules, and would introduce performance regressions that negate the main reason they chose C++ in the first place.

jnwatson 2y ago

It is 100-1000 times harder to find application-level security bugs than it is to find memory safety bugs. It is also far easier to apply formal analysis to code if you don't have to model arbitrary pointers. Android has hard evidence that just eliminating memory safety makes a significant difference.

bcoates 2y ago

I mostly agree with you but take the opposite position: attacking memory safety bugs has been so successful that we should use the same pattern on other large classes of bugs. It's absolutely possible to write a reasonably usable language that makes injection/escaping/pollution/datatype confusion errors nearly impossible, but it would involve language support and rewriting most libraries--just like memory safety did. Unfortunately we are moving in the opposite direction (I'm still angry about javascript backticks, a feature seemingly designed solely to allow the porting of php-style sql injection errors)

0xbadcafebee 2y ago
Take that to its logical end: a language designed with high-level functions to automate all possible work that, if left to a human to craft, would expose security vulnerabilities. You know what you have there? A new method for developing software. If we just switch languages every time we have another class of vuln that we want to eliminate, it will take us 1,000 years to get them all. Or we could just get them all today by fundamentally rethinking how we write software. The problem isn't software. The problem is humans writing software. There are bugs because we are using a highly fallible process to create software. If we want to eliminate the bugs, we have to change how the software is created.

alpire 2y ago

> You have a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. They write code with memory safety bugs. We should really stop putting the blame on developers. The issue is not that developers are sub-par, but that they are provided with tools making it virtually impossible to write secure software. Everyone writes memory safety bugs when using memory-unsafe languages. And one helpful insight here is that the security posture of a software application is substantially an emergent property of the developer ecosystem that produced it, and that includes having secure-by-design APIs and languages. https://queue.acm.org/detail.cfm?id=3648601 https://queue.acm.org/detail.cfm?id=3648601 goes into more details on this.

pornel 2y ago

People have a finite amount of time and effort they can spend on making the code correct. When the language is full of traps, spec gotchas, antiquated misfeatures, gratuitous platform differences, fragmented build systems, then a lot of effort is wasted just on managing all of that nonsense that is actively working against writing robust code, and it takes away from the effort to make a quality product beyond just the language-wrangling. You can't rely on people being perfect all the time. We've been trying that for 50 years, and only got an endless circle of CVEs and calls to find better programmers next time. The difference is how the language reacts to the mistakes that will happen. It could react with "oops, you've made a mistake! Here, fix this", and let the programmer apply a fix and move on, shipping code without the bug. Or the language could silently amplify smallest mistakes in the least interesting code into corruption that causes catastrophic security failures. When concatenating strings and adding numbers securely is a thing that exists, and a thing that requires top-skilled programmers, you're just wasting people's talent on dumb things.

deleted 2y ago

[deleted]

uecker 2y ago

I think it is somewhat about security. The "Nobody can write secure C/C++ code" nonsense translates to "We are not at fault that are products are broken garbage, because it is simply impossible to write secure code." Now we can pretend to fix "a whole class of errors" (as long as there is no "unsafe" anywhere) by imposing Rust on programmers (and the open-source community that then will produce memory safe code for free for some to use) and while this may indeed help a bit, one can hope to avoid being really being held responsible for product security for another decade or so.

saagarjha 2y ago

> There's a bunch of sub-par programmers, who don't use the old, well documented, stable, memory-safe functions and techniques. …which are?

pjc50 2y ago

> old, well documented, stable, memory-safe functions and techniques. I'm sorry, are we still talking about C here? Where the old functions are the ones that are explicitly labelled as too dangerous to use, like strcmp()?