4 ms·

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 prog

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.
  - tptacek 2y ago
    Security bugs are a distinct kind of defect and can't be reasoned about the same was as ordinary bugs, because ordinary bugs don't have intentional adversaries driving them. It makes sense to accept the risk of some kinds of bugs in ways you generally can't with security bugs (without some other mitigation in place).
  - steveklabnik 2y ago
    I fully agree that if you want the highest quality outcomes, you have to consider the whole process. However, I don't see that as being in conflict with using tools that can also help you achieve higher quality within a certain stage of that process.
    - 0xbadcafebee 2y ago
      The problem isn't the new tool, it's wasting an opportunity to have a more significant impact. The same amount of time, money, and resources that's going to be invested in this, could have been invested in a larger solution that still would have solved the immediate goals, as well as many others. We're pissing away the chance to improve not only more security but reliability of software as a whole. This is going to distract people for years away from other issues, and the result will be real world harm that could have been prevented. All because one class of bug is meme-worthy.

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.
- tptacek 2y ago
  Security bugs are a distinct kind of defect and can't be reasoned about the same was as ordinary bugs, because ordinary bugs don't have intentional adversaries driving them. It makes sense to accept the risk of some kinds of bugs in ways you generally can't with security bugs (without some other mitigation in place).
- steveklabnik 2y ago
  I fully agree that if you want the highest quality outcomes, you have to consider the whole process. However, I don't see that as being in conflict with using tools that can also help you achieve higher quality within a certain stage of that process.
  - 0xbadcafebee 2y ago
    The problem isn't the new tool, it's wasting an opportunity to have a more significant impact. The same amount of time, money, and resources that's going to be invested in this, could have been invested in a larger solution that still would have solved the immediate goals, as well as many others. We're pissing away the chance to improve not only more security but reliability of software as a whole. This is going to distract people for years away from other issues, and the result will be real world harm that could have been prevented. All because one class of bug is meme-worthy.