Hacker News Reader

Comment by prodigal_erik | Hacker News Reader

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, and just wanting to try would mark me as unqualified to do construction.

The heartbleed bug was a classic buffer overrun of the kind C has been causing for decades. 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"?

View on HN

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.

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.

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?

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.

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.

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.

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

"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?

There are several available (and some in the making).

That they aren't more established for this kind of work is both a historical accident (bad moves with regards to licencing, etc) and a result of the cavalier, worse-is-better solutions the industry takes to everything, even when it's counter-productive (e.g with regards to security) that didn't let them catch on.

For some known ones, used at one point or another for those purposes, Ada, Pascal, Oberon, Modula, etc.

New contenders still in development include stuff like Rust, as a GC-optional newer contender. One wonders why it took until 2010+ to see another attempt at these kind of languages, as if we didn't have any issues with C/C++.

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

Not sure what I said was false?

I agree that GC and memory safety are orthogonal -- see rust. But there aren't a lot of options if you want safe and non-GC, which was my point.

And GC is just not an option sometimes. GC has been around forever but it just hasn't proven itself in a lot of domains. I don't think it's for lack of trying, I think it's because sometimes you want to manage the memory.

> GC'd languages haven't proven themselves useful for things like OSs,

What about Lisp Machines?

Lisp Machines provide ways to 'manually' manage memory for things like network stacks.

If a Lisp Machine is doing a global full GC (which it wants to avoid as much as possible), then it does not react in any useful way to inputs, the network, ...

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.

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.

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.

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.

> 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

Possibly one of the most trustworthy pieces of software there is.

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

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.

So what did they do? Write the code in C and then proved it with Isabelle/HOL? Extracted C code from Isabelle/HOL?

d.j.b software (qmail, nacl, dnscurve, others). It is rare, but it has been done.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

I agree with you.

I was just trying to guard people against the false hope (and more often, lock-in due to money constraints) that certification provides.

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?

What do you think a lot of those higher-level alternatives are written in?

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.

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.

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

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

You've constructed your argument in such a way that is both inarguable, and non-actionable. Yes, it's true that with sufficient patience, attention to detail, time, and money, you can write sophisticated, secure software in C.

However, in the real world, it turns out that programmers are "lazy" (which is a pretty condescending way to describe it, btw). It's a fact that programmers using C have been responsible for millions, if not billions of dollars in economic losses due to simple buffer overflows, integer overflows, use after free, etc. So is the solution to come up with something better than C, or is it to just tell people to stop being lazy and hope they stop producing these bugs?

The solution would be to stop hiring incompetents who shouldn't be allowed near a line of BASIC let alone anything else, from being allowed anywhere near sensitive code, regardless of language.

Reply on news.ycombinator.com