Theo De Raadt's Small Rant On OpenSSL 301
New submitter raides (881987) writes "Theo De Raadt has been on a better roll as of late. Since his rant about FreeBSD playing catch up, he has something to say about OpenSSL. It is worth the 5 second read because it is how a few thousand of us feel about the whole thing and the stupidity that caused this panic."
Update: 04/10 15:20 GMT by U L : Reader badger.foo pointed out Ted Unangst (the Ted in the mailing list post) wrote two posts on the issue: "heartbleed vs malloc.conf and "analysis of openssl freelist reuse" for those seeking more detail.
"It's Not a Tumor" - Oh Wait, It Is (Score:5, Interesting)
Once upon a time, SSL certificates were signed against a single root certificate, each SSL cert issuer had a single root certificate authority for each of its product lines. Now all corps issue an SSL certificate that is signed against and INTERMEDIATE certificate, which in turn is signed against the root certificate.
What happens if a provider's server has this exploit and the intermediate certificate is compromised? EVERY certificate signed against that intermediate must be revoked. Or put another way, the ENTIRE PRODUCT LINE must be tossed into the garbage and all certs reissued.
So if Verisign or Thawte discover new their intermediate certificate MIGHT have been exploited, would they say anything? The servers implementing those certs are in the hands of a select few - it would be easy to hide the possibility they might have been compromised.
Why OpenSSL is so popular? (Score:5, Interesting)
So what could be done to prevent something like this from happening in the future? People will keep writing bad code, this is unavoidable, but what automated tests could be run to make sure to avoid the worst of it? Someone with direct development experience please educate the rest of us.
not developed by a responsible team? (Score:2, Interesting)
On the contrary, I believe it was developed by a responsible team, that unfortunately made an error.
Most everyone have made errors, even if most go unnoticed and are essentially harmless. This one appears different, but I don't think it justifies De Raadt's moronic comment.
Bug Looks Deliberate (Score:5, Interesting)
That code is almost a text book example of material that is submitted to the Underhanded C contest...
http://en.wikipedia.org/wiki/Underhanded_C_Contest
Re:So what is an alternative to OpenSSL? (Score:5, Interesting)
GnuTLS, which recently people were being told to avoid in favor of OpenSSL. You see, there was this bug...
Really? (Score:3, Interesting)
"it is how a few thousand of us feel about the whole thing"
Then maybe you thousands should stop complaining and start contributing to the project, which is so under-resourced problems like this are pretty much inevitable.
Re:"It's Not a Tumor" - Oh Wait, It Is (Score:4, Interesting)
As we all know, most high level hacks these days come from an internal computer getting infected with something.
De Raadt is wrong (Score:2, Interesting)
Comment removed (Score:5, Interesting)
Re:not developed by a responsible team? (Score:3, Interesting)
This is simply not true, stop spinning it.
Even if OpenSSL is using system's malloc, with all its mitigation features, the bug still works. The attacker just has to be more careful, lest he should read freed() and unmapped memory, and so cause a crash and (supposedly) leave some kind of meaningful trail.
Feeding Allo(g)ators (Score:3, Interesting)
Allocators in this case make no significant difference with regards to severity of the problem.
What is or is not in process free list makes no difference when you can arbitrarily request any block of memory you please.. only slightly effects chance of success when it becomes necessary to shoot in the dark. Lets not forget most OS provided optimized allocators keep freed memory in their heaps for some time as well and may still not throw anything when referenced.
Looking at code for this bug I am amazed any of this garbage was accepted in the first place. There is no effort at all to minimize chance of error with redundant + 3's and 1 + 2's sprinkled everywhere complete with unchecked allocation for good measure.
Suppose I should be glad 1 + 2 = 3 today and they have not used signed integers when dealing with lengths.
... oh dear god ...
Well at least they learned their lesson and have stopped sprinkling redundant and error prone type + length + padding garbage everywhere... see..
and here ..
... oh well .. Looks like plenty of low hanging fruit to be had for anyone with a little spare time.
The chilling thing about Ted Unangst's analysis (Score:5, Interesting)
As I read his analysis, OpenSSL relies on releasing a buffer, reallocating it, and getting the PREVIOUS contents of that buffer back -- or else it will abort the connection. (Search for the string "On line 1059, we find a call to ssl3_release_read_buffer after we have read the header, which will free the current buffer." in his article referenced by the parent post).
Now, IMO, this goes way beyond sloppy. Releasing a buffer before you're done with it, and relying on a wacky LIFO reallocation scheme giving you back that very same buffer so you can process it, is either 1) an utterly incompetent coding blunder that just happened to work when combined with an utterly terrible, insecure custom allocation scheme, or 2) specifically designed to ensure that this insecure combination is widely deployed to provide a custom-made back door, as it works only with the leaky custom allocator.
If 1), then I must agree with Theo that the OpenSSL team were indeed irresponsible, since at least one of these two cooperating blunders ought to have shown up in a decent security audit of the code, and any decent set of security-oriented coding standards would forbid them both.
If 2), then it was deliberate, and the tinfoil-hat crowd is right for once.
the RFC is horrible (Score:5, Interesting)
Re:When comments... (Score:4, Interesting)
As much as Theo can be an utter and insufferable prick, on this score he's right.
Actually, most of the time he's right; it's just the prick bit that is the problem. What's worrying about this is that he sounds completely reasonable. He didn't even call the Open SSL developers any names or anything and everything in the post was reasonable. I hope he isn't sick or something.
Re:not developed by a responsible team? (Score:4, Interesting)
That would have been an appropriate boilerplate response to your typical Theo De Raadt comment, but... did you actually read that "analysis of openssl freelist reuse" link? It's hard for me to imagine that having been done by mistake; it's more of an instance of a coder cleverly cutting a corner. And some might argue "don't we all?", but if one is writing such security-critical software, one should at least have some notion that clever corner-cutting is a gigantic no-no.
Now, the freelist reuse is not the cause of the heartbleed bug; it merely frustrates what would otherwise have been a relatively straightforward mitigation strategy. But it's a symptom of an attitude that is, well, irresponsible.