OpenBSD Team Cleaning Up OpenSSL 304
First time accepted submitter Iarwain Ben-adar (2393286) writes "The OpenBSD has started a cleanup of their in-tree OpenSSL library. Improvements include removing "exploit mitigation countermeasures", fixing bugs, removal of questionable entropy additions, and many more. If you support the effort of these guys who are responsible for the venerable OpenSSH library, consider a donation to the OpenBSD Foundation. Maybe someday we'll see a 'portable' version of this new OpenSSL fork. Or not."
de Raadt (Score:4, Insightful)
Yes, Theo has a bad temper and is not filtering carefully enough what he says, but his heart is in the right place, and he's a fucking great leader. I don't mind one bit his bad temper, because it usually hits those that really deserve it. And on the other hand, he's one of the most effective open source leaders.
Wonderful! (Score:2, Insightful)
I have little doubt that the OpenBSD team will significantly improve the code.
Re:What about a re-implementation... (Score:4, Insightful)
Re:What about a re-implementation... (Score:1, Insightful)
All languages are safe if used "properly".
The trick is being resilient against the occasional mistake, and C does that really poorly.
Re:What about a re-implementation... (Score:5, Insightful)
So if C is so bad why should we trust the languages that are implemented in it? You do realize that most of these "safe" languages are written in C, right?
"Ancient." "Cruft." (Score:5, Insightful)
While it may sound like that... (Score:5, Insightful)
The first step to cleaning up the code is getting it into a state where you're not leaving crap in place because 'It's for something I don't understand.'
That's what got us in the current OpenSSL mess in the first place.
Additionally, once the core code is cleaned up you can always follow the changelogs and merge the legacy stuff back in (assuming they're using git, or another VCS with a good git check(in/out) module.)
Honestly anyone still running any of those OSes is probably running a 0.9 series library and thus wasn't vulnerable to this bug to begin with. Who knows how many of those alternate paths even still worked anymore.
Re:Backport\Upstream? Seems unlikely (Score:5, Insightful)
It's a fork specifically for OpenBSD. Why would they keep support for other OSes?
I agree that if they were trying to create a general replacement fork of OpenSSL, that those would be bad things, but for what they're trying to do, these are good decisions. They're trying to improve OpenBSD's security - OpenSSL is a big attack surface, and they're trying to make it smaller by removing the things they don't need.
This will complicate things both ways, going forward. Updates to OpenSSL might be harder to integrate with OpenBSD's fork (if it becomes an actual independent product, can we call it OpenOpenSSL? Or Open^2SSL?), if it touches upon the altered parts. Likewise, anyone trying to merge an Open^2SSL fix into OpenSSL might have difficulty. I expect that if OpenBSD's fork of OpenSSL becomes a separate project, one or the other will die off, simply due to all that duplicated effort.
What I expect to happen in that case is that Open^2SSH will maintain compatibility with all the platforms OpenSSH or OpenSMTPD (which are OpenBSD projects) support - pretty much any Unix-like environment, including Linux, BSD, OS X, Cygwin, and most proprietary Unices. If there's enough desire for support for other platforms, a second fork might happen to maintain them, but I honestly doubt it (Mac OS 9? Really?).
Re:Backport\Upstream? Seems unlikely (Score:2, Insightful)
I think the point is to have as little code as possible, and to have no code that isn't covered by their tests. Both of which are excellent ideas if you want to write secure code.
Re:Backport\Upstream? Seems unlikely (Score:5, Insightful)
It's not remotely about petty OS wars. Complexity is bad for security, mmkay? If you want a newer version of openssl for OS/2, netware, or pre OSX MacOS, I'd really like to know what exactly you are doing. Dropping those platforms is the right thing.
Re:What about a re-implementation... (Score:5, Insightful)
If your language runtime has a bug instead, it's much more likely to be a very indirect one, because now not only do you likely have to cause a specific behavior in the program itself, but that behavior has to trip up the runtime in a way that causes that bug to lead to something bad.
Yeah and? Has that stopped all the exploits of the Flash runtime and the Sun/Oracle JVM? Nope. In fact, those two are among the most exploited pieces of userspace software on the OS.
Re:Backport\Upstream? Seems unlikely (Score:3, Insightful)
It's a fork specifically for OpenBSD. Why would they keep support for other OSes?
You only fork when you want to put distance between the original; there is nothing stopping them from making changes/"improvements" to the original OpenSSL project except for scope constraint (i.e. if they just want OpenBSD to be secure) or ego. Either one stinks of selfishness. I cant criticize them directly since they are still doing all of their work for "free" and are publishing it freely, but it has to be pointed out that they are choosing the greater of two evils.
Re:Backport\Upstream? Seems unlikely (Score:5, Insightful)
they are choosing the greater of two evils.
No.
Eventually supporting too many screwy and ancient systems starts to cause just so many problems that it is really, really hard to write solid, well tested, clear code. The heartbleed bug was exactly a result of this. Because of supporting so many screwy platforms, they couldn't even rely on having malloc() work well. That means they had their own malloc implementation working from internal memory pools. Had they not, they would have benefited from the modern mmap() based implementations and you'd have got a segfault rather than a dump of the process memory.
Supporting especially really old systems means having reimplementations of things which ought to be outside the scope of OpenSSL. Then you have to decide whether to always use the reimplementation or switch on demand between the custom one and the system one and whether or not to have some sort of quirk/bug correction.
This sort of stuff starts to add up and lead to a maintainance nightmare.
What OpenBSD are doing: throwing out all the accumulated crud and keeping the good parts is a fine way to proceed. It will almost certainly be portable to the other BSDs, OSX and Linux since they provide similar low level facilities. I doubt a port back to Windows would be hard because modern windows provides enough sane facilities that it's generally not too bad for heavily algorithmic code like this.
Basically there's no way for them to get started except to first rationalise the code base and then audit it.
Re:de Raadt (Score:5, Insightful)
Actually, it is you who are wrong.
Theo's point from the beginning is that a custom allocator was used here, which removed any beneficial effects of both good platform allocators AND "evil" allocator tools.
His response was a specific circumstance of the poor software engineering practices behind openSSL.
Furthermore, at some point, openSSL became behaviorally dependant on its own allocator -- that is, when you tried to use a system allocator, it broke -- because it wasn't handing you back unmodified memory contents you had just freed.
This dependency was known and documented. And not fixed.
IMO, using a custom allocator is a bit like doing your own crypto. "Normal people" shouldn't do it.
If you look at what open SSL is
1) crypto software ... you should already be squarely in the land of "doing every possible software engineering best practice possible". This is software that needs to be written differently than "normal" software; held to a higher standard, and correct for correctness sake.
2) that is on by default
3) that listens to the public internet
4) that accepts data under the control of attackers
I would say that, "taking a hard dependence on my own custom allocator" and not investigating _why_ the platform allocator can no longer be used to give correct behavior is a _worst practice_. And its especially damning given how critical and predisposed to exploitability something like openSSL is.
Yet that is what the openSSL team did. And they knew it. And they didn't care. And it caught up with them.
The point of Theo's remarks is not to say "using a system allocator would have prevented bad code from being exploitable". The point is "having an engineering culture that ran tests using a system allocator and a debugging allocator would have prevented this bad code from staying around as long as it did"
Let people swap the "fast" allocator back in at runtime, if you must. But make damn sure the code is correct enough to pass on "correctness checking" allocators.
Re:"Ancient." "Cruft." (Score:5, Insightful)
For whatever unfathomable reason Microsoft decided to make Winsock use the BSD socket API *but* you need to use Windows specific error handling mechanisms, Windows specific constants, initialization and shutdown functions, etc.