The good news (sort of) is that it's an ordinary buffer overflow attack. We've known that these are a problem for decades and we've known how to check for them automatically for decades. Even in C's niche there are research prototypes for safe C-like languages. And yet there seems little effort to make them production-ready and deploy them; what kind of market failure is that?
I think this is the final nail in the coffin for the ideas that "many eyes make all bugs shallow" or that code review alone by "experts" is enough to eliminate even the simplest of bugs. Use static analysis or go home.
There are plenty of other ways to screw up with crypto but they don't pass out the server's private keys just like that.
The main technical point of Theo de Raadt's "exploit mitigation countermeasures" post is that even when the infrastructure it's running on is trying to add safety checks, OpenSSL will often neuter them. The specific example was the exploit mitigations in OpenBSD's malloc, which are neutered for OpenSSL because (for dubious stated reasons) it insists on wrapping the system malloc with its own caching variant. The same would apply, of course, to more straightforward measures like a malloc() which just cleared out the returned memory before turning it over to the app.
And this isn't the only thing about the OpenSSL codebase which seems likely to frustrate attempts at analysis. (Heck, the whole "forest of #ifdefs" thing has got to be at least a bit of a stumbling block.)
Yes, it's certainly not production ready. I just mean that there is one contender that is coming that addresses this.
> is it possible to write a library in Rust, and have it callable from C?
Yup. The third production deployment of Rust is actually a Ruby extension, written in C, that is a thin wrapper over Rust. Ruby -> C -> Rust. The reason it was done this way is that Ruby's C interface is incredibly macro heavy, so it was easier to use them in a tiny C layer than to try to port them to Rust itself. For more: https://air.mozilla.org/sprocketnes-practical-systems-progra... (you'll have to scroll through to wycats' part.)
I still think that now would be the ideal time to start working on a TLS/SSL implementation in Rust. First, it would mean that there would be less time between the release of Rust 1.0 and a usable library. It would also be a good project to give feedback to the Rust compiler writers.
What really bothers me about HN and the startup echo chamber at large is the idea that newness makes something inherently better.
It's like an endemic of "not invented here" fever.
A language is not inherently better simply because it is newer. Sometimes the old ways are best. Rust will not magically solve problems like this. Only more disciplined coding and auditing practices can.
You are greatly misrepresenting the comment you're replying to. It is not suggesting that Rust is better because it's newer. It's suggesting that Rust would avoid this vulnerability because Rust is designed to avoid this vulnerability. It is absolutely possible to "magically solve problems like this" at a language level. Buffer overruns are possible because of specific decisions in the design of C. They simply do not exist in, for example, Java programs. There will still be errors that can occur, but this particular bug is 100% an artifact of C.
> Rust will not magically solve problems like this.
I agree that it won't magically solve problems like this, but it _will_ solve problems like this. Rust guarantees protection from data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory. At compile time.
That's because C++ is an approximate superset of C, an so it inherits all of that baggage as well. This is why we need new systems programming languages like Rust, designed for the 21st century with the benefit of hindsight.
I think this is the final nail in the coffin for the ideas that "many eyes make all bugs shallow" or that code review alone by "experts" is enough to eliminate even the simplest of bugs. Use static analysis or go home.
There are plenty of other ways to screw up with crypto but they don't pass out the server's private keys just like that.