10 ms·

I wouldn't be allowed to build a skyscraper out of fatigued and rusty scrap iron. There is no reasonable amount of money and effort that could make that work, a

• rando289 12y ago
  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.
      • 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.)
• lodewijkadlp 12y ago
  't Was a better idea at the time. Additionally, it's really fast. Additionally, people can already use it. Not to mention the sunk costs of the massive packages. Additionally there's this tendency to say "Don't write your own crypto". Is it a surprise monocultures result from that?
• tbrownaw 12y ago
  When someone comes along saying "If you pay me, I'm going to write security software using unchecked pointer arithmetic" how do we as a community agree that the only response will be "That's a terrible idea and nobody will pay you for it"? By having an alternative that is actually in practice better. Confidence in maintainability is important. Performance is important. Compatibility (both as in language bindings, and as in variety of host systems) is important.
• U2EF1 12y ago
  C has some of the best static analysis and debugging tools of any language, but all of that's worthless if you don't use them. Doubly so if you specifically handicap those tools and write your own obfuscated allocation scheme. Heartbleed was less an indictment against C and more an indictment against shitty code.
  • Joeri 12y ago
    I don't see how one statement excludes the other. C is not the best tool to write secure software, but at the same time people have figured out how to use it securely despite its deficiencies. Heartbleed was a failure of both the tool and how it was used.
    • rgbrenner 12y ago
      Heartbleed wasn't the fault of C... It would have been caught if OpenSSL didn't implement their own allocator by Valgrind and other tools. Seriously, have you ever used valgrind? not a difficult tool to use What he's (erik) really saying is, if someone hires me to build a skyscraper, and I show up with fatigued and rusty scrap iron.. when the skyscraper fails, I should blame iron, and we should all have a talk about how terrible iron is, and why no one should be using iron. And whenever someone points out that I used rusty scrap, I'll just say, well titanium wouldnt have been rusty! Why arent we all using titanium?
• lifeisstillgood 12y ago
  That's not the argument - a skyscraper made out of fatigued and rusty iron would fall over before it could open. However a skyscraper that was not upto spec, no fire escapes, perhaps cutting back on the sprinkler system, maybe not putting in carpets, now that is more likely. We have market forces that prevent people selling clearly defective skyscrapers. But we need regulators and investigators paid for out of the public purse to ensure the defects that are not obvious are found. What we lacked here is a form of certification that the code was good enough. Or perhaps, we just lacked a form of certification that enough (qualified) eyeballs were looking at the code.
  • tenfingers 12y ago
    Certified software already exists ("trusted nix" anyone?). Though in practice it's arguable if it's actually any "better" than non-certified one. It also costs a lot more money to certify. Some OSS software has indeed problems with certification. A real example: if you do a statistical analysis for a government or public administration, you need to use certified software. Many people use Stata in that field though would prefer R for a number of reasons. I have, personally, twice as much confidence in any result that R is spewing compared to Stata. But Stata is certified, while R is not. To bring back to OpenSSL, you could readily start the certification process of a single version of OpenSSL if you really wanted, and most importantly, had money to. You know, for you critical business. Or you can just buy a certified SSL implementation in the first place and use that. Because if YOU're resposible for security, whose fault is when an exploit is found? The SSL developers, or you for not using certified software? Because that's how stuff is already working in practice. People in this thread seem to forget how free/oss software is made. Complaining about implementation details or "organization" politics about a group of people loosely collaborating is a bit hypocritical. Start a "Trusted OpenSSL" startup, collect money, and start employing the core developers. Then you might still have money to buy a Coverity license which will definitely help in spotting problems like these.
    • lifeisstillgood 12y ago
      I did not think I was complaining about the developers - more that it turns out (in hindsight) that half the internet trusted six overworked folks to build everything they depended on. I think that some form of warning or certification for OSS projects would surface things like "OpenSSL - used in 100 million sites, total spend 4 cents a week" would at least allow people to see where there donations to Another perhaps related one would be a culture of paying for free software (as in trusted funding routes, foundations and an expectation that users of free software at certain levels and sizes should contribute back. Not sure how it will work but raisin the facts and figures to prominence will encourage a solution.
• hifier 12y ago
  What do you think a lot of those higher-level alternatives are written in?
• Nursie 12y ago
  We don't. It's more than possible to write good software in C. It's more than possible to write bad software in any other language. Particularly where security is concerned C can give you control of operation timings and various other side-channels that others don't. C has not caused a single buffer overrun. Lazy coders have.
  • pmahoney 12y ago
    > C has not caused a single buffer overrun. Lazy coders have. That's like saying exposed high voltage lab equipment has not caused a single shock, careless lab techs bumping into it have. When you design for safety, you assume mistakes will happen, and you design accordingly. Continuing with the voltage example, for a low voltage, one that will shock but not cause lingering pain, a simple barrier would suffice to prevent careless bumping into. For higher voltage, a box with a door connected to an interlock that cuts power when the door is open is better. To receive a shock, either the interlock would need to fail, or the operator would need to deliberately defeat it. In even higher voltage situations, where the shock could cause permanent damage or death, trusting that single interlock would be insufficient, and further protections would be needed. In general, assume mistakes will happen, and design so that a serious failure requires multiple mistakes and/or multiple component failures. Never trust your life to a single component not failing. Whether C "causes" buffer overruns is irrelevant semantics. Using plain C without strong static analysis is equivalent to working directly on exposed voltage. Perfectly fine when nothing bad will happen as a result of inevitable mistakes. Negligent when securing a bank.
    • Nursie 12y ago
      >> When you design for safety, you assume mistakes will happen, and you design accordingly. Yes, and if more people working in C did this then we'd be better off. As it is there are a lot of hacks and awful coders who shouldn't be let near a line of basic, let alone anything with security impact, but they still find their way into banking, payments and other financial, security critical code. Call me naive, but I reckon these absolute muppets will find a way to f*ck up regardless of language technology. You can't force someone to write correct code who doesn't really understand WTF they're doing, and no framework or language is going to fix that.
• ksk 12y ago
  Okay, then make a business case to migrate away from C. Take into account (1) Available talent pool (2) Access to high quality tools/libraries/documentation/ (3) Performance (4) Maintainability (5) Language interop. Resources: time and money; are finite, as expected. Nobody has found an alternative. Perhaps you have one in mind.
• acqq 12y ago
  So do you actually know any other language, apart from C and C++ that will actually be compatible with all the existing needs? That means, among other things, being really fast, not using garbage collectors and being linkable to the rest of the software written in C. I know that Rust can be used once it matures, nobody knows when, but the question is for now?
• facepalm 12y ago
  Unfortunately for the time being software will have to be written by humans, that is, fallible entities. You make it sound as if there were some magical security programmers who are above fail and could be trusted to get everything right, all the time. I think that is a dangerous illusion. Is there even a name for that fallacy? It is so common - for example the same things happens when people call for regulations in finance. Regulation by whom? They imagine some magical finance genius people who would get everything right.