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."
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,
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.
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.
Yeah, I just read their security advisory. I was basing my information on the original Heartbleed slashdot article which listed OpenBSD as unaffected.
(Note to self: Verify all thy claims before making a near-first comment on slashdot...)
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.
And thay changes things, how? C++ allows all the same "unsafe" things as C does. Have you ever used C++ before?
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
He was being somewhat sarcastic, because OpenBSD's allocator is in contrast to
and does try to separate allocations specifically to mitigate Heartbleed-style vulnerabilities.
In other words, the OpenBSD allocatior does have exploit mitigation, and the OpenSSL freelist acts as a countermeasure to those mitigation capabilities whether it was intended or not.
It says it's slow on "some platforms", yet they disabled it on all and then didn't test the alternative.
But of course everyone knows it's way better to quickly implement a dramatically awful security vulnerability than to do things slowly and correctly.