?

Log in

No account? Create an account
teacher-mode

Heartbleed

Thanks to jducoeur, this link to XKCD's explanation of the Heartbleed bug.

OMG: I didn't realize it was this simple and stupid. Reason #738 why no production code should be written in C or C++.

Comments

Code review didn't find it here.

Some languages ARE more inherently fragile than others. Plenty of languages prevent entire categories of errors, most specifically the ones easiest to use for exploits (buffer overflows, bad pointer dereferencing).

Juggling flaming radioactive knives can be done safely by professionals, but if all you need to do is juggle, why not use batons instead?
The code reviewer has come forward, along with the bug author.

Fair cop

True: it would have been possible to produce this bug in other languages. But it would have been harder: you would have had to actively choose to dump from a specified memory position forward for a specified length rather than doing the easy thing, sending out a copy of the received string. C makes it easy to get at the raw machine when you need to -- but it also makes it easy to get at the raw machine when you DON'T need to.

And yes, the right answer in ANY language is good code review, careful documentation of assumptions, and testing what happens when those assumptions are violated.

There are languages (e.g. Haskell) that get nearly the performance of C without losing soundness, because the compiler does a lot of theorem-proving about what can and can't be true at various points in the code. Of course, that technology didn't exist forty years ago....

Re: Fair cop

But, I say absent certain knowledge, I bet that they don't get so cozy with the hardware

Don't actually know the answer in this particular case, but the general answer for Scala is: if Java can do it, Scala can do it. (And if not, not.) For better and worse, Scala tied its fate to the JVM. (Which gives it easier access to many more toys than Haskell, at the cost of some elegance.)

And while, yes, there are definitely some major areas where C is still the right answer, they're receding pretty steadily. Performance is rarely a convincing argument any more -- the compilers for the high-level languages can generally do better than most people rolling hand-coded C -- although I agree that hardware access often still is.

In this particular case, the argument is a little subtler. I doubt that performance or hardware access are actually worth writing it in C -- but depending on a VM would rule it out for many of the places where it is being used. I'm actually not sure what the best answer is nowadays for coding a native-compiled library...