4 ms·

I have no idea why you're being downvoted. Probably by a bunch of people who think they can write C and C++ without writing any security bugs. Which, unless the

I have no idea why you're being downvoted. Probably by a bunch of people who think they can write C and C++ without writing any security bugs. Which, unless they belong to a vanishingly small group of security experts who write code in an organization with the same discipline, budget and glacial schedule of the team writing software for the Space Shuttle, they can't.

foxhill 12y ago
except that literally every piece of software you have ever written or used goes through some level of C, and lets face it, most of the C projects out there are actually pretty well tested. and it's not like higher level languages are significantly better in this regard.
- Scramblejams 12y ago
  It's not like higher level languages are significantly better? Seriously? The last time I accidentally executed injected code due to a free error or buggy bounds check in the non-C parts of Python, or Ruby, or Lisp, or Erlang was ... well, never. And no, the fact that C underlies all these languages isn't a testimony to the adequacy of its security features.
  - foxhill 12y ago
    the python interpreter, CPython, is uh, written in C. CRuby, too. if C was so insecure, you would expect that interpreting python would be just as "insecure" as writing C.
    - Scramblejams 12y ago
      No, because writing a VM constitutes a reduction in attack surface. Implement a bytecode instruction properly once, and it's good everywhere it's used. Implement a correct garbage collector, and you don't have to worry about use-after-free anywhere in your Python code. You still have to worry about it in your C, though, and you have to make sure it's done correctly Every Single Place you do it. And if you think programmers are up to that task, go browse the CVEs for a while. Look, I know lots of people like you think that C isn't that hard to get secure code from. But if you were correct, we wouldn't be living in the security cesspool of memory bugs we are now.
    - Dewie 12y ago
      What is the LOC for the CPython interpreter? Now, what is the combined LOC for all Python code that uses the CPython interpreter (and those LOC are in a higher-level language). Now compare that to the amount of C code that that would amount to if all of that code was written (or, tried to be written) in C instead.
    - nl 12y ago
      That's so clearly false that it hardly deserves a response. I'm spending more time wondering if you are trolling that why you are wrong. But in case you aren't trolling: 1) A lot of "Python" security vulnerabilities are caused by "C"-problems (overflow errors, etc). [1] and [2] are a couple from this year. 2) You'd expect interpreting python to be more secure than C because the interpreter acts as a filter over input reducing the attack surface, meaning that potentially vulnerable paths are minimised are better tested than if an entire program was in C. [1] http://www.cvedetails.com/cve/CVE-2014-7185/ http://www.cvedetails.com/cve/CVE-2014-7185/ [2] http://www.cvedetails.com/cve/CVE-2014-1912/ http://www.cvedetails.com/cve/CVE-2014-1912/
    - pjmlp 12y ago
      Historical accident. People choose C, because nowadays it happens to be everywhere, which eases porting but there are lots of languages that could be used instead, if people valued safety.
    - bbcbasic 12y ago
      Technically you are correct: "C is not insecure". In the same way as "English is not offensive" However programs written in C may or may not be insecure. Of those programs you would expect a compiler or interpreter, that has been tested in the wild on millions of programs, and so you are more likely to find the security bugs. Also we hope these programs are written by very talented engineers. On the other hand Joe Enterprise hacking up a greenfield web service for the first time in C ... more likely to have security bugs. If Joe Enterprise moves from C to Java. Less likely to have security bugs.
alayne 12y ago
Memory safety can't guarantee security or correctness. If you guys want to have a better discussion, you need to be even handed about the complexity of security. Languages can solve some classes of security problems.
- Scramblejams 12y ago
  Agreed. But memory safety is really such low-hanging fruit right now. Given that memory bugs still produce massive quantities of severe vulnerabilities, it seems appropriate to hammer on that aspect of languages. If memory safety ever becomes a practically solved problem (e.g. somebody's running an OpenBSD-style count of how many days since a new memory bug popped up and it gets past, I don't know, hate to be greedy, how about 3?), then I'll be merrily banging away on the other aspects.

foxhill 12y ago

except that literally every piece of software you have ever written or used goes through some level of C, and lets face it, most of the C projects out there are actually pretty well tested. and it's not like higher level languages are significantly better in this regard.

Scramblejams 12y ago
It's not like higher level languages are significantly better? Seriously? The last time I accidentally executed injected code due to a free error or buggy bounds check in the non-C parts of Python, or Ruby, or Lisp, or Erlang was ... well, never. And no, the fact that C underlies all these languages isn't a testimony to the adequacy of its security features.
- foxhill 12y ago
  the python interpreter, CPython, is uh, written in C. CRuby, too. if C was so insecure, you would expect that interpreting python would be just as "insecure" as writing C.
  - Scramblejams 12y ago
    No, because writing a VM constitutes a reduction in attack surface. Implement a bytecode instruction properly once, and it's good everywhere it's used. Implement a correct garbage collector, and you don't have to worry about use-after-free anywhere in your Python code. You still have to worry about it in your C, though, and you have to make sure it's done correctly Every Single Place you do it. And if you think programmers are up to that task, go browse the CVEs for a while. Look, I know lots of people like you think that C isn't that hard to get secure code from. But if you were correct, we wouldn't be living in the security cesspool of memory bugs we are now.
  - Dewie 12y ago
    What is the LOC for the CPython interpreter? Now, what is the combined LOC for all Python code that uses the CPython interpreter (and those LOC are in a higher-level language). Now compare that to the amount of C code that that would amount to if all of that code was written (or, tried to be written) in C instead.
  - nl 12y ago
    That's so clearly false that it hardly deserves a response. I'm spending more time wondering if you are trolling that why you are wrong. But in case you aren't trolling: 1) A lot of "Python" security vulnerabilities are caused by "C"-problems (overflow errors, etc). [1] and [2] are a couple from this year. 2) You'd expect interpreting python to be more secure than C because the interpreter acts as a filter over input reducing the attack surface, meaning that potentially vulnerable paths are minimised are better tested than if an entire program was in C. [1] http://www.cvedetails.com/cve/CVE-2014-7185/ http://www.cvedetails.com/cve/CVE-2014-7185/ [2] http://www.cvedetails.com/cve/CVE-2014-1912/ http://www.cvedetails.com/cve/CVE-2014-1912/
  - pjmlp 12y ago
    Historical accident. People choose C, because nowadays it happens to be everywhere, which eases porting but there are lots of languages that could be used instead, if people valued safety.
  - bbcbasic 12y ago
    Technically you are correct: "C is not insecure". In the same way as "English is not offensive" However programs written in C may or may not be insecure. Of those programs you would expect a compiler or interpreter, that has been tested in the wild on millions of programs, and so you are more likely to find the security bugs. Also we hope these programs are written by very talented engineers. On the other hand Joe Enterprise hacking up a greenfield web service for the first time in C ... more likely to have security bugs. If Joe Enterprise moves from C to Java. Less likely to have security bugs.

alayne 12y ago

Memory safety can't guarantee security or correctness. If you guys want to have a better discussion, you need to be even handed about the complexity of security. Languages can solve some classes of security problems.

Scramblejams 12y ago
Agreed. But memory safety is really such low-hanging fruit right now. Given that memory bugs still produce massive quantities of severe vulnerabilities, it seems appropriate to hammer on that aspect of languages. If memory safety ever becomes a practically solved problem (e.g. somebody's running an OpenBSD-style count of how many days since a new memory bug popped up and it gets past, I don't know, hate to be greedy, how about 3?), then I'll be merrily banging away on the other aspects.