Slashdot Mirror
OpenBSD Team Cleaning Up OpenSSL
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."
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.
I think my CC number got stolen.
$30,949 is how much the OpenBSD Foundation received in donations in 2013. 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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It's not a shameless plug. Theo has been openly critical of the OpenSSL team's development practices. By forking in-house he's essentially saying that they will put their proverbial money where their mouth is by doing their own development.
We also have a comment from the FreeBSD developer Poul-Henning Kamp.
He starts by saying "The OpenSSL software package is around 300,000 lines of code, which means there are probably around 299 bugs still there, now that the Heartbleed bug — which allowed pretty much anybody to retrieve internal state to which they should normally not have access — has been fixed." After that he notes that we need to ensure that the compiler correctly translates the high-level language to machine instructions. Later Kamp rants a bit about the craziness of CAs in general — would you trust "TÜRKTRUST BLG LETM VE BLM GÜVENL HZMETLER A.."? Then he lists some bullet points about things that are wrong in OpenSSL:
- The code is a mess
- Documentation is misleading
- The defaults are deceptive
- No central architectural authority
- 6,740 goto statements
- Inline assembly code
- Multiple different coding styles
- Obscure use of macro preprocessors
- Inconsistent naming conventions
- Far too many selections and options
- Unexplained dead code
- Misleading and incoherent comments
"And it's nobody's fault. No one was ever truly in charge of OpenSSL, it just sort of became the default landfill for prototypes of cryptographic inventions, and since it had everything cryptographic under the sun (somewhere , if you could find out how to use it), it also became the default source of cryptographic functionality. [...] We need a well-designed API, as simple as possible to make it hard for people to use it incorrectly. And we need multiple independent quality implementations of that API, so that if one turns out to be crap, people can switch to a better one in a matter of hours."
Obviously since OpenBSD is running their fork of OpenSSL 0.9.8 which essentially doesn't have this exploit, this is just a shameless plug.
OpenBSD 5.3 - 5.5 was affected: see their Security Advisories
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Ted Unangst wrote a good article called "analysis of openssl freelist reuse"
His analysis:
it's a very good read.
Trolling is a art,
C is a perfectly safe language if used properly. Not to mention that it is as ubiquitous as it can possibly get without sacrificing portability.
Removal of ancient MacOS, Netware, OS/2, VMS and Windows build junk
Removal of “bugs” directory, benchmarks, INSTALL files, and shared library goo for lame platforms
Ripping out some windows-specific cruft
Removal of various wrappers for things like sockets, snprintf, opendir, etc. to actually expose real return values
There's no doubt that OpenSSL needs work, but they seem to be needlessly combining actual security review with "break every platform that I don't like." At a minimum, anyone else trying to benefit from this will need to unravel the worthwhile security changes from the petty OS wars crap.
Every so called "safer" language (than C) is also less efficient. For OpenSSL, we need maximum efficiency/speed in big data scenarios, and in cases where hardware acceleration is asked for. Playing with Go, Java & Co. is a no-go here. Plus, C can be just as safe, when used properly and when code is properly audited and screened. The problem with Heartbleed was that auditing took way too long to materialize and to catch up. A bug in a, say, Go version of OpenSSL would have probably taken just as long to get discovered, if auditing happens so seldom.
cpghost at Cordula's Web.
Apparently you didn't read the second news item on the OpenBSD news site, where they reached their 2014 funding goal of $150,000 last week.
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?
Added to this, most of what they're doing is removing code and exposing the underlying code to the safeguards they already have in place at the OS level. Refactoring suddenly becomes a LOT easier, as there's less to test. They're pruning their tree, essentially.
The beauty is that the way the handlers are designed at the OS level (and have already been tested against all other packages) means that if there IS a failure, it'll immediately cause a hard fail in OpenSSL -- which might seem bad, but it means that it'll be immediately reported and fixed, and the actual problem will be easy to find. It also means that there's less likelihood of an attacker being able to leverage the bug other than to perform denial of service attacks.
I read that as discarding stuff for Windows 98, 2000, and other ancient platforms that have fallen almost entirely from use, and certainly outside the pool of what's tested: A good thing.
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.
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?).
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.
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.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
As I understand it, one reason that security-related code is best done in low level languages is that the implementer has absolute control over sensitive data.
For example, consider an server which acquires a passphrase from the client for authentication purposes. If your implementation language is C, you can receive that passphrase into a char array on the stack, use it, and zero it out immediately. Poof, gone in microseconds.
But let's say you used some language which dynamically allocates memory for all strings and garbage-collects them when they go out of scope. It's "safer" in one respect, because it prevents the developer from having to do their own memory management. But auto-growing strings (and lists) often work via some invisible sleight-of-hand whereby the string's data is copied to new memory once it grows enough to fill its original underlying buffer. This can happen several times as you concatenate more characters onto the end of that string. So as you read it a long passphrase into a dynamically-growing string, little now-unused copies of the prefixes are being put back on the heap all the time, completely outside your control. If that daemon dumps core and you inspect the dumpfile, you might see something like "correct-horse-battery-sta". Marry that to the log of IP connections, and boom, you can make an educated guess at what Randall Munroe's passphrase is.
Koans and fables for the software engineer
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.
SJW n. One who posts facts.
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.
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.