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."
Re:And they've already stopped (Score:5, Interesting)
$30,949 is how much the OpenBSD Foundation received in donations in 2013. [openbsdfoundation.org] That has to get fixed as their expenses were $54,914 and only a one-time transfer from an old account covered the deficit.
The community that depends on OpenSSH, OpenNTPD and the like needs to figure out how to support these projects.
Personally I'd like to see the Foundation offer targeted donations to specific projects with a percentage (~20% perhaps) going into the general operations fund. I bet there are a bunch of people who would throw a hundred bucks at OpenSSH but would be concerned that a general donation would go to some odd thing Theo is doing (whether that be fair or not).
And if "Fixing OpenSSL" were one of the donation options, then hold on to your hats - I think we're all in agreement on this. We do know that the folks currently working on the projects are paid by others but if the Foundation can get enough money to offset expenses then it could actually do some development work and possibly finally take care of some sorely-neglected tasks on a few of these codebases.
Re:Okay, Go! (Score:4, Interesting)
Not necessarily. It looks like they're removing what they can't support, such as VMS, Netware and OS/2. The few people that care can still use the original OpenSSL code.
I'd expect them to ensure it support the hardware platforms OpenBSD supports at the very least. Then, if they go the "portable" route like they did for OpenSSH, support for the other Unix and Unix-like systems.
http://www.openssh.com/portable.html [openssh.com]
More power to them.
Re:What about a re-implementation... (Score:5, Interesting)
Re:And they've already stopped (Score:3, Interesting)
Should they not be getting some tax funding??? This is so ironic projects like this that if they fail can take down the next every company that uses these projects pays taxes should tax money not be given with out any strings like no nsa back doors or the sort but rather make sure all bugs are taken care of? To many companies profit from ssl yet the project that maintains it is on very week standings.
OpenSSL OR... (Score:3, Interesting)
Or simply support and use the GnuTLS!
both have their own set of problems, but at least now you have the a alternative.
Re:"Please Put OpenSSL Out of Its Misery" (Score:2, Interesting)
It's not just the library that's in shit shape, the openssl commandline tools themselves are annoying. Getting it to generate a UCC/SAN certificate with multiple hostnames is a hoot (you hardcode the list of alternate names into the openssl configuration file. Then when you want to create a different certificate you hardcode a new list of alternate names into the openssl configuration file), and just using it for its intended purpose basically requires that you either completely understand SSL certificates and what a Common Name is, or you have read a walkthrough to explain that when it asks for your name, it means it wants your hostname.
Re:de Raadt (Score:5, Interesting)
He is technically incapable of evaluating what's actually happening, and likes to go off-list when he's angry and wrong [fbcdn.net].
The freelist is not an "exploit mitigation countermeasure", but rather standard allocation caching behavior that many high-rate allocation applications and algorithms implement--for example, ring buffers [wikipedia.org] are common as all hell. The comment even says that it's done because performance on allocators is slow.
Further, the only bug in Heartbleed was a READ OVERFLOW BUG caused by lack of input validation. It would actually read that a user said "This heartbeat is 65 thousand bytes long", allocate 65 thousand bytes plus room for instrumentation data, put instrumentation data in place, and then copy 65 thousand bytes from a request that was 1 byte long. While there are mitigation techniques, most allocators--anything that uses brk() to allocate the heap for allocations smaller than say 128KB (glibc's pmalloc and freebsd's kmalloc both use brk() until you ask for something bigger than 128KB, then use mmap())--don't do that. That's how this flaw worked: It would just read 64KB, most likely from the brk() area, and send it back to you.
Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD. Write overflows would kill canaries, but they actually allocated enough space to copy the too-large read into. And the code is, of course, correct for invalid input.
Theo made a lot of noise about how all these other broken things were responsible for heartbleed, when the reality is one failed validation carries 100% of the weight for Heartbleed. If you perfectly cleaned up OpenSSL except for that single bug, slapped it on Linux with the default allocator, and ran it, it would still have the vulnerability. And it only behaves strange when being exploited--and any test would have sent back a big packet, raising questions.
There was never really any hope that this was going to be caught before it was in the wild and "possibly had leaked your SSL keys'. It may have happened sooner, maybe, maybe not; but it still would have been a post-apocalyptic shit storm. And all those technical mitigations Theo is prattling on about would have helped if OpenSSL were cleaned up... AND if those technical mitigations were in Linux, not just OpenBSD.
Re:Thanks! (Score:5, Interesting)
No. We all love to hate on OpenSSL because it's a pile of poo.
There are vested interests who make a living because they have write permissions to OpenSSL and they can charge companies to do it and the barrier to entry to others is really high because it's a undocumented, over complex pile of source.
Right on. (Score:5, Interesting)
Otherwise known as "the only sane way to simulate exceptions in C". Seriously. Read up on how "goto" is used in low-level code bases such as OS kernels, instead of citing some vague memory of a 1960s paper without understanding its criticisms.
People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading. You don't want them used as a universal hammer for every nail in the code. At some point though, people need to jump off the bandwagon and learn to respect, not fear, these things that actually have some very compelling uses.
Re:Backport\Upstream? Seems unlikely (Score:5, Interesting)
If they end up stripping it down to a minimal library with the core functionality, cleaning up the public interface (e.g. exported functions), and making it easy to create your own OS-specific wrapper around it, then they are actually doing something that should have been done in the first place. If they do it right, it will become much more popular (and most likely more light-weight and secure) than the current OpenSSL project.
Re:de Raadt (Score:4, Interesting)
OpenBSD is a hobby OS
*every* community-driven operating system is a hobby OS. Is that relevant?
It's like Linux with grsecurity
Maybe for you. Not for me. And it is actually easier to audit and it has a smaller kernel. And a kernel debugger. Something that is quite handy to find and troubleshoot problems.
(...) I would avoid the bet.
There are also more Windows machines than *nix machines with an internet connection. Some little-known RTOS are way more popular than Linux and BSD combined. Your point is?
OpenBSD's allocator is what we call "Proof of Concept".
Monolythic kernels are a proof of concept of monolythic designs. Every existing implementation of something is a proof of concept of the given concept. Again, what is the point?
It exists somewhere in real life, you can leverage it (I've leveraged proof-of-concept exploit code from Bugtraq in actual exploit kits), but it's not this ubiquitous thing that's out there enough to have an impact on the real world.
While OpenBSD itself is a niche product, its team is very well known for producing hugely popular products, including OpenSSH and PF. BSD server usage is low, but there are no real stats on middleware - routers, storage units, set-top boxes, closed devices, etc. FreeBSD is reportedly used in Playstation - that's more users than most Linux distros has. Is popularity usage relevant to the discussion? Not really.
Suntrust, Bank of America, slashdot, the NSA, Verisign, Microsoft, Google--is running a non-OpenBSD operating system with no such protections
I'd actually be very surprised if none of these companies use OpenBSD goodies - Either OpenBSD by itself, or middleware BSD products. And then you can add to this OpenSSH, OpenBGPD and a couple more interesting products. Microsoft used OpenBSD as a basis for the Microsoft Services for Unix. But again - is it relevant to the discussion? Not really.
And again, the concept of allocation caching is common. Freelists are used when allocations are all the same size; that gripe is essentially that a valid data object is not valid because they dislike it. Plenty of software uses freelists, and freelists are a generalization of the object pool software design pattern used for database connection caching in ORMs, token caching in security systems, and network buffers (ring buffer...). I would be surprised if OpenBSD's libc and kernel didn't make use of freelists or object pools somewhere.
So, you're saying that optimizing memory allocation in privileged space is the same as optimizing memory allocation on a userland library? That managing fixed-sized, out-of-the-userspace-address-pool structures is the same as trying to be smarter than the local malloc implementation? No system is perfect, but it generally sounds like a very bad idea.
In short: there's a lot of whanging on that OpenSSL made OpenBSD's security allocator feature go away, and that (implication) if OpenSSL had not done that, then an exploit attempt would have come across one of the 0.01% of interesting servers running OpenBSD, and a child Apache process would have crashed, and some alarms would have gone off, and someone would have looked into the logs despite the server humming along just fine as if nothing had happened, and they would have seen the crash, and investigated it with a debugger, and then reproduced the crash by somehow magically divining what just happened, and done so BEFORE THE WHOLE WORLD HAD DEPLOYED OPENSSL 1.0.1.
So, you're assuming there aren't compromised OpenBSD servers because of this. And that no one actually tried to exploit it in OpenBSD. The fact is that no one kows exactly the extent of the damage of this vulnerability, or if it could have been detected way earlier by using OpenBSD or Linux with grsecurity or whatnot. And