7 ms·

It's basically impossible to write safe code in C. Surely that makes it pretty damn poor at what it does? Especially since system code is the place where safet

by hbex5 12y ago

It's basically impossible to write safe code in C. Surely that makes it pretty damn poor at what it does? Especially since system code is the place where safety matters most.

Scramblejams 12y ago
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
- 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.
frozenport 12y ago
Consider the Linux kernel?
- Scramblejams 12y ago
  Which is filled with security bugs. Consider the conventional sysadmin wisdom that if someone gets a shell on your box, it's as good as owned, due to a no doubt fertile field of privilege escalation vulnerabilities in the kernel. Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.
  - foxhill 12y ago
    i'm sorry, but proof by convention or consensus is not a proof. you have an idea of the linux kernel, and it's not entirely unwarranted. but whilst there have obviously been security issues, it would be a mistake to suggest that they are the fault of C.
    - nraynaud 12y ago
      Let's just say that it's not C's fault. It's just that C is particularly well suited for creating security problems. The base semantics is dangerous, the undefined behaviors are lurking everywhere, and the compilers writers don't care ("it's the user fault if they go in undefined behavior that we put everywhere, and they'd better says thank you that we didn't ring their phone while they were in the bath the last time they did an integer multiplication without checking overflow, because the spec said we could have done it"). Sometimes I think the ebola crisis is created by a GCC developer. "I'm sorry for those people, but I was entitled to it, that guy there dereferenced a wild pointer, I could have cured cancer instead, but no".
    - Scramblejams 12y ago
      Strictly speaking, you are correct. But saying C is not at fault is like finding the trivial solution to a polynomial -- it is correct but not very useful. No, C is not at fault. The programmers are at fault. But it is prudent to ask, when some of the world's foremost programmers produce an apparently limitless number of CVEs as they do, whether they could use some help from the language. If the answer is yes, we should recognize that such help cannot come from C.
EliRivers 12y ago
One of the local Gods, "the market", would seem to imply that it doesn't matter much to most people.
- Scramblejams 12y ago
  Distressingly true. I despair that 20 years from now, absent an utterly wrenching change, we will all still be playing whack-a-mole with a seemingly infinite number of security bugs, many of monumental severity, all because we are unable to move away from our memory unsafe foundations. And the endless supply of ignorant C/C++ programmers (of which I am not suggesting Damien is a member) who profess to management that they can easily write secure code does not help.
sampo 12y ago
I don't think he wanted safety, he wanted fast runtimes. Is there any way to achieve speed without sacrificing safety? Ada?
- jbergens 12y ago
  He kinda did. He writes that they changed from Erlang to C because of problems in Erlang. He wanted some safety or tools to help him find problems easier (actually problems in the language or libraries they used). They might develop slightly faster now in C than they did before in Erlang but I doubt it and the rewrite took time that probably cost them 2 months of inproductivity compared to not rewriting it. As for running speed they of course want that. Can't remember if they actually thought that low speed was problem with the earlier Couchbase.
- doublextremevil 12y ago
  I think that is exactly what Rust[0] is trying to do. [0] http://www.rust-lang.org/ http://www.rust-lang.org/
ars 12y ago
> It's basically impossible to write safe code in C. Of course it's possible. If your issue is memory checking you can use mudflap or valgrind. > Surely that makes it pretty damn poor at what it does? No, it surely does not. > Especially since system code is the place where safety matters most. And yet somehow they manage. The security issues you find in system code are not things that would be helped by range checking.
- letstryagain 12y ago
  > Of course it's possible. If your issue is memory checking you can use mudflap or valgrind. It might be theoretically possible but in practice nobody has managed to do so with any non-trivial application.
  - semi-extrinsic 12y ago
    I beg your pardon? I've used valgrind for this purpose on large scientific codes running with MPI on supercomputers. And that works fine. The PETSc team at Argonne National Lab, who write perhaps the most used high-performance parallell linear algebra library in existence in C use valgrind for debugging. Surely those count as non-trivial applications?
    - dllthomas 12y ago
      I think the parent was trying to say "no one has managed to use C safely in a non-trivial application", not "no one has managed to use mudflap or valgind on a nontrivial application".
      - ars 12y ago
        He could try to say that, but it doesn't make him correct. And in fact if someone used valgrind and fixed any errors (which plenty of people have done successfully) that completely disproves him. He should retract his false statement due to evidence against it.

by hbex5 12y ago

It's basically impossible to write safe code in C. Surely that makes it pretty damn poor at what it does? Especially since system code is the place where safety matters most.

Scramblejams 12y ago

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
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.

frozenport 12y ago

Consider the Linux kernel?

Scramblejams 12y ago
Which is filled with security bugs. Consider the conventional sysadmin wisdom that if someone gets a shell on your box, it's as good as owned, due to a no doubt fertile field of privilege escalation vulnerabilities in the kernel. Don't get me wrong -- the Linux kernel is a magnificent piece of engineering, and an excellent choice for hosting a mainstream server, I run a number of such myself -- but let's not kid ourselves about its security limitations.
- foxhill 12y ago
  i'm sorry, but proof by convention or consensus is not a proof. you have an idea of the linux kernel, and it's not entirely unwarranted. but whilst there have obviously been security issues, it would be a mistake to suggest that they are the fault of C.
  - nraynaud 12y ago
    Let's just say that it's not C's fault. It's just that C is particularly well suited for creating security problems. The base semantics is dangerous, the undefined behaviors are lurking everywhere, and the compilers writers don't care ("it's the user fault if they go in undefined behavior that we put everywhere, and they'd better says thank you that we didn't ring their phone while they were in the bath the last time they did an integer multiplication without checking overflow, because the spec said we could have done it"). Sometimes I think the ebola crisis is created by a GCC developer. "I'm sorry for those people, but I was entitled to it, that guy there dereferenced a wild pointer, I could have cured cancer instead, but no".
  - Scramblejams 12y ago
    Strictly speaking, you are correct. But saying C is not at fault is like finding the trivial solution to a polynomial -- it is correct but not very useful. No, C is not at fault. The programmers are at fault. But it is prudent to ask, when some of the world's foremost programmers produce an apparently limitless number of CVEs as they do, whether they could use some help from the language. If the answer is yes, we should recognize that such help cannot come from C.

EliRivers 12y ago

One of the local Gods, "the market", would seem to imply that it doesn't matter much to most people.

Scramblejams 12y ago
Distressingly true. I despair that 20 years from now, absent an utterly wrenching change, we will all still be playing whack-a-mole with a seemingly infinite number of security bugs, many of monumental severity, all because we are unable to move away from our memory unsafe foundations. And the endless supply of ignorant C/C++ programmers (of which I am not suggesting Damien is a member) who profess to management that they can easily write secure code does not help.

sampo 12y ago

I don't think he wanted safety, he wanted fast runtimes. Is there any way to achieve speed without sacrificing safety? Ada?

jbergens 12y ago
He kinda did. He writes that they changed from Erlang to C because of problems in Erlang. He wanted some safety or tools to help him find problems easier (actually problems in the language or libraries they used). They might develop slightly faster now in C than they did before in Erlang but I doubt it and the rewrite took time that probably cost them 2 months of inproductivity compared to not rewriting it. As for running speed they of course want that. Can't remember if they actually thought that low speed was problem with the earlier Couchbase.
doublextremevil 12y ago
I think that is exactly what Rust[0] is trying to do. [0] http://www.rust-lang.org/ http://www.rust-lang.org/

ars 12y ago

> It's basically impossible to write safe code in C. Of course it's possible. If your issue is memory checking you can use mudflap or valgrind. > Surely that makes it pretty damn poor at what it does? No, it surely does not. > Especially since system code is the place where safety matters most. And yet somehow they manage. The security issues you find in system code are not things that would be helped by range checking.

letstryagain 12y ago
> Of course it's possible. If your issue is memory checking you can use mudflap or valgrind. It might be theoretically possible but in practice nobody has managed to do so with any non-trivial application.
- semi-extrinsic 12y ago
  I beg your pardon? I've used valgrind for this purpose on large scientific codes running with MPI on supercomputers. And that works fine. The PETSc team at Argonne National Lab, who write perhaps the most used high-performance parallell linear algebra library in existence in C use valgrind for debugging. Surely those count as non-trivial applications?
  - dllthomas 12y ago
    I think the parent was trying to say "no one has managed to use C safely in a non-trivial application", not "no one has managed to use mudflap or valgind on a nontrivial application".
    - ars 12y ago
      He could try to say that, but it doesn't make him correct. And in fact if someone used valgrind and fixed any errors (which plenty of people have done successfully) that completely disproves him. He should retract his false statement due to evidence against it.