back to article OpenBSD founder wants to bin buggy OpenSSL library, launches fork

In the wake of the Heartbleed bug fiasco, members of the OpenBSD project have forked the popular OpenSSL library with the aim of creating a new version that they say will be more trustworthy. Even though OpenSSL is open source software, for a full two years its entire development community managed to overlook the crucial bug …

COMMENTS

This topic is closed for new posts.

Page:

  1. Roo
    Windows

    Can't wait for 5.6. Keep on trucking OpenBSD. :)

  2. Anonymous Coward
    Anonymous Coward

    One more pair of eyes

    An update to bss_dgram.c at 2014-04-21 13:13:43 makes a call to malloc and assumes it always succeeds. Oooops!

    ....

    data->saved_message.data = malloc(inl);

    memcpy(data->saved_message.data, in, inl);

    return inl;

    ....

    You are welcome

    1. Anonymous Coward
      Anonymous Coward

      Re: One more pair of eyes

      Yeah, that's the way. Any open source code fixes just pick a related article on the internet somewhere and post them up!

      This is just the sort of public spirited contribution that would've stopped heartbleed from happening!

  3. Anonymous Coward
    Anonymous Coward

    Right, so ...

    > and the programmer whose error caused all the ruckus says there just aren't enough people scrutinizing the OpenSSL code to spot difficult-to-find bugs

    ... and forking it and making it OpenBSD-only is going to improve number of eyes looking at the code how?

    1. Michael Thibault

      Re: Right, so ...

      Perhaps it's that the eyes involved have security consciousness in the DNA? Or, that they recognise that security is at the foundation of their preferred OS and are thus 'incentivised'? Perhaps it's that the eyes aren't actually busy crafting yet-another colour of lipstick to put on their mascot? Perhaps it's that the eyes aren't otherwise busy mule-headedly forking yet another variant of their preferred OS? It's difficult to say why people do the things they do. But there are lots of possibilities.

      1. midcapwarrior

        Re: Right, so ...

        "security consciousness in the DNA"

        So now we are breeding security folks.

        Guess it can't be worse that what we have now.

    2. Christian Berger

      Re: Right, so ...

      Well what seems to be obvious is that the OpenSSL team doesn't seem to be quite up to the job. After all they let that heartbleed bug in even though there apparently was no indication of any input sanity checks in it. If your code is critical to half of the SSL connections on the Internet, you should be somewhat more careful not to break stuff. Maybe you should even have multiple independent reviewers for any patches that come in. Plus you need to have the courage to tell someone that their code is not quite up to the standards they have, and perhaps give them tips on how to improve it. (this can, in many cases, be a pre-written text)

      So yes, this might be an OpenBSD-only thing at first, but as with much OpenBSD originated software it'll spread out to other operating systems. After all most of the systems out there today are POSIX.

      1. Alan Brown Silver badge

        Re: Right, so ...

        "If your code is critical to half of the SSL connections on the Internet, you should be somewhat more careful not to break stuff."

        If you critically rely on code put together by a few _UNPAID_ volunteers then you should be more inclined to help out.

        On the paid side, it's mostly just been a dog and pony show. Security tends to be an afterthought and it shows.

    3. P. Lee

      Re: Right, so ...

      I suspect the way they want to achieve additional eyes is to simplify and normalise the code style to what is currently considered good practise and to get rid of cruft.

      By forking/starting a new project, you get permission to break things and lose features because you aren't impacting existing users and refactoring the code is one way to get to grips with it and will involve some auditing on its own. This is probably a better way to go than to do a massive revision in the existing package, since there is still a good chance of breaking things.

    4. Charlie Clark Silver badge

      Re: Right, so ...

      Forking is perfectly legitimate especially if you want to change large parts of the code as seems to be the case. OpenBSD itself started life as a fork of FreeBSD and the two continue to profit from each other's different focus.

      Taking the existing code as a functional specification and removing as much code as possible will allow the developers to make a reference implementation that will hopefully be a more secure. Like OpenSSH (from OpenBSD) it should then be pretty straightforward for others to use the library and I suspect other developers will be happy to join in.

      Meanwhile the existing code will continue to "work" and can even benefit from backporting any changes.

      1. Anonymous Coward
        Anonymous Coward

        Re: Right, so ...

        OpenBSD itself started life as a fork of FreeBSD

        A fork of NetBSD actually, since Theo was booted out of that project for his incredibly abrasive manner. At the time NetBSD was a better choice since the key design goals were portability and simplicity, whereas FreeBSD was focused exclusively on getting maximum performance for the Intel x86 architecture.

        1. Charlie Clark Silver badge

          Re: Right, so ...

          @Chris Wareham - you're right, of course. Thanks for the correction. The underlying point stands: forking is part and parcel of open source.

    5. Roo
      Windows

      Re: Right, so ...

      "... and forking it and making it OpenBSD-only is going to improve number of eyes looking at the code how?"

      Fair question, but I don't think it's relevant in this instance because a major complaint levelled at the OpenSSL team is that they don't accept many (if any) patches from anyone else, so it doesn't really matter how many eyes are looking at the code base if the maintainers are unwilling/unable to actually fix the code.

      With that said, I haven't seen the many eyes argument being used by the OpenBSD team... Their beef with OpenSSL appears to be that it is a key piece of user land, it trades security for performance, and the coding falls well short of what the OpenBSD team consider to be good practice. From the examples and patches I have looked at I have to agree, the sooner that OpenSSL is shit-canned the better in my view.

      Heartbleed isn't the first OpenSSL bug to have raised some hackles in OpenBSD land - but it appears to be the final straw. :)

      1. Anonymous Coward
        Anonymous Coward

        Re: Right, so ...

        Incredible the number of DIFFs posted in two weeks by OpenBSD. (Imagine IBM trying to clean up this gar-bage: years!)

        So much junk and strange modules. Amazing that much of commerce and security was handled under the OpenSSL jibberish. For us who don't code it's, "shut up and donate."

        Anyone who has a commercial web site should toss a couple of bones to Theo and Co. Some of us know Lucha LibreSSL will be a great improvement over DopenSSL.

    6. Anonymous Coward
      Anonymous Coward

      Re: Right, so ...

      and forking it and making it OpenBSD-only is going to improve number of eyes looking at the code how?

      For starters they'll probably make it work with the system malloc instead of OpenSSL's brain dead memory allocator:

      Heartbleed vs malloc.conf

      analysis of openssl freelist reuse

      1. Jamie Jones Silver badge
        Boffin

        Re: Right, so ...

        "For starters they'll probably make it work with the system malloc instead of OpenSSL's brain dead memory allocator:"

        I knpw you're not implying it, but as many people believe it to be so, it's worth reminding that the hearbleed bug has nothing to do with malloc, nor memory management in general.

        Also, the OPENSSL_malloc function ends up calling system malloc, but as you infer, this point is moot if they use other mechanisms to manipulate their malloced memory block in user space.

        1. Bronek Kozicki
          Holmes

          Re: Right, so ...

          Heartbleed was related to malloc, in a sense. Without own malloc, Heartbleed would't have caused one tenth of the damage it did. Here is explanation how:

          Had OpenSSL used system malloc rather than their own free list, memory allocated to old request would actually get freed, and memory accesses such as those exploited by Heartbleed would actually crash the system. Which would prevent miscreant from accessing your private data, and also hopefully prompted OpenSSL team to fix the bug.

        2. Anonymous Coward
          Anonymous Coward

          Re: Right, so ...

          I knpw you're not implying it, but as many people believe it to be so, it's worth reminding that the hearbleed bug has nothing to do with malloc, nor memory management in general.

          Indeed, but the way memory is held in the OpenSSL freelist implementation means that the bug is far more exploitable since there's more likely to be interesting stuff that can be peeked at. Also, OpenSSL doesn't work with the freelists disabled, as Ted U discovered. Had it worked, then it's likely this bug would have been caught much earlier by the kind of people who use strict malloc/free implementations and settings for security critical stuff.

  4. A Non e-mouse Silver badge

    Not just KNF

    Freshbsd has a nice summary of the changes the OpenBSD team have made so far. The general tidying up so far seems to be not just KNF, but removing unnecessary wrappers around standard C library routines, and switching to more standard/modern malloc family memory allocation calls.

    These are all the low hanging fruit jobs. Once this is done and the code is in a more modern/readable style, then the hard word of auditing the code can start.

    1. Bronek Kozicki

      I looked at those commits, makes interesting reading.

      Same of the code being fixed or removed is ... very ugly indeed. Some of it makes my hair stand on ends, like a living illustration of The Coding Horror. Also looking at the age of this bug and its implications to security of users it is obvious that OpenSSL team is, at best, incompetent. Alternatively, perhaps they are motivated to keep the codebase in bad shape. Either way, I am never going to trust OpenSSL again.

      I'm very happy OpenBSD has taken the task of fixing it, and I committed to monthly donations for them. They deserve their pay for service to the world, providing alternative to abomination of a code that was OpenSSL.

      1. Anonymous Coward
        Anonymous Coward

        @Bronek

        Why don't you write some better code, and contribute it to either OpenSSL or LibreSSL?

        1. BinkyTheMagicPaperclip Silver badge

          Not a good idea. I don't know Bronek's coding skills, but hacking cryptography should be left to the very small number of people that are good at both coding and cryptography.

          1. Anonymous Coward
            Anonymous Coward

            "Not a good idea. I don't know Bronek's coding skills, but hacking cryptography should be left to the very small number of people that are good at both coding and cryptography."

            D'you reckon?

            People should just stick to saying how bad others are at it, without showing them how to do it better? That's a better option, is it?

  5. Anonymous Coward
    Anonymous Coward

    Never mind Comic Sans

    Look at those amazing <blink/> tags!!!

    1. Anonymous Coward
      Anonymous Coward

      Re: Never mind Comic Sans

      You may have overlooked the note at the bottom of the page:

      "This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and blink tags".

      Yeah, that'll work.

      1. davemcwish

        Re: Never mind Comic Sans

        There should be a 2nd donate button to keep annoying the hipsters.

  6. btrower

    My eyes!

    I had to look. In fairness to the OpenSSL guys, it is not the only bad code out there, not by a long shot. Again, in fairness to them, it works to some extent.

    We shall see, but I expect this will go from horrible to less horrible but still horrible. This class of code is gruesomely messy all over. I would roll up my sleeves and help fix it, but it is like attempting to save a manuscript that has fallen in the sewer. It is better to just re-think and re-write. Besides, my aesthetic sensibilities differ.

    I would write a list of rules of thumb these guys routinely break but it would go on forever.

    I do not like to criticize other programmers, especially open source guys who have given of their blood sweat and tears for free. Code that works at all is very difficult to write. This is not for ordinary people by a long shot. Most of the people poking fun at the code would not be able to do it even as well, let alone better. Still, you may not know how to do a thing, but still be able to easily tell it is not done well. The OpenSSL stuff is not done well overall. However, that identical criticism is true of so much of the code we use, proprietary code included that it is unfair to single out the OpenSSL guys.

    My hat is off to the programmer who made the mistake and fessed up to it. I admire the courage.

    1. DanDanDan

      Re: My eyes!

      One look at this specific change (below) had me agree wholeheartedly with you. Why hard code the size of a buffer (256 in this case), when the functions "sizeof()" does exactly that for you?! Performance gains? Wouldn't this be sorted by a semi-decent compiler?

      http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/lib/libssl?id=258edb6cb04cce27479a492e610b6bd1f535c9f3

      1. Anonymous Coward
        Anonymous Coward

        Re: My eyes!

        @DanDanDan

        >Wouldn't this be sorted by a semi-decent compiler?

        Think about what sizeof() actually does. Hint: it doesn't actually call anything at runtime.

        1. Anonymous Coward
          Anonymous Coward

          Re: My eyes!

          Hint: sizeof() in C99 can indeed be a runtime call.

          1. Anonymous Coward
            Anonymous Coward

            Re: My eyes!

            >Hint: sizeof() in C99 can indeed be a runtime call.

            Only for variable length arrays:

            unsigned char buf[256];

            buf is not a variable length array and OpenSSL isn't compiling with C99 as it's standard.

            And... GCC doesn't compute the size of variable arrays when sizeof is called:

            "The length of an array is computed once when the storage is allocated

            and is remembered for the scope of the array in case you access it with sizeof."

            1. Anonymous Coward
              Anonymous Coward

              Re: My eyes!

              INTERNATIONAL ISO/IEC STANDARD 9899

              Second edition 1999-12-01

              It _really_ looks like a standard to me. From said standard:

              The sizeof operator yields the size (in bytes) of its operand, which may be an expression or the parenthesized name of a type. The size is determined from the type of the operand. The result is an integer. If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant.

              In general my impression with GCC is that unless you insistently ask for it to try to conform to a standard (e.g., with something like -pedantic -std=c99) then it will compile a rag-bag mixture of standards and non-standard extensions.

              1. Anonymous Coward
                Anonymous Coward

                Re: My eyes!

                >It _really_ looks like a standard to me. From said standard:

                That standard that doesn't apply to that code.

  7. Destroy All Monsters Silver badge
    Windows

    Madness is doing the same thing and expecting a different outcome

    Color me pessimistic but...

    "Too busy coding"

    "Writing in C"

    Those are not good words.

    1. Anonymous Coward
      Anonymous Coward

      Re: Madness is doing the same thing and expecting a different outcome

      From a security point of view, yes those guys are quite insane but so far they've proven they know damn well what they're doing. As for writing in "C", here's something for you from Wikipedia :

      [quote] code which needs to run particularly quickly and efficiently may require the use of a lower-level language, even if a higher-level language would make the coding easier [/quote]

      If you're still unhappy, you may go ahead and write it in Java or any other high-level programming language you master.

    2. Dazed and Confused

      Re: Madness is doing the same thing and expecting a different outcome

      "Too busy coding"

      "Writing in C"

      Those are not good words.

      You can write bullet proof code in assembler, you just need to know what you're doing.

      1. Alan Brown Silver badge

        Re: Madness is doing the same thing and expecting a different outcome

        "You can write bullet proof code in assembler, you just need to know what you're doing."

        But assembler isn't portable.

        1. Dazed and Confused

          @Alan Brown

          "You can write bullet proof code in assembler, you just need to know what you're doing."

          But assembler isn't portable.

          My point was that you don't need some high level language to watch your arse if you know where your own arse is.

          The problem with good code is its often boring.

          Flying by the seat of your pants is often quicker and more exciting. Remembering to check the return from every call is dull dull dull but a good plan if you don't want to run the risk of problems later on.

          During a formal code review I once upset a programmer by complaining that his code was boring to read. Well boring it might have been, but I'd have been more than happy to get on a plane if he'd have written the flight control SW.

    3. A Non e-mouse Silver badge

      Re: Madness is doing the same thing and expecting a different outcome

      C does not have the exclusive license on bad or insecure code.

      1. Anonymous Coward
        Anonymous Coward

        Re: Madness is doing the same thing and expecting a different outcome

        C is good, very good. It makes no pretence to protecting the programmer from his own inadequacies and does not claim to make the whole world warm and safe. It makes sure the programmer and designer retain full responsiblity for their actions. It is light weight, reasonably transparent in its interactions and terse. With a good coding style and relevant comments it is clearer to understand than most "high level" languages. I write this as a happy user of Pascal/Algol/Modula style languages at one time and quite a fan of Python now (there's a contradiction for you).

        Java and its kind are dangerous: they purport to do all the nasty bits for you. But they do so to a surprisingly limited extent and involve an unhealthy amount of trust in black boxes, innumerable libraries and a full understanding and tracking of scope, for instance.

        As an ancient SE, I am amazed at the reduced quality of even critical code today and the casual acceptance of bugs and frequent updates. Either the programmers are much worse or the tools are at fault, or both.

        I am ever more impressed by the long term solidity of, for instance, real UNIX implementations, UNIX shells and tools, X11, countless real time software and so on, written mainly in K & R C plus some assembler. I am delighted by a language that is small enough to be described, in full, in a book less than a couple of centimetres and that is so clean and small that, very quickly, a competetent engineer can hold it completely in his memory, including the commoner library calls, with the rest in succint man pages.

        I am appalled at the likes of C++ or Java where, it seems, none of us can master even the full semantics of the basic language (if it stops evolving long enough), let alone the plethora of class libraries each described in a manual as big as the Old Testament, so that advertisements for workers have to specify which libraries, which versions ....

        As for the idea that a load of clever amateurs or professionals with time on their hands is the way to get code, in which they have no personal interest, properly and thoroughly reviewed, probably with no desing or implementation documents to guide them - well, openSSL is not the first software to show how daft that is. Reviewing is hard, skilled work requiring knowledge, experience and time. It is rarely doen adequately even when people are paid for it and have a professional, vested interest. These "reviewers" of open code: how many of them publish proper reports of their reviews, findings, recommendations etc. for peer review? Or do they just put in a "fix", perhaps not much better than the original and rely on some "gatekeeper" to approve it and shove it in the package source tree?

        Anon - stealing a few minutes before starting work.

        1. Roo
          Windows

          Re: Madness is doing the same thing and expecting a different outcome

          "I am ever more impressed by the long term solidity of, for instance, real UNIX implementations, UNIX shells and tools, X11, countless real time software and so on, written mainly in K & R C plus some assembler. I am delighted by a language that is small enough to be described, in full, in a book less than a couple of centimetres and that is so clean and small that, very quickly, a competetent engineer can hold it completely in his memory, including the commoner library calls, with the rest in succint man pages.

          I am appalled at the likes of C++ or Java where, it seems, none of us can master even the full semantics of the basic language (if it stops evolving long enough), let alone the plethora of class libraries each described in a manual as big as the Old Testament, so that advertisements for workers have to specify which libraries, which versions ...."

          Have an upvote for that, although I'll agree to disagree with the dig at C++, it really is a different beast from Java. Your point about the language being held completely in memory is a good one - often overlooked in these days of hitting CTRL-SPACE repeatedly until you have something that will stumble through the Java/C# compiler. :)

        2. Anonymous Coward
          Anonymous Coward

          Re: Madness is doing the same thing and expecting a different outcome

          The huge advantage of C (from an open source perspective) is that it allows bottom feeding of the very lowest level denominator coders. The is crucially important when you rely on volunteer effort and can't count on people with more than the bare minimum skills. This also perhaps explains bugs like Heartbleed.

          1. BinkyTheMagicPaperclip Silver badge

            Re: Madness is doing the same thing and expecting a different outcome

            The advantage of C is portability. C++ compiler quality is *still* variable on different platforms and there's the name decoration issue. Yes, it's possible to work around it, but C is a tad simpler.

            Additionally pretty much all existing operating systems are written in C (although there are exceptions such as L4, and certain components written in C++. Windows is written in C, but some parts are realistically only usable from C++ or .NET).

            For most libraries and non low level operating system code I would use C++, but in the specific case of libraries such as OpenSSL that may be running on embedded systems with fairly severe resource restrictions this may not be realistic.

        3. Ken Hagan Gold badge

          Re: Madness is doing the same thing and expecting a different outcome

          "I am appalled at the likes of C++ or Java where, it seems, none of us can master even the full semantics of the basic language"

          In fairness to the C++ guys, the worst of the complexity results from a sincere attempt to actually describe and then remain compatible with the C subset. In no particular order, C's integer types, promotion rules, decay of arrays to pointers, lack of initialisation guarantees and (until recently) lack of a memory ordering model, have been the bane of anyone who actually wanted to write clear and safe code. Classes, namespaces, exceptions, templates and the like are pretty damn clean in comparison.

          1. Anonymous Coward
            Anonymous Coward

            Re: Madness is doing the same thing and expecting a different outcome

            How could you not mention the preprocessor?

    4. Anonymous Coward
      Anonymous Coward

      Re: Madness is doing the same thing and expecting a different outcome

      >"Writing in C"

      Can you suggest a language that A: solves all the possible programmer errors that are possible in C while running on the bare metal and not inside of a virtual machine, B: doesn't depend on libraries that are written in C, C: has a working modern portable compiler that isn't implemented in C.. oh and we need an OS that isn't mostly implemented in C to go with it.

      Or we could stop trying to blame C for programmer errors that are possible in any language that is powerful enough to actually do system level programming and accept that "humans are always going to make mistakes". The human error that caused heart bleed was actually very small and I bet that you could find similar mistakes in just about any codebase you care to look at. I would say that heartbleed doesn't show we need better languages, new TLS libraries etc. Instead I think it shows that we actually need to rethink how private keys, passwords etc are handled in memory. Should private keys be floating around in the memory of processes that are also handling connections from the outside world?

  8. akeane

    The problem is ...

    ... instead of using computers for their intended purpose i.e. playing Doom, people started hacking them to do pointless rubbish like eCommerce, storing recipes, Minesweeper and other such fripperies!

    As for blink tags, these days I suspect you would have to implement it in JavaShi^H^Hcript or Flash,

    again introducing potential security risks #sadface

    1. Anonymous Coward
      Anonymous Coward

      @akeane

      CSS supports flashing text too.

  9. Destroy All Monsters Silver badge
    FAIL

    C - the leech theraphy of coding. It will never go away!

    Let the witch doctors speak!

    C is good, very good.

    It doesn't even have Modules, FFS.

    Can you suggest a language that A: solves all the possible programmer errors that are possible in C while running on the bare metal and not inside of a virtual machine

    "I want to have FTL travel, meanwhile I will defend my Zimmer Frame equivalent of coding for no particular reason!".

    21st century: Programming applications "to the bare metal" and other retardations of the conservative or ignorants.

    You can write bullet proof code in assembler, you just need to know what you're doing.

    You also need a very large team, lots of time and lots of money in that case. Nope, you won't get them.

    C does not have the exclusive license on bad or insecure code.

    "WIth that kind of plus, we can only win."

    Code which needs to run particularly quickly and efficiently may require the use of a lower-level language, even if a higher-level language would make the coding easier

    Surprising generalities from Jimbo's Bag Of Trivia!

    Seriously, WTF? I anything being tought in schools today?

    1. E_Nigma

      Re: C - the leech theraphy of coding. It will never go away!

      Ahh, the things thought at schools these days... Reminds me of a group of graduates from my university who, straight out of uni, got themselves a job of designing and implementing a real time system. 'A' students that they were, they wrote code that was absolutely beautiful to look at, pouring all of their fresh knowledge of software design into the work. The only problem? Their beautiful, readable, maintainable OO code was nowhere near as fast as it had to be. Cue a rewrite that saw them doing everything that you "shouldn't" be doing when programming in the 21st century, and it worked.

      So horses for courses. ;)

Page:

This topic is closed for new posts.

Other stories you might like