3 ms·

I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use.

by derekp7 11y ago

I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. Also, when programming in a higher level language, chances are that if you need to do anything interesting, you are more likely to be using someone else's library module which in turn is written in C. Also, the higher level you go, the more framework is sitting underneath your code -- framework that you must understand 100% in order to avoid misusing it (not to mention flaws in that framework). Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs.

geofft 11y ago
> I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. That's not a useful comparison, since you're distilling the question of how many bugs there are to whether there are bugs. If a language gets you two security-critical bugs in a 10-year-long project, that's not a reason to say "Eh, might as well have used C". > Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs. Sure, don't write security-critical software in PHP either. There are other languages in the world; some of them are specifically designed for writing security-critical software (e.g., Ada and Rust), some happen to be much better than C due to other parts of their design (e.g., Go, Haskell, idiomatic C++11, Vala), and some happen to be not significantly better than C (e.g., PHP, Python, Perl, bash, etc. etc.).
- glass- 11y ago
  > Rust So instead of using C we should write our security-critical software in a language that was released 3 months ago and has no major deployments.
  - geofft 11y ago
    Yes, agreed. We should choose languages based on their suitability for the job, not how long they've been free to ruin the world. That said, if you have some sort of external constraint about using a language merely because other people are using it, there's Ada, which is over three decades old and has numerous major deployments.
j-pb 11y ago
But it avoids a huge class of really really bad bugs. If you remove manual memory management and mutable stare you can go pretty far in terms of security even in a dynamically typed system. See clojure as an example.
jerf 11y ago
1: Do you agree that languages can be safer or less safe to write code in? If yes to 1, 2: Can you seriously defend the claim that C is not well to the "unsafe" end of the spectrum? And that, equivalently, there are a number of safer languages to write in? If no to 1, 2: How can you actually justify that? Given the same programmer writing in Haskell and Assembler, with the same amount of effort, all code written by that programmer will have the same security level? Really? It seems to me the only way to carry the argument that "It's not a problem to write security code in C" is to reduce all languages to "safe" and "unsafe", define "safe" somewhat absurdly as "impossible to write insecure code in", then claim that since all languages are in the "unsafe" column, it's just fine to use C. The mere act of spelling that argument ought to nearly suffice to refute it.
- nickpsecurity 11y ago
  It's kind of a false debate. There were a number of empirical studies in the 90's that compared many 3GL languages, esp to Ada as it was being assessed. The results were that C programmers produced the highest number of defects (esp severe ones), C++ improved on that, and Ada's safety features cut that way down except one time. Outlier might have meant anything. However, almost everything ever published showed C/C++ were less productive, harder to maintain, harder to integrate, and had more bugs/vulnerabilities. So, burden of proof is actually on other side to justify C particularly as a wise choice in building robust software. The AdaCore book below illustrates nicely the different areas where defects are common and how they systematically eliminate them. The Wirth languages similarly added all kinds of protections in automatically while letting you disable safety where performance or low-level requirements demanded it. Still did interface protections for calls to that code. I think updating something like that with extra protections Ada community, etc have figured out would give lots of safety, performance, & without Ada's steep learning curve. What you think? http://www.adacore.com/knowledge/technical-papers/safe-secure/ http://www.adacore.com/knowledge/technical-papers/safe-secur...
- AnimalMuppet 11y ago
  That's not enough to refute derekp's point, though. Let's admit that C is unsafe, and that some (not all) other languages are safer. But, first, safety is not the only virtue. And second, you don't get safety just by using a safe language. To the first point: Safety is good. Really. For security-critical software, safety is very, very, important. It's still not the only thing that's important. Familiarity to the developer still matters. Tool support still matters. For example, I've got nearly 30 years of experience with C/C++. I can avoid (most of) the sharp edges. Could I write code that somebody could still pwn? Probably. Could a static analyzer, say, save me? Maybe. But let's say I wrote the same code in Haskell. Could I write at least something that could DOS the user's machine? Easily. Would I have any idea whether I was doing so? No. Could a static analyzer save me? Second, I remember when Microsoft added the ability for Outlook to execute attachments. That was going to be a gaping security hole, no matter what language it was written in. The security hole was in the spec, not in implementing language. And if I understand derekp's point, you could have a safety hole in the library. For example, Java is safer than C at string handling... unless there was a flaw in Java's String library. Are you sure that there isn't one? How sure are you? Why are you that sure? For that matter, did Haskell have an SSL package? Was that package anything besides a wrapper around a C library? The higher level stuff you use, the more layers there are below you, and the greater the attack surface that you can't even see. Now, you could argue that I'm more likely to write a security bug doing string handling by hand, than there is to be one in Java's String library. And I'd agree that it's probably so. But I need everything I use to be bulletproof, and an attacker only needs to find one flaw. The more I use, the less the odds are in my favor. (The more I write myself, also the less the odds are in my favor.) There is a place where writing it yourself, even in C, is the right answer, even for security critical code. But once you do, audit it heavily, analyze it with as many tools as you can, have whitehats take a serious run at it, and so on.

by derekp7 11y ago

geofft 11y ago

> I see this opinion expressed quite frequently. Avoiding C avoids only a limited number of potential bugs, and bugs can occur no matter what language you use. That's not a useful comparison, since you're distilling the question of how many bugs there are to whether there are bugs. If a language gets you two security-critical bugs in a 10-year-long project, that's not a reason to say "Eh, might as well have used C". > Case in point -- how many web sites have been hacked that are written in PHP? or Wordpress? Avoiding C does not avoid bugs. Sure, don't write security-critical software in PHP either. There are other languages in the world; some of them are specifically designed for writing security-critical software (e.g., Ada and Rust), some happen to be much better than C due to other parts of their design (e.g., Go, Haskell, idiomatic C++11, Vala), and some happen to be not significantly better than C (e.g., PHP, Python, Perl, bash, etc. etc.).

glass- 11y ago
> Rust So instead of using C we should write our security-critical software in a language that was released 3 months ago and has no major deployments.
- geofft 11y ago
  Yes, agreed. We should choose languages based on their suitability for the job, not how long they've been free to ruin the world. That said, if you have some sort of external constraint about using a language merely because other people are using it, there's Ada, which is over three decades old and has numerous major deployments.

j-pb 11y ago

But it avoids a huge class of really really bad bugs. If you remove manual memory management and mutable stare you can go pretty far in terms of security even in a dynamically typed system. See clojure as an example.

jerf 11y ago

1: Do you agree that languages can be safer or less safe to write code in? If yes to 1, 2: Can you seriously defend the claim that C is not well to the "unsafe" end of the spectrum? And that, equivalently, there are a number of safer languages to write in? If no to 1, 2: How can you actually justify that? Given the same programmer writing in Haskell and Assembler, with the same amount of effort, all code written by that programmer will have the same security level? Really? It seems to me the only way to carry the argument that "It's not a problem to write security code in C" is to reduce all languages to "safe" and "unsafe", define "safe" somewhat absurdly as "impossible to write insecure code in", then claim that since all languages are in the "unsafe" column, it's just fine to use C. The mere act of spelling that argument ought to nearly suffice to refute it.

nickpsecurity 11y ago
It's kind of a false debate. There were a number of empirical studies in the 90's that compared many 3GL languages, esp to Ada as it was being assessed. The results were that C programmers produced the highest number of defects (esp severe ones), C++ improved on that, and Ada's safety features cut that way down except one time. Outlier might have meant anything. However, almost everything ever published showed C/C++ were less productive, harder to maintain, harder to integrate, and had more bugs/vulnerabilities. So, burden of proof is actually on other side to justify C particularly as a wise choice in building robust software. The AdaCore book below illustrates nicely the different areas where defects are common and how they systematically eliminate them. The Wirth languages similarly added all kinds of protections in automatically while letting you disable safety where performance or low-level requirements demanded it. Still did interface protections for calls to that code. I think updating something like that with extra protections Ada community, etc have figured out would give lots of safety, performance, & without Ada's steep learning curve. What you think? http://www.adacore.com/knowledge/technical-papers/safe-secure/ http://www.adacore.com/knowledge/technical-papers/safe-secur...
AnimalMuppet 11y ago
That's not enough to refute derekp's point, though. Let's admit that C is unsafe, and that some (not all) other languages are safer. But, first, safety is not the only virtue. And second, you don't get safety just by using a safe language. To the first point: Safety is good. Really. For security-critical software, safety is very, very, important. It's still not the only thing that's important. Familiarity to the developer still matters. Tool support still matters. For example, I've got nearly 30 years of experience with C/C++. I can avoid (most of) the sharp edges. Could I write code that somebody could still pwn? Probably. Could a static analyzer, say, save me? Maybe. But let's say I wrote the same code in Haskell. Could I write at least something that could DOS the user's machine? Easily. Would I have any idea whether I was doing so? No. Could a static analyzer save me? Second, I remember when Microsoft added the ability for Outlook to execute attachments. That was going to be a gaping security hole, no matter what language it was written in. The security hole was in the spec, not in implementing language. And if I understand derekp's point, you could have a safety hole in the library. For example, Java is safer than C at string handling... unless there was a flaw in Java's String library. Are you sure that there isn't one? How sure are you? Why are you that sure? For that matter, did Haskell have an SSL package? Was that package anything besides a wrapper around a C library? The higher level stuff you use, the more layers there are below you, and the greater the attack surface that you can't even see. Now, you could argue that I'm more likely to write a security bug doing string handling by hand, than there is to be one in Java's String library. And I'd agree that it's probably so. But I need everything I use to be bulletproof, and an attacker only needs to find one flaw. The more I use, the less the odds are in my favor. (The more I write myself, also the less the odds are in my favor.) There is a place where writing it yourself, even in C, is the right answer, even for security critical code. But once you do, audit it heavily, analyze it with as many tools as you can, have whitehats take a serious run at it, and so on.