3 ms·

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, Ru

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.
    - nanolith 12y ago
      It's not nearly that simple. Look, I get it: you're a fan of Rust. That's great. Use whatever language floats your boat. But, it takes more than language features to solve security issues. Memory vulnerabilities are only a small piece of the wide range of potential defects that exist in software. These are also defects that largely go away with training and experience. I can teach most C / C++ developers how to manage memory and pointers in a way that avoids all of the pitfalls that Rust is designed to prevent. It is absolutely possible to write reasonably secure software in most general purpose programming languages. This is true for C, C++, and even Rust. Don't believe me? Spend some time studying the formal proof behind the se implementation of L4, written in C. All of this being said, I am a big fan of high-level languages. For my personal work, I write 80% of my software in Literate Haskell and around 20% in a lower level language like C++. But, I also understand the limitations that comes with abstraction, and they are big. System level code operates under a lot of constraints, and the abstraction that come with "safe" languages can come at the cost of this code working at all. A good software engineer uses whichever tool he / she needs to build good software. If the process is followed, then there is no reason why we can't have an ecosystem that uses whichever languages are best for the problem. For most system level stuff, C/C++ are perfectly fine. If you want to use Rust, great. But, don't delude yourself into believing that your language choice trumps good engineering practice. It never will. Don't believe me? Write some software that can work around the Halting Problem in Rust, and get back to me. Because, that's the sort of intelligence you would need in a compiler or a tool to replace good practice.
      - 12y ago

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.
  - nanolith 12y ago
    It's not nearly that simple. Look, I get it: you're a fan of Rust. That's great. Use whatever language floats your boat. But, it takes more than language features to solve security issues. Memory vulnerabilities are only a small piece of the wide range of potential defects that exist in software. These are also defects that largely go away with training and experience. I can teach most C / C++ developers how to manage memory and pointers in a way that avoids all of the pitfalls that Rust is designed to prevent. It is absolutely possible to write reasonably secure software in most general purpose programming languages. This is true for C, C++, and even Rust. Don't believe me? Spend some time studying the formal proof behind the se implementation of L4, written in C. All of this being said, I am a big fan of high-level languages. For my personal work, I write 80% of my software in Literate Haskell and around 20% in a lower level language like C++. But, I also understand the limitations that comes with abstraction, and they are big. System level code operates under a lot of constraints, and the abstraction that come with "safe" languages can come at the cost of this code working at all. A good software engineer uses whichever tool he / she needs to build good software. If the process is followed, then there is no reason why we can't have an ecosystem that uses whichever languages are best for the problem. For most system level stuff, C/C++ are perfectly fine. If you want to use Rust, great. But, don't delude yourself into believing that your language choice trumps good engineering practice. It never will. Don't believe me? Write some software that can work around the Halting Problem in Rust, and get back to me. Because, that's the sort of intelligence you would need in a compiler or a tool to replace good practice.
    - 12y ago