7 ms·

C security software is being massively funded and is very successfully the basis for trillions of business, eg. the linux & windows & mac kernel. But, according

C security software is being massively funded and is very successfully the basis for trillions of business, eg. the linux & windows & mac kernel. But, according to #1 voted random psuedonymous internet commenter, this is obviously a terrible idea.

bashinator 12y ago
It can be both successful and a terrible idea. Another example would be the single-user automobile becoming the dominant form of transit in the US.
- rando289 12y ago
  It can be whatever you want to call it. Terrible in comparison to a fantasy land of candy and rainbows. OP is saying "as a community we should say no to funding C security software". It's about as insightful as saying anyone who uses a car is dumb.
  - prodigal_erik 12y ago
    I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished, and by now yet another attempt shows such poor judgment that funding ought not be provided. Certainly Linux has had remote root exploits, and so many local exploits that its multi-user model is no longer taken very seriously, and the other kernels have fared no better.
    - rando289 12y ago
      > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished Kinda proves my point.
    - Sanddancer 12y ago
      Conversely, the well-audited OpenBSD kernel has had next to none of these problems precisely because they pay attention to correctness, even with the "fatigued and rusty scrap iron" that is the C language.
      - PhantomGremlin 12y ago
        I'm sure that OpenBSD is much more secure in general than Linux. I love it and use it as my own firewall. But even OpenBSD has had its share of local root exploits. They've even had 2 remote root exploits, and so few only because most services are disabled by default.
        Sanddancer 12y ago
        True. However, they also as a group have done some pretty significant research into problems declared solved in order to make systems more secure. For example, the change a few years back to make malloc based on mmap instead of more traditional heap pools, so that if there is an overflow, the program's much more likely to segfault than to go gleefully trampling over data, etc. Additionally, it's worth keeping in mind that the reason for the OpenBSD team forking OpenSSL wasn't Heartbleed, but rather the OpenSSL team's rather terribly coded malloc replacement that did things in there. All of the security research and practices the OpenBSD team typically insists upon couldn't do anything because OpenSSL insisted on running in its own leaky memory box.
    - bstx 12y ago
      > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished https://sel4.systems https://sel4.systems Possibly one of the most trustworthy pieces of software there is.
      - prodigal_erik 12y ago
        Man, I'd forgotten about that project. I wonder how much of the code could have been written differently and how much was effectively dictated by the theorem prover. Those are probably the very first people in the industry who deserve to be called engineers.
      - Intermernet 12y ago
        The sneaky thing they did is write seL4 in Literate Haskell, and then translate it to C. That involves some serious understanding of both languages! http://ssrg.nicta.com.au/projects/seL4/tech.pml http://ssrg.nicta.com.au/projects/seL4/tech.pml
      - Dewie 12y ago
        So what did they do? Write the code in C and then proved it with Isabelle/HOL? Extracted C code from Isabelle/HOL?
    - beagle3 12y ago
      d.j.b software (qmail, nacl, dnscurve, others). It is rare, but it has been done.
      - borplk 12y ago
        Oh the irony. Those that you mention are also safe until proven otherwise. I remember before Heartbleed was discovered everyone was raving about how secure OpenSSL is because it has been around for so long yadda yadda ... Heartbleed was discovered and everyone's suddenly acting "haha I knew it all along .. it was shit".
        beagle3 12y ago
        Everything is safe only until proven otherwise. Java will save you from (say) buffer overflows, but not SQL injections or permission errors (the most probable successful attack against Apache servers had always been writable executable directories, even though it is written in C and had its share of buffer overflows) And if your circle thought OpenSSL was tight, you are hanging in the wrong circles for security. Heart less was exceptionally bad, but OpenSSL for a long time had a couple of security fixes a month on Ubuntu and Debian - that's enough to tell you that you need to follow advisories closely and not trust blindly. And yes, I have been saying that for at least 5 years, before heartbleed was introduced.
      - _delirium 12y ago
        Even djb software has your usual C-type security issues, though in less frequency than normal. qmail had an integer overflow that was theoretically exploitable, but couldn't be practically exploited in a normal configuration (djb admitted that was "pure luck"). And djbdns had an integer overflow that was exploitable (though in fairly unusual circumstances): http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864
  - bashinator 12y ago
    Wow, that wasn't what I was saying at all. Read my post again - using (mostly) single-occupancy internal-combustion automobiles as the primary form of transit for the world's population is a terrible idea. When the car was first invented, I don't think anyone was thinking about 40,000 road deaths a year and CO2 pollution causing global climage change. When UNIX and linux kernels were written in C, nobody was thinking about string formatting or memory allocation exploits being used to steal millions of credit card numbers. That doesn't mean that drivers are dumb, or kernel developers. It does mean that we're living with the terrible consequences of various first-to-market success stories.
xenadu02 12y ago
All of which have had massive security flaws, including hundreds or even thousands of zero-day remote exploits. And that's just counting the C memory corruption bugs, not actual algorithmic bugs. If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning? That said, we're just going to continue soldiering on because of horrible programmer attitudes like yours. Everyone wants to believe that they are a unique little snowflake who wouldn't make those kinds of mistakes (oh wait, Coverty couldn't catch Heartbleed, oops) and choose the comfortable fiction of a Just World where people get what they deserve. After all, if people just drove better we wouldn't have so many accidents, so why bother with air bags and seat belts? Better hope everyone else drives better too or you'll be changing all your passwords and keys with the rest of us schlubs no matter how fancy your valgrind test suite is.
- PhantomGremlin 12y ago
  > oh wait, Coverty couldn't catch Heartbleed, oops Not fair. Iirc the reason Coverity couldn't catch Heartbleed was because the OpenSSL people insisted on rolling their own inferior memory allocation. It would have worked if they just used the system malloc(). Coverity only works for normal programmers, it can't fully mitigate the ingenuity of complete fools. Of course, my recollection could be wrong. In which case "someone is wrong on the Internet" will apply and someone will quickly set the record straight.
- jeffdavis 12y ago
  "If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning?" What language actually meets the need? GC'd languages haven't proven themselves useful for things like OSs, databases, or libraries that are deployed extremely widely in many environments. So what safe, non-GC language are you advocating?
  - zurn 12y ago
    This is irrelevant (and false). GC is orthogonal to memory safety. (And all of those things have been successfully been done in GC'd languages.)

bashinator 12y ago

It can be both successful and a terrible idea. Another example would be the single-user automobile becoming the dominant form of transit in the US.

rando289 12y ago
It can be whatever you want to call it. Terrible in comparison to a fantasy land of candy and rainbows. OP is saying "as a community we should say no to funding C security software". It's about as insightful as saying anyone who uses a car is dumb.
- prodigal_erik 12y ago
  I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished, and by now yet another attempt shows such poor judgment that funding ought not be provided. Certainly Linux has had remote root exploits, and so many local exploits that its multi-user model is no longer taken very seriously, and the other kernels have fared no better.
  - rando289 12y ago
    > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished Kinda proves my point.
  - Sanddancer 12y ago
    Conversely, the well-audited OpenBSD kernel has had next to none of these problems precisely because they pay attention to correctness, even with the "fatigued and rusty scrap iron" that is the C language.
    - PhantomGremlin 12y ago
      I'm sure that OpenBSD is much more secure in general than Linux. I love it and use it as my own firewall. But even OpenBSD has had its share of local root exploits. They've even had 2 remote root exploits, and so few only because most services are disabled by default.
      - Sanddancer 12y ago
        True. However, they also as a group have done some pretty significant research into problems declared solved in order to make systems more secure. For example, the change a few years back to make malloc based on mmap instead of more traditional heap pools, so that if there is an overflow, the program's much more likely to segfault than to go gleefully trampling over data, etc. Additionally, it's worth keeping in mind that the reason for the OpenBSD team forking OpenSSL wasn't Heartbleed, but rather the OpenSSL team's rather terribly coded malloc replacement that did things in there. All of the security research and practices the OpenBSD team typically insists upon couldn't do anything because OpenSSL insisted on running in its own leaky memory box.
  - bstx 12y ago
    > I'm not saying writing secure software in C is inherently impossible, but I'm not aware of it having ever been accomplished https://sel4.systems https://sel4.systems Possibly one of the most trustworthy pieces of software there is.
    - prodigal_erik 12y ago
      Man, I'd forgotten about that project. I wonder how much of the code could have been written differently and how much was effectively dictated by the theorem prover. Those are probably the very first people in the industry who deserve to be called engineers.
    - Intermernet 12y ago
      The sneaky thing they did is write seL4 in Literate Haskell, and then translate it to C. That involves some serious understanding of both languages! http://ssrg.nicta.com.au/projects/seL4/tech.pml http://ssrg.nicta.com.au/projects/seL4/tech.pml
    - Dewie 12y ago
      So what did they do? Write the code in C and then proved it with Isabelle/HOL? Extracted C code from Isabelle/HOL?
  - beagle3 12y ago
    d.j.b software (qmail, nacl, dnscurve, others). It is rare, but it has been done.
    - borplk 12y ago
      Oh the irony. Those that you mention are also safe until proven otherwise. I remember before Heartbleed was discovered everyone was raving about how secure OpenSSL is because it has been around for so long yadda yadda ... Heartbleed was discovered and everyone's suddenly acting "haha I knew it all along .. it was shit".
      - beagle3 12y ago
        Everything is safe only until proven otherwise. Java will save you from (say) buffer overflows, but not SQL injections or permission errors (the most probable successful attack against Apache servers had always been writable executable directories, even though it is written in C and had its share of buffer overflows) And if your circle thought OpenSSL was tight, you are hanging in the wrong circles for security. Heart less was exceptionally bad, but OpenSSL for a long time had a couple of security fixes a month on Ubuntu and Debian - that's enough to tell you that you need to follow advisories closely and not trust blindly. And yes, I have been saying that for at least 5 years, before heartbleed was introduced.
    - _delirium 12y ago
      Even djb software has your usual C-type security issues, though in less frequency than normal. qmail had an integer overflow that was theoretically exploitable, but couldn't be practically exploited in a normal configuration (djb admitted that was "pure luck"). And djbdns had an integer overflow that was exploitable (though in fairly unusual circumstances): http://article.gmane.org/gmane.network.djbdns/13864 http://article.gmane.org/gmane.network.djbdns/13864
- bashinator 12y ago
  Wow, that wasn't what I was saying at all. Read my post again - using (mostly) single-occupancy internal-combustion automobiles as the primary form of transit for the world's population is a terrible idea. When the car was first invented, I don't think anyone was thinking about 40,000 road deaths a year and CO2 pollution causing global climage change. When UNIX and linux kernels were written in C, nobody was thinking about string formatting or memory allocation exploits being used to steal millions of credit card numbers. That doesn't mean that drivers are dumb, or kernel developers. It does mean that we're living with the terrible consequences of various first-to-market success stories.

xenadu02 12y ago

All of which have had massive security flaws, including hundreds or even thousands of zero-day remote exploits. And that's just counting the C memory corruption bugs, not actual algorithmic bugs. If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning? That said, we're just going to continue soldiering on because of horrible programmer attitudes like yours. Everyone wants to believe that they are a unique little snowflake who wouldn't make those kinds of mistakes (oh wait, Coverty couldn't catch Heartbleed, oops) and choose the comfortable fiction of a Just World where people get what they deserve. After all, if people just drove better we wouldn't have so many accidents, so why bother with air bags and seat belts? Better hope everyone else drives better too or you'll be changing all your passwords and keys with the rest of us schlubs no matter how fancy your valgrind test suite is.

PhantomGremlin 12y ago
> oh wait, Coverty couldn't catch Heartbleed, oops Not fair. Iirc the reason Coverity couldn't catch Heartbleed was because the OpenSSL people insisted on rolling their own inferior memory allocation. It would have worked if they just used the system malloc(). Coverity only works for normal programmers, it can't fully mitigate the ingenuity of complete fools. Of course, my recollection could be wrong. In which case "someone is wrong on the Internet" will apply and someone will quickly set the record straight.
jeffdavis 12y ago
"If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning?" What language actually meets the need? GC'd languages haven't proven themselves useful for things like OSs, databases, or libraries that are deployed extremely widely in many environments. So what safe, non-GC language are you advocating?
- zurn 12y ago
  This is irrelevant (and false). GC is orthogonal to memory safety. (And all of those things have been successfully been done in GC'd languages.)