The OpenSSL "heartbleed" vulnerability

Well actually now that I think about it.

Using https is a good way to be able to read the memory of every computer that connects to your webserver. At least for the time being.

Quite. The hilarious fact is that right now, if you're writing some software and you want crypto between agents across networks and you use something like libsodium and don't need any sort of interop with historical clients, then you're more likely to get it right, than if you use openssl!

What really could be simplified is the grammar, which is indeed more complex than necessary. But please don't confuse a message's grammar and its serialisation.

A few examples:

http://tools.ietf.org/html/draft-miller-jose-pkix-key-01
http://tools.ietf.org/html/draft-ietf-jose-json-web-signa...

Mozilla is now working on Servo, written in their new Rust programming language. To make it secure and to be able to make it more parallel.

Then there are all the protocol parsers available in the standard libraries of PHP/Python/Perl which may or may not be official parts of the language, but is still distributed with them (often forked and outdated versions of course). Probably every modern language with a big standard library shipped with a broken XML parser at some point (perhaps with the exception of Go, which is still quite young).

There are also all kinds of strange interaction bugs where the underlying software behaves in an unexpected way which causes problems. Just look at all the Python and Ruby software which gladly accepts code injections via YAML. Any application written in Rails over the last few years would have been bitten by these things not once but many times over. Even Github and Facebook which employs many committers to these projects have fallen over pretty much every time someone dedicates themselves to it. Google's web fronts are memory unsafe C++ and they have fared much better.

In summary: Yes, there are plenty of problems with C but there are even bigger problems with many of the proposed replacements. The answer is, as always, "it's complicated". Secure software needs a rigorous development process and someone needs to care about it, no matter what language or tools you choose.

If proponents can't name a language and runtime, how can the efforts to rewrite network services ever begin?

~

There is no silver bullet.

Some languages used in certain ways, paired with well-implemented runtimes will probably reduce the likelihood of some sorts of bugs, the impact of some bugs. A few improvements here, a few improvements there. Now, wny runtime you pick will have its share of nasty bugs to offset some of the gains; any set of design/code patterns will end up containing flawed patterns that need to get fixed up when you find they misfire.

The truth is that even simple algorithms and data structures *cannot* be expressed in C in a generic and type-safe way, and instead of acknowledging that and using a decent language or at least improve C, people work around that using the preprocessor that should have been shot in the head 30 years ago. “convenient” is just about the last word I could come up with to describe C.

We're talking here, clearly, about system-level libraries such as openssl. The statement under consideration is that C should never be used for anything (related to security). That implies that there _is no problem space anywhere_ (related to security) where there is not a better alternative language than C. So, (and again I'm not trying to be argumentative) what languages _should_ we be considering when writing the next, more secure openssl-type library?

And, importantly, what do we have to give up to make that change?

Personally I'm in the "pox in its house" camp when it comes to openssl; I've found it a PITA every time I've had to deal with it. I would LOVE for something else to take its place and if that something is inherently more secure by virtue of being written in a "more secure" language, so much the better.

Now is the perfect time for a real conversation about this, so let's get real.

Yes, DOS is a bit better than information leak, but we doesn't get this for free.

The question is whether the benefits outweigh the costs.

If bound checking is free I agree that having it enabled is a good thing. But the way it is currently implemented it is not. And I still want to stress that bound checking doesn't make incorrect program correct and this can only be used as a mitigation technique.

> Even if that weren't the case, most code isn't performance sensitive...
> The sane way to do it is to default to safety and remove checks where it's unavoidable to get sufficient performance (for example by using
> an “unsafe” block in languages that support it, such as C#, or by rewriting a small part of the program in an unsafe language).

This is the case when your program has bottlenecks. But often program has no an obvious bottleneck. One example is program I'm currently working on. Lots of efforts was put into performance optimization. On almost every workload the profile of this program is completely flat. No meaningful functions takes more than 3%. Even is we completely optimize away one specific part we gain only 3% of performance. We know that computational complexity of our algorithms is optimal. But the code is still working slower than we want. And truth to be told I was happy to disable some checks to speedup program for 3%, because manual optimization became very hard.

There is no small part to rewrite in unsafe language. Or should we rewrite all 5 Mb of code according to your suggestion?

If you going to say that our program is an exception, take a clang as another example. Which part of the compiler would you write on "safe" code and which on "unsafe"? Preprocessor? Parser? AST? Code generation?

> ...and many checks can be optimised away.

I saw an example where replacing array of char to std::string (from MSVC) results in 4x performance degradation. The problem was that std::string::operator[] (which doesn't do bound checking) choose which buffer to use based on size of the string using a single "if". This "if" enlarge size of a operator[] function and inliner (MSVC) decided not to inline it. On the other hand access to array of char was nicely merged into enclosing code. The program was an implementation of one of string-based algorithm so the effect was disastrous. The fix was to get the iterator from string before doing a computation, so this "if" is performed only once and operator* on iterator can be nicely inlined.

> In Java, it's trivial to run your program in a debugger and trap every time an ArrayIndexOutOfBoundsException is thrown, no matter if it's caught or not.

Only in case when none of libraries you use throw and catch this exception as a part of its standard workflow. Do you know how many components in large programs (like Visual Studio) throws random exceptions? I can cleanup exception in code that belong to me (and an exception in our part of code always indicates error in code), but I can not do this to the whole program. If I trap on every exception I will be unable to debug at all.

> The moment you're violating the bounds of an array you've already broken an invariant, the question is what to do about it. What you're saying here is that we shouldn't
> check array bounds because we *might* do something stupid in response when we *know* we'll do stuff that results in information leaks and code execution bugs if we don't.

So you want to get a chance (sic!) that sometimes your program continue to work in case of out-of-bound. In exchange you want to give up the performance of your program. I hope you know that writing fast code is much harder than writing a correct code.

The net effect is that, again, good programs only exist as a result of good programming.

Without my being "part of the problem" your computer would be be useful for little more than a doorstop. So, respectfully, take your attitude and shove it.

Memory protection separates *independent processes*, not memory within the same process.

Meanwhile, how do you think you're able to take advantage of that? Via someone "programming carefully" with C code.