Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Security Open Source Software BSD IT

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."
This discussion has been archived. No new comments can be posted.

OpenBSD Team Cleaning Up OpenSSL

Comments Filter:
  • Re:Okay, Go! (Score:5, Informative)

    by Rigel47 ( 2991727 ) on Tuesday April 15, 2014 @12:42PM (#46758019)
    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.
  • by Anonymous Coward on Tuesday April 15, 2014 @12:42PM (#46758023)

    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."

  • Re:Okay, Go! (Score:5, Informative)

    by buchner.johannes ( 1139593 ) on Tuesday April 15, 2014 @12:43PM (#46758047) Homepage Journal

    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 []

  • by grub ( 11606 ) <> on Tuesday April 15, 2014 @12:45PM (#46758065) Homepage Journal

    Ted Unangst wrote a good article called "analysis of openssl freelist reuse" []

    His analysis:

    This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator.

    it's a very good read.

  • by Anonymous Coward on Tuesday April 15, 2014 @12:48PM (#46758121)

    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.

  • by Anonymous Coward on Tuesday April 15, 2014 @01:00PM (#46758285)

    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.

  • Re:Okay, Go! (Score:4, Informative)

    by xdor ( 1218206 ) on Tuesday April 15, 2014 @01:00PM (#46758291)

    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.

  • by Anonymous Coward on Tuesday April 15, 2014 @01:19PM (#46758597)

    I agree that the OpenSSL code base is very bad. (I was doing some work based on modifying the library recently and I had to hold my nose.) However, I take objection with some of this:

    - 6,740 goto statements

    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.

    - Inline assembly code

    Otherwise known as "making the thing go fast". Yes, I want the bignum library, or hashing algorithms, to use assembly. Things like SIMD make these tasks really effing fast and that is a good thing...

  • by Lunix Nutcase ( 1092239 ) on Tuesday April 15, 2014 @01:24PM (#46758673)

    And thay changes things, how? C++ allows all the same "unsafe" things as C does. Have you ever used C++ before?

  • by QilessQi ( 2044624 ) on Tuesday April 15, 2014 @01:42PM (#46758877)

    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.

  • Re:de Raadt (Score:5, Informative)

    by EvanED ( 569694 ) <evaned@gmail. c o m> on Tuesday April 15, 2014 @01:50PM (#46758971)

    The freelist is not an "exploit mitigation countermeasure",...

    He was being somewhat sarcastic, because OpenBSD's allocator is in contrast to

    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

    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.

    The comment even says that it's done because performance on allocators is slow.

    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.

If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson