back to article Whoops! Tiny bug in NetBSD 6.0 code ruins SSH crypto keys

The brains behind NetBSD have warned a bug in the open-source OS creates weak cryptographic keys that can be cracked by attackers. Users attempting to secure sensitive communications, such as SSH terminal connections, using the dodgy keys could be easily snooped on and their data decrypted. The use of a cryptographically …

COMMENTS

This topic is closed for new posts.
  1. Destroy All Monsters Silver badge
    Flame

    CPU-integrated hardware RNGs when?

    1. Anonymous Coward
      Anonymous Coward

      And if/when they discover a similar weakness in a CPU-integrated hardware RNG it will affect every OS using the CPU.

      1. Destroy All Monsters Silver badge
        Flame

        Also, when french-propelled cows fall from the sky they may land on your valet.

        Seriously, the tests on these pieces of kit are pretty good and not at webmonkey level.

        Behind Intel's New Random-Number Generator

        1. Destroy All Monsters Silver badge
          Pint

          The trivial thought came to me while on the karzy that, if additional trust is needed, one can just XOR the bits from the hardware RNG and the software RNG. Then both have to be foobared pretty seriously to give a compressible result.

    2. Robin Bradshaw
      Thumb Up

      Hardware RNG's are already here

      My VIA eden based home webserver (ok its actually a recycled thin client) has this feature allready as well as hardware accelerated AES and RSA. See cpuflags: rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en

      1. Destroy All Monsters Silver badge
        Holmes

        Re: Hardware RNG's are already here

        Id didn't know about the VIA implementation. Since January 2003, too.

        So what's keeping the others?

        You can also buy pricey add-on cards, I see.

    3. Ru

      It is entirely possible to use a hardware RNG as a source of entropy and yet still completely balls up your key generation. Hardware support for encryption and decryption is not the same as hardware key generation, incidentally.

      A cursory search turns up a netbsd bugreport from 2006 talking about a driver for an intel hardware RNG. It may be reasonably assumed that the project has hardware RNG support since that time, but I'm entirely too lazy to verify this. Certainly other BSDs and *nixes have supported such devices for some time.

      1. Nigel 11
        Alert

        Don't virtually all PCs have a hardware RNG these days? Although it's rarely used as such. It's the integrated audio system.

        Rack up the gain on the microphone input and you'll hear noise generated by the switching of other electronic systems in the box. (Even better if a mic is connected and you pick up external noises). It shouldn't be hard to generate a fairly random number from a second's worth of samples thereof. It may not be good enough for crypto on its own, but XORing it with a "good" random number cannot make it any less good.

        1. This post has been deleted by its author

          1. Nigel 11
            Thumb Down

            You don't need anything radioactive! A noise diode is quite good enough.

          2. Blain Hamon
            Coat

            a built-in radiation source and Geiger counter RNG

            I tried that once, but then /bin/cat would die about half the time.

            1. jake Silver badge

              @Blain (was:Re: a built-in radiation source and Geiger counter RNG)

              /dev/whippet thinks that putting t'cat in t'bin is a good idea.

          3. JassMan Silver badge
            Trollface

            @Larry F54

            IMHO radiation generated random numbers are only suitable for a small batch produced in a relatively short time. OK many isotopes have an extremely long half life but they all have a half life. By definition this means that the output of the generator is "coloured" and therefore not truely random.

          4. RW
            Boffin

            You win the prize. All other so-called random number generators are only pseudo-RNGs.

            This is a well-known fact that is unfortunately not as well known as it should be.

    4. h3

      What a useless article - doesn't say whether it affects 6.1-RC? or 6.0.1

  2. Longrod_von_Hugendong
    Happy

    At least...

    1) We are told about it

    2) There is a patch.

    Unlike another company(s) i could mention, that wouldnt tell you and release a patch 6 months from now once a load of machines are compromised.

  3. Anonymous Coward
    Anonymous Coward

    Not the first time.

    http://linuxhaters.blogspot.com/2008/05/gcc-opensslc-fno-random-seed.html

    "You see, opening your source code leads to more eyes looking at your code. Yes. But leaving the distribution tasks to, well, distributions, means there are also more hands (and guys, admit it, more dicks) to fuck your code up. I gotta give it to this Slashdot commenter who correctly stated: this is SSL with muppet extensions."

    http://it.slashdot.org/story/08/05/13/1533212/debian-bug-leaves-private-sslssh-keys-guessable

    1. Anonymous Coward
      Anonymous Coward

      Re: Not the first time.

      The OpenSSL bug in Debian was an interesting one. The package maintainer "fixed" the code based on the output of a static analysis tool that warned about a dodgy looking bit of code. The code was doing something that ordinarily is a no-no, but in this case it was being done deliberately. Unfortunately, the original author of the code hadn't seen fit to put in a comment stating why this was being done. So I'd argue it was ultimately a failure of the original author of the code, as dong tricksy shit like he or she did is only ever permissible if it's well documented.

      1. Anonymous Dutch Coward
        WTF?

        Re: Document your tricksy shit?

        Well yes and no.

        If you're messing with crypto code you'd better know what you're doing in the first place. Removing something because a static code generator says so says more about the guy removing it than the quality of the comments.

        That said, commenting never hurts and yes, it will perhaps prevent the same mistake.

        1. Philip Hands

          Re: Document your tricksy shit?

          Also, Kurt (the maintainer in quesion) did ask about whether it was a good idea to "fix" said tricksy shit, on the openssl-devel mailing list, and recieved only positive noises in response.

          It was later revealed that the OpenSSL developers generally don't read their -devel list, because it's too noisy, and instead hang out elsewhere -- feel free to make your own judgements about the overall wisdom of that, and how to allocate the blame arising from the Debian patch.

        2. Anonymous Coward
          Anonymous Coward

          Re: Document your tricksy shit?

          If you're messing with crypto code you'd better know what you're doing in the first place.

          It didn't really reflect on the maintainers knowledge of crypto coding - the original author of the code was doing something frankly stupid that relies on an assumption that uninitialised data will provide additional entropy. Nothing in the C standard precludes an implementation scrubbing freed memory, and I've worked on a platform that does exactly that by zeroing it out.

          1. Anonymous Coward
            Anonymous Coward

            Re: Document your tricksy shit? - Chris Wareham

            You've worked on MULTICS?

          2. This post has been deleted by its author

          3. This post has been deleted by its author

        3. Anonymous Coward
          Joke

          Re: Document your tricksy shit?

          "That said, commenting never hurts and yes, it will perhaps prevent the same mistake."

          As some wise person once said, "Real programmers don't comment their code. It was hard to write, it should be hard to understand."

          ;)

          1. jake Silver badge

            Seen in a five page bit of in-line assembly language, kernel code, K&R C, circa 1985

            * I don't remember exactly why I wrote this shim, nor what it does

            * It was late, I had several beers ... you've been there, admit it

            * But don't change it or everything else breaks!

            It's been in my personal `fortune` file since I first ran across it :-)

  4. PyLETS
    Go

    RNG quotation

    "Random numbers should not be generated with a

    method chosen at random." Donald Knuth

    Source: https://www.random.org/quotations/

    1. Stoneshop Silver badge

      Re: RNG quotation

      http://xkcd.com/221/

      1. This post has been deleted by its author

  5. Chavdar Ivanov
    WTF?

    So what?

    I have been running NetBSD since the halcyon days of 1.5... There is hardly a better bunch of OS developers out there, usually responding within the hour on one of the lists. My impression is that anyone who uses NetBSD in production keeps an eye on the discussions, especially security advisories. Patching is trivial. I very much doubt there was even an attempt to use this, let alone to succeed. One could argue that OEMs using NetBSD as a platform would suffer more in providing the firmware updates to their systems, but I'd suggest that these still use mostly NetBSD 5 and earlier, so it is unlikely many have been affected.

    This is not the first security advisory related to NetBSD, but probably the first to attract such an attention. Move over.

    And yes, I run -current only, it has been extremely stable for me for a code in constant development (it fluctuates, of course, one has to be careful with the 'sysupgrade auto' bit and do it after certain testing).

    1. Anonymous Coward
      Anonymous Coward

      Re: So what?

      I've been running NetBSD since 1.3, and it certainly is a great platform both code and community wise. 1.5 was definitely a sweet spot for me as well, although the release with the second threading implementation was an impressive one with regard to performance gains.

  6. John Smith 19 Gold badge
    Flame

    Every f**king time its the random number generator.

    This IIRC is not the first time some network protocol relied on a number being "random" and it turned out it was not.

    My instinct is despite it being an active research topic since the 1950s implementing the research is demanding and easily FUBAR'd.

    Let me suggest that a)If you're implementing one and you do some tricky possibly non portable, possibly inefficient (but essential to algorithm correctness) thing you document it.

    In the space shuttle flight software code they called these "alibis." If it's good enough for maintaining life threatening computer code it's good enough for you.

    If you're reading it don't change it unless you really understand what's going on.

  7. Peter Mount
    Boffin

    Raspberry Pi

    Apparently the CPU used in the PI has a hardware RNG. Back in February they added kernel support for it:

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=19334&p=277747#p277747

    it sounds like it uses a thermal entropy source.

  8. Benchops

    Not just your key

    If this is anything like the Debian -> Ubuntu key problem a few years back then it's not just your ssh key you need to change. You NEED to make sure that you trawl round all accounts where you put your public key in the authorized_key[2] file as /that/ is where the attackers will get in with a predictable key.

    1. Daniel Palmer

      Re: Not just your key

      Debian supplied blacklist packages so that known insecure keys couldn't be use to autheticate.. other distros/system admins could have implemented those blacklists too if insecure debian keys was a major problem for them.

    2. Anonymous Coward
      Anonymous Coward

      Re: Not just your key

      The bug only affects things very soon after boot. This is a problem for any autogenerated keys on boot (e.g. ssh host keys) before much entropy has been gathered-- the system should have waited until enough entropy was available to generate the keys, but instead it waited only until 32 bits of entropy were available. Your ssh user keys are probably ok if you did anything interactive before using them-- interaction provides entropy.

  9. ian 22
    Unhappy

    Brilliant

    "Random numbers to important to be left to chance"

    Dear Sir, you owe me a keyboard.

  10. Herby Silver badge

    Just remember...

    Some state lotteries here in the USA use computerized "random" numbers to generate the draws.

    So, "Random numbers for fun" takes on a whole new meaning!

  11. asdf Silver badge
    Trollface

    wow dodged a bullet

    Glad this happened to NetBSD and not to one of the important BSD's people actually use like DragonFly BSD, FreeBSD or OpenBSD.

    1. Anonymous Coward
      Anonymous Coward

      Re: wow dodged a bullet

      Better check your routers, set top boxes and other devices with similar capabilities. A lot of them run NetBSD, including things such as wireless access points from a certain fruity firm (I know one of the NetBSD contributors who was contracted to work on them).

      1. asdf Silver badge
        Trollface

        Re: wow dodged a bullet

        >Better check your routers, set top boxes and other devices with similar capabilities.

        Router - Linux based Gargoyle firmware (pretty solid too), would like to run OpenBSD but too much of a pain to setup (if even possible) on the standard gaming commodity router I own.

        Directv setup top box might be running it though for all I know. That might explain why its so laggy. Pretty much everything else with internet access in my house is certainly not running NetBSD.

  12. southpacificpom
    Devil

    NetBSD - it runs on anything...

    The "NetBSD Toaster" takes on a whole new meaning...

  13. Chavdar Ivanov
    Thumb Up

    Further development... the fix that wasn't.

    Apparently it turned out the fix was incorrect... Subsequent analysis is even more entertaining, see

    http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc

    (especially the tls@ credit - "... for causing, finding, "fixing", and fixing the bug

    and helping with this advisory.").

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019