4 ms·

You seem to be arguing against yourself. If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Or are you seriously

You seem to be arguing against yourself. If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Or are you seriously arguing that languages that are safer than C aren't Turing complete? There are plenty of memory-safe languages in which you can do nearly everything you'd do in C, and much, much safer. There's no reason whatsoever a program like 'strings' couldn't be written in a memory-safe language.

AnthonyMouse 12y ago
> If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Shellshock was a parsing bug, the memory safety of bash helped nothing. Bugs are bugs. When you get an out of bounds exception that leaves your program in an inconsistent state somewhere halfway up the call stack in a code path with poor test coverage, "safe" is not the correct word.
- thirsteh 12y ago
  The premise of this conversation is flawed: A language isn't "insecure" or "secure." It's placed at a certain point in a safety spectrum ranging from "Do anything with no safety" to "Safely heat the room and achieve nothing." What I'm saying is not that you can't write software that can be abused in memory-safe languages. I'm saying that you're much less likely to have extremely serious code execution vulnerabilities if you write a program in Go instead of C.
  - AnthonyMouse 12y ago
    > What I'm saying is not that you can't write software that can be abused in memory-safe languages. I'm saying that you're much less likely to have extremely serious code execution vulnerabilities if you write a program in Go instead of C. What I'm saying is that "much" less likely is overstating the difference. Most bugs in C programs are not buffer overruns, and even the ones that are would still be bugs in Go or Rust, they would just be a different kind of bug which is still plausibly exploitable under real conditions. This is not a silver bullet kind of situation. "Rewrite everything in Go" is not actually a fix -- it's replacing code with 30 years worth of bug reports and vulnerability testing with completely untested new code, at the cost of significant resources that could better be used to fix the remaining vulnerabilities. I'm not even saying that all the existing code is perfect. Replacing OpenSSL with entirely new code would probably do more good than harm just because the existing code is so ugly. But that's the exception rather than the rule.
    - thirsteh 12y ago
      There are a ridiculous number of serious vulnerabilities in C code related to lack of bounds checking and manual memory management. This isn't really opinion so much as fact. I understand what you're saying, but you're also downplaying the seriousness of C bugs relative to <most other languages> bugs. > Most bugs in C programs are not buffer overruns, and even the ones that are would still be bugs in Go or Rust, they would just be a different kind of bug which is still plausibly exploitable under real conditions. I don't follow. What's the equivalent of forgetting to check the length of an input string before chugging it into a too-small array in Go? > "Rewrite everything in Go" is not actually a fix I never said that, though. I'm not suggesting we rewrite the GNU tools in Go. But if you were to write the GNU tools from scratch today, C would be a bad choice simply because it's so easy to slip up with devastating effects, and there aren't many advantages to using it for simple tools like 'strings'.
      - AnthonyMouse 12y ago
        > There are a ridiculous number of serious vulnerabilities in C code related to lack of bounds checking and manual memory management. This isn't really opinion so much as fact. I understand what you're saying, but you're also downplaying the seriousness of C bugs relative to <most other languages> bugs. I feel like "<most other languages> bugs" tend to get ignored because it's not popular to blame <language> for bugs unless <language> is C. For example an enormous number of high severity CVEs are SQL injection but I never hear anybody saying we should replace SQL with a binary interface that clearly distinguishes statements from data, even though that would make more difference in practice than replacing C with something else. > I don't follow. What's the equivalent of forgetting to check the length of an input string before chugging it into a too-small array in Go? In Go the program terminates, which is at best a denial of service vulnerability. If the program is anything in the nature of Fail2ban then just causing it to die is a serious problem. Meanwhile when it restarts it will have to somehow deal with whatever corrupted state the crash left behind, which depending on the context can provide the attacker with opportunities to do arbitrarily bad things by manipulating the state to be something the programmer never anticipated. Being able to induce a restart is a huge increase in attack surface. Immediate program termination is the "take cyanide capsule" solution to serious bugs. It may be better than some of the alternatives but it's still very bad.
  - tomjen3 12y ago
    Does Go force you to sanitize all user input? Because I am sure if had ported bash to Go, you would still have the same issue with the broken parser. I am not sure if you would still have had heart bleed, but I know you wouldn't have had heart bleed if the openssl people had used the platform libc, instead of rolling their own, so I wouldn't consider heart bleed an issue with C, but an issue with the programmer.

AnthonyMouse 12y ago

> If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Shellshock was a parsing bug, the memory safety of bash helped nothing. Bugs are bugs. When you get an out of bounds exception that leaves your program in an inconsistent state somewhere halfway up the call stack in a code path with poor test coverage, "safe" is not the correct word.

thirsteh 12y ago
The premise of this conversation is flawed: A language isn't "insecure" or "secure." It's placed at a certain point in a safety spectrum ranging from "Do anything with no safety" to "Safely heat the room and achieve nothing." What I'm saying is not that you can't write software that can be abused in memory-safe languages. I'm saying that you're much less likely to have extremely serious code execution vulnerabilities if you write a program in Go instead of C.
- AnthonyMouse 12y ago
  > What I'm saying is not that you can't write software that can be abused in memory-safe languages. I'm saying that you're much less likely to have extremely serious code execution vulnerabilities if you write a program in Go instead of C. What I'm saying is that "much" less likely is overstating the difference. Most bugs in C programs are not buffer overruns, and even the ones that are would still be bugs in Go or Rust, they would just be a different kind of bug which is still plausibly exploitable under real conditions. This is not a silver bullet kind of situation. "Rewrite everything in Go" is not actually a fix -- it's replacing code with 30 years worth of bug reports and vulnerability testing with completely untested new code, at the cost of significant resources that could better be used to fix the remaining vulnerabilities. I'm not even saying that all the existing code is perfect. Replacing OpenSSL with entirely new code would probably do more good than harm just because the existing code is so ugly. But that's the exception rather than the rule.
  - thirsteh 12y ago
    There are a ridiculous number of serious vulnerabilities in C code related to lack of bounds checking and manual memory management. This isn't really opinion so much as fact. I understand what you're saying, but you're also downplaying the seriousness of C bugs relative to <most other languages> bugs. > Most bugs in C programs are not buffer overruns, and even the ones that are would still be bugs in Go or Rust, they would just be a different kind of bug which is still plausibly exploitable under real conditions. I don't follow. What's the equivalent of forgetting to check the length of an input string before chugging it into a too-small array in Go? > "Rewrite everything in Go" is not actually a fix I never said that, though. I'm not suggesting we rewrite the GNU tools in Go. But if you were to write the GNU tools from scratch today, C would be a bad choice simply because it's so easy to slip up with devastating effects, and there aren't many advantages to using it for simple tools like 'strings'.
    - AnthonyMouse 12y ago
      > There are a ridiculous number of serious vulnerabilities in C code related to lack of bounds checking and manual memory management. This isn't really opinion so much as fact. I understand what you're saying, but you're also downplaying the seriousness of C bugs relative to <most other languages> bugs. I feel like "<most other languages> bugs" tend to get ignored because it's not popular to blame <language> for bugs unless <language> is C. For example an enormous number of high severity CVEs are SQL injection but I never hear anybody saying we should replace SQL with a binary interface that clearly distinguishes statements from data, even though that would make more difference in practice than replacing C with something else. > I don't follow. What's the equivalent of forgetting to check the length of an input string before chugging it into a too-small array in Go? In Go the program terminates, which is at best a denial of service vulnerability. If the program is anything in the nature of Fail2ban then just causing it to die is a serious problem. Meanwhile when it restarts it will have to somehow deal with whatever corrupted state the crash left behind, which depending on the context can provide the attacker with opportunities to do arbitrarily bad things by manipulating the state to be something the programmer never anticipated. Being able to induce a restart is a huge increase in attack surface. Immediate program termination is the "take cyanide capsule" solution to serious bugs. It may be better than some of the alternatives but it's still very bad.
- tomjen3 12y ago
  Does Go force you to sanitize all user input? Because I am sure if had ported bash to Go, you would still have the same issue with the broken parser. I am not sure if you would still have had heart bleed, but I know you wouldn't have had heart bleed if the openssl people had used the platform libc, instead of rolling their own, so I wouldn't consider heart bleed an issue with C, but an issue with the programmer.