Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

More proof that crypto should be left to the experts

More proof that crypto should be left to the experts

  • Comments 41

Apparently two years ago, someone ran a static analysis tool named "Valgrind" against the source code to OpenSSL in the Debian Linux distribution.  The Valgrind tool reported an issue with the OpenSSL package distributed by Debian, so the Debian team decided that they needed to fix this "security bug".


Unfortunately, the solution they chose to implement apparently removed all entropy from the OpenSSL random number generator.  As the OpenSSL team comments "Had Debian [contributed the patches to the package maintainers], we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."


And it IS a terrible idea.  It means that for the past two years, all crypto done on Debian Linux distributions (and Debian derivatives like Ubuntu) has been done with a weak random number generator.  While this might seem to be geeky and esoteric, it's not.  It means that every cryptographic key that has been generated on a Debian or Ubuntu distribution needs to be recycled (after you pick up the fix).  If you don't, any data that was encrypted with the weak RNG can be easily decrypted.


Bruce Schneier has long said that cryptography is too important to be left to amateurs (I'm not sure of the exact quote, so I'm using a paraphrase).  That applies to all aspects of cryptography (including random number generators) - even tiny changes to algorithms can have profound effects on the security of the algorithm.   He's right - it's just too easy to get this stuff wrong.


The good news is that there IS a fix for the problem, users of Debian or Ubuntu should read the advisory and take whatever actions are necessary to protect their data.

  • What if your whole business was about trust. More specifically, what if your entire business was about providing a long number (very long) to companies so nobody knows that number except you and the company. And then, suddenly you find out that the number

  • Where were your security when MS Blast infected millions of Windows copies around the world?

  • Tom, Blaster (and Sasser) were the tipping points that caused Microsoft to rethink the way we shipped software.

    You'll note that there hasn't been a significant internet worm since Blaster - that's because of the work that MSFT did.

    Yes, we came to the game late, but we get it.  And our current track record by any reasonable measurement is dramatically better than any of the other platforms out there (either OS or application).


    IE7 has more unpatched security vulnerabilities than any other web browser (with the exception of IE6, which has 117 unpatched vulnerabilities). The windows server OS has more unpatched vulnerabilities than any OS with the exception of Linux and Solaris.

    I believe that Microsoft has come around in the area of security, and I've run many different windows based servers without incident since the Code Red worm; including NT 4, 2000, and 2003 systems. However, the fact that you chose to knock Linux to prove your point about the delicateness of crypto code (and not-so-subtlely bashing OSS in the process), gives me even more reason to believe that Microsoft is a cult. I've worked with coders who were trained in Redmond, and its amazing how closed minded they were.

    If you want to talk about leaving crypto to the experts, why not start with what's closest to you: (I especially like this one.. error released in a patch that had to be re-patched. Sound familiar?)

  • IMHO I wasn't "picking on linux".  I was picking on a team that mucked around with code where they shouldn't have and introduced a potentially catastrophic security hole because of it.  It happens that it was a Linux distribution, but that's irrelevant, I would have picked on MSFT if we'd made such a boneheaded mistake in recent history.

    About those "crypto" vulns you pointed to.  The first link wasn't a crypto vuln, but instead was the fact that cryptoapi's certificate validation logic could be tricked to attempt to validate certificates against arbitrary hosts.  No question it's a bug but it had nothing to do with crypto.

    The other two you picked were fixed 6 and 8 years ago (long before the trustworthy computing initiative).  Ancient history.

  • The main issue here is that OpenSSL team didn't document use of uninitialized memory in their code.

    Code comments are abused nowadays to state stupid and obvious things like:

    a *= 2; // we multiply a with 2

    But it is obviously too much to ask for:

    // NOTE: We are using this memory without initialization on purpose

    If the OpenSSL code was properly documented Debian maintainers wouldn't make such a mistake.

    You are barking up the wrong tree Larry.

  • >You'll note that there hasn't been a significant internet worm since Blaster - that's because of the work that MSFT did.

    I wouldn't give you all the credit for that -- most likely it was because people started using third-party statefull inspection capable firewalls.

  • Igor, you're wrong.  The reason we've not had a significantworm since Blaster is because SP2 enabled the built-in firewall on hundreds of millions of machines.  

    There isn't enough market share for 3rd party firewalls to even come close to matching the installed base of XP SP2 machines.

  • Btw, you're wrong.  The problem wasn't the comments.  The OpenSSL team has said that removing the use of uninitialized memory wouldn't actually make a difference.  The problem was that the Debian developer went and removed a 2nd line of code that DID have cryptographic significance.

  • >There isn't enough market share for 3rd party firewalls to even come close to matching the installed base of XP SP2 machines.

    Really? What about all those SP2 machines which had that same firewall disabled and even uninstalled clean by the viruses and malware?

    Let me tell you about Blaster days -- I had XP with firewall enabled and I was online via dial-up when Blaster hit me. Machine rebooted and I removed it manually from DOS before booting into Windows again. Then I reconnected and I somehow managed to stay online long enough to find a fix. Windows Firewall didn't help a single bit.

    Since then I used 3rd party statefull inspection firewalls until I got broadband. Then I completely disabled and uninstalled all firewalls and delegated the protection to the NAT on my router.

    Truth is that many broadband Windows XP users are safe because of NAT and not because of Windows built-in Firewall because that firewall is a joke.

    >Btw, you're wrong.  The problem wasn't the comments.

    I never said that the problem was the comments but the lack of them.

    My point was that non-obvious things in source code (a.k.a. nasty tricks or "clever" hacks) should be properly documented especially if the code is open-sourced.

    I sometimes can't remember why I did something the way I did in my own code, so I don't expect others to understand. That is what comments are for.

    Here is an example (error checking removed):

    // Get supported OpenGL extensions from a display driver

    const GLubyte *ext = glGetString(GL_EXTENSIONS);

    int len = strlen((char*)ext);

    GLubyte *buf = (GLubyte *)malloc(len);

    RtlCopyMemory(buf, ext, len);

    // WARNING! extension string is returned by driver

    //          and it may reside in read-only memory

    //          that is why we need to copy the string

    //          before tokenizing it

    // WARNING: strstr() would not work because some

    //          extension names are subset of another

    //          longer extension name

    char *p = strtok((char*)buf, " ");

    while (p != NULL)


    // ...


    This is an example of what you should do when you expect that someone could play smart and try to "improve" your code.

  • Everyone has to do their best work. Learn new technology if someone want. Developers can write cryptography code to train thyself but do not publish this code.

Page 3 of 3 (41 items) 123