2 ms·

I agree with this assessment. There is nothing inherently wrong with C. While alternative languages have certain advantages, there are clear reasons why core

I agree with this assessment. There is nothing inherently wrong with C. While alternative languages have certain advantages, there are clear reasons why core foundational libraries like OpenSSL are written in C: portability, age of the code base, knowledge of the contributors, etc. While I would personally like to see a pragmatic move towards C++ in many of these low level libraries for some of the additional type safety and mechanics the language provides, this is a normative idea only, and I am under no delusion that it would necessarily result in better code. Good software transcends language. I would, however, like to see enhancements to the style of code being written in this library so that tools like static analyzers and contract verifiers can provide meaningful results. A craftsman is only as good as how well he/she can make use of the available tools. Much of OpenSSL defies analysis, which is why the more bone-headed of these vulnerabilities, such as Heartbleed, are so hard to find. It's impossible to eliminate all bugs. But, it is possible to build code in such a way that when there is the suspicion of a bug, one has a fairly good idea of how and why it is occurring. It is also possible to structure code -- even C and assembler -- so that it's easier to read and analyze, be this by eye or using tools. Finally, it's possible to structure code so that automated unit testing provides meaningful results regarding boundary conditions and contracts between functions. This latter point isn't meant to find bugs on its own, but rather to codify the more subtle bits of contracts between functions and data structures in a defensive way to ensure that future patches -- like the one that caused Heartbleed -- don't stomp on assumptions made in software.

MichaelGG 12y ago
> There is nothing inherently wrong with C The fact that almost no teams on Earth seem to be able to ship large codebases without severe vulnerabilities rather disputes that idea.
- nanolith 12y ago
  Let me assure you that this is true regardless of language or platform. I've done vulnerability analysis on codebases written in C++, Java, C#, Objective C, Ruby, and Python. I've found bugs in each of these platforms. The biggest differentiator I found was experience. More experienced software developers, on average, made fewer bugs resulting in vulnerabilities than less experienced software developers. There is no magic language or platform that makes writing secure software easy. There are tools, techniques, and training that can help. But, these can only help. Writing quality software -- of which security is an important part -- is a difficult process that requires a lot of experience and discipline.
  - MichaelGG 12y ago
    Please point to the CVEs for the plethora of remote code execution bugs in apps written in Java and C#, for instance. I went through every single security bulletin MS published over the past couple years. The vast majority of the serious ones were 100% due to memory safety issues. The biggest exception was due to trying to sandbox arbitrary code (their .NET equivalent to Java applets). If you have some counter-evidence, showing C to be even remotely as safe as, say, Java, please step forward. If you are actually saying "Well I found a lot of SQL injection bugs in code written in Java", that's a different issue. And I'm sure you're aware of it. There's probably a name for the use of rhetoric of the form "Nothing's perfect. Therefore X and Y are just as good, since they are both imperfect."
    - nanolith 12y ago
      Luckily, I don't have to respond by your goalposts. You are hammering on a single class of security vulnerability out of hundreds of potential vulnerabilities. How does Rust prevent a confused deputy vulnerability? How about SQL Injection? Okay... well, what about all of the potential side channel attacks? People in higher level languages tend to believe that the relative safety of their position means that they have to be less vigilant about vulnerabilities. That is often what I have found. The number of vulnerabilities overall were similar, but the type of vulnerabilities were different. Because there was a completely mistaken belief that these platforms were "more secure", security practices were often sloppy. Most of these vulnerabilities were at the application level. So, looking for Microsoft CVEs isn't going to help you. The C++ code bases tended to have more senior level people working on them, who were more careful about both defects and vulnerabilities. Code bases in higher level languages, in general, had more junior level people working on them. Largely, the number of vulnerabilities were similar. Again, I'm speaking of my own experience. But, I think that many researchers in the field would give you a similar story. I'm always wary of people promising silver bullets over hard work.
      - MichaelGG 12y ago
        So by your own logic, if experienced C++ developers wrote in, say, Rust, they would not make mistakes like SQL injection, and they wouldn't be making all the memory-safety mistakes, either. Edit: If your overall point is that systems are laughably insecure, and most app devs just leave gigantic holes open, sure, great. But let's not compound that by making their OSes and low-level network stuff run arbitrary code for anyone on the Internet.

MichaelGG 12y ago

> There is nothing inherently wrong with C The fact that almost no teams on Earth seem to be able to ship large codebases without severe vulnerabilities rather disputes that idea.

nanolith 12y ago
Let me assure you that this is true regardless of language or platform. I've done vulnerability analysis on codebases written in C++, Java, C#, Objective C, Ruby, and Python. I've found bugs in each of these platforms. The biggest differentiator I found was experience. More experienced software developers, on average, made fewer bugs resulting in vulnerabilities than less experienced software developers. There is no magic language or platform that makes writing secure software easy. There are tools, techniques, and training that can help. But, these can only help. Writing quality software -- of which security is an important part -- is a difficult process that requires a lot of experience and discipline.
- MichaelGG 12y ago
  Please point to the CVEs for the plethora of remote code execution bugs in apps written in Java and C#, for instance. I went through every single security bulletin MS published over the past couple years. The vast majority of the serious ones were 100% due to memory safety issues. The biggest exception was due to trying to sandbox arbitrary code (their .NET equivalent to Java applets). If you have some counter-evidence, showing C to be even remotely as safe as, say, Java, please step forward. If you are actually saying "Well I found a lot of SQL injection bugs in code written in Java", that's a different issue. And I'm sure you're aware of it. There's probably a name for the use of rhetoric of the form "Nothing's perfect. Therefore X and Y are just as good, since they are both imperfect."
  - nanolith 12y ago
    Luckily, I don't have to respond by your goalposts. You are hammering on a single class of security vulnerability out of hundreds of potential vulnerabilities. How does Rust prevent a confused deputy vulnerability? How about SQL Injection? Okay... well, what about all of the potential side channel attacks? People in higher level languages tend to believe that the relative safety of their position means that they have to be less vigilant about vulnerabilities. That is often what I have found. The number of vulnerabilities overall were similar, but the type of vulnerabilities were different. Because there was a completely mistaken belief that these platforms were "more secure", security practices were often sloppy. Most of these vulnerabilities were at the application level. So, looking for Microsoft CVEs isn't going to help you. The C++ code bases tended to have more senior level people working on them, who were more careful about both defects and vulnerabilities. Code bases in higher level languages, in general, had more junior level people working on them. Largely, the number of vulnerabilities were similar. Again, I'm speaking of my own experience. But, I think that many researchers in the field would give you a similar story. I'm always wary of people promising silver bullets over hard work.
    - MichaelGG 12y ago
      So by your own logic, if experienced C++ developers wrote in, say, Rust, they would not make mistakes like SQL injection, and they wouldn't be making all the memory-safety mistakes, either. Edit: If your overall point is that systems are laughably insecure, and most app devs just leave gigantic holes open, sure, great. But let's not compound that by making their OSes and low-level network stuff run arbitrary code for anyone on the Internet.