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

 


Forgot your password?
Close
typodupeerror
×
Security BSD

FreeBSD-Current Random Number Generator Broken 105

Posted by samzenpus from the protect-ya-neck dept.
First time accepted submitter bobo the hobo writesThe FreeBSD random number has been discovered to be generating possibly predictable SSH keys and SSL certificates for months. Time to regenerate your keys and certs if using FreeBSD-Current. A message to the freebsd-current mailing list reads in part: "If you are running a current kernel r273872 or later, please upgrade your kernel to r278907 or later immediately and regenerate keys. I discovered an issue where the new framework code was not calling randomdev_init_reader, which means that read_random(9) was not returning good random data. read_random(9) is used by arc4random(9) which is the primary method that arc4random(3) is seeded from."
This discussion has been archived. No new comments can be posted.

FreeBSD-Current Random Number Generator Broken More

FreeBSD-Current Random Number Generator Broken

Comments Filter:

  • Cui bono? (Score:2)

    by Anonymous Coward

    I discovered an issue where the new framework code was not calling randomdev_init_reader

    So who was responsible for introducing that change? Let's smoke out the mole.

    • Re:Cui bono? (Score:4, Interesting)

      by MrBingoBoingo ( 3481277 ) on Wednesday February 18, 2015 @07:23PM (#49083555) Homepage
      This. So much this. When these regressions happen there are people behind them. The great value of a Linus or a Theo is shaming this people out the door. At least this was caught in -Current and not -Stable. This incident appears to be at least as much a social engineering attack as a code quality issue.
  • Wouldn't it make more sense to patch the kernel to make the correct function calls then update to a kernel with more changes that may not be tested/stable for a given usage scenario?

  • I guess this is a problem (Score:2, Funny)

    by Anonymous Coward

    According to many people on this site almost every Linux user have now switched to FreeBSD because of Systemd.

  • The -current is not a release — it is the trunk of the development tree. Using for anything important — such as data, that may be worthwhile enough for your enemies to hack for — is silly. Far worse bugs may exist in -current — or be introduced at any point.

    Stick to releases [freebsd.org] — or one of the -stable branches — for anything, that's not about working on FreeBSD itself.

    • That explains hearthstone! (Score:2, Funny)

      by Anonymous Coward

      Why do I get both my 7 mana-cost cards on my first two draws?

      Why does the best card in my hand always wind up being the card that gets discarded on random discards?

      Why is the board-clear that I need always at position 30 in the draw pile?

      It is because they built their server backend on FreeBSD!

      It is all so clear now.

  • Non-news.... Bug is in CURRENT not STABLE (Score:5, Insightful)

    by tomxor ( 2379126 ) on Wednesday February 18, 2015 @05:41PM (#49082847)
    Bleeding edge software has bugs?? what

    • Bleeding edge software has bugs?? what

      Many people run CURRENT, so if they put their pubkeys on servers they could possibly be guessable. Try reading the article next time.

      • Re: (Score:1)

        by Anonymous Coward

        What!!! you don't regen keys everyday OMFG, what is the world coming to, AHHHHHHHHHHHHHHHHHHHHHH!

        • What!!! you don't regen keys everyday OMFG, what is the world coming to, AHHHHHHHHHHHHHHHHHHHHHH!

          It's been a problem for months, I'm sure some people have generated keys in that time. Are you trolling?

      • Re: (Score:3)

        by tomxor ( 2379126 )

        Bleeding edge software has bugs?? what

        Many people run CURRENT, so if they put their pubkeys on servers they could possibly be guessable. Try reading the article next time.

        Yes they do, yes they could, no it's not news, it's on the current branch... In true BSD style i'm going to say RTFM: https://www.freebsd.org/doc/en... [freebsd.org] Current is not intended for production, end of.

  • RE:Random Number Generator Broken (Score:2, Insightful)

    by Anonymous Coward

    All of these problems will be solved when systemd integrates Rand

  • How bad was the bug? (Score:5, Funny)

    by Nonesuch ( 90847 ) on Wednesday February 18, 2015 @07:03PM (#49083429) Homepage Journal

    This seems like an odd bug to have happen, how bad were the effects? Just 'weaker' randomness, or without randomdev_init_reader do the random routines just return the same series of pseudorandom digits every time?

    Also, obligatory Dilbert reference [dilbert.com]

  • "Random" (Score:3)

    by sexconker ( 1179573 ) on Wednesday February 18, 2015 @07:07PM (#49083475)

    When blackboxed, even "return 5" is indistinguishable from a true random number generator.
    People want noisy numbers, not random numbers. Which is a good thing, because a true random number generator will never exist.

  • But it doesn't have SystemD (Score:3, Funny)

    by Billly Gates ( 198444 ) on Wednesday February 18, 2015 @08:01PM (#49083745) Journal

    So who cares??

  • Why would you expect the OS to solve your random number problem for you? It's software. It has no means to know what platform it is really running on and no means to understand the min-entropy of any input it sees. It is the wrong thing in the wrong place and it cannot 'guarantee' secure random numbers unless it gets guarantees of min-entropy sources from the hardware it runs on and uses it correctly.

    If you hardware doesn't offer a hardware RNG with specific claims for min-entropy or computational bounds on

    • Re: (Score:2)

      by spauldo ( 118058 )

      /dev/random has been part of UNIX for ages. It's part of the system, and expected to be there. The kernel developers take it seriously, because most UNIX software that needs random numbers uses it.

      If you don't trust it, that's fine, but pretty much all UNIX software uses it - and UNIX runs the 'net. Certificates are generated using it. If you want to avoid it, install Windows and unplug your internet connection.

      • /dev/random blocks on most unix derived operating systems unless you go to some measures to feed the kernel with a continuous supply of data claiming to be entropic.

        Certificates generated with software that trusts /dev/[u]random is what led us to the "Mining your Ps and Qs" problem. Google it if you aren't familiar.

        Even if you have a good source of entropy on your platform, the odds are high that neither the OS nor RNGd will use it. On some popular Linux distributions I've used, RNGd fails silently at boot.

        • Re: (Score:2)

          by spauldo ( 118058 )

          Sure, you've got good points about failures in /dev/random. Surprise, there have been problems - just like there's been problems with pretty much all code everywhere at some time.

          But what exactly do you expect kernel developers to do? /dev/random exists, and a lot of stuff uses it. It's expected to be there. Kernel developers (especially BSD developers, who tend to view UNIX much more conservatively than Linux developers) are going to make sure that the service is available and as bug-free as possible.

    • Re: (Score:2)

      by Bengie ( 1121981 )
      The OS is responsible for being a reliable source of trusted entropy. There are many ways to create strong pseudo-random numbers, some are faster than others, but all can be strong. Random numbers are a complex issue that should be implemented once and implemented well. Doing random in user land is a horrible idea and has been a reoccurring issue over the years. You also run the issue that software may not get upgraded, but the OS can. Single point of responsibility and all that jazz.

      Kind of like how it

      • >The OS is responsible for being a reliable source of trusted entropy.

        Yet it cannot possibly be that. The OS has no entropy. It is not a source of entropy. Physical processes are sources of entropy. The OS might be able to demultiplex a source of physical entropy to share it out amongst multiple processes, but as has happened time and time again, we've seen operating systems fail to do exactly that because the OS has no knowledge of whether it's inputs are entropic, and when they are not, you get data th

        • Re: (Score:1)

          by Anonymous Coward

          And yet, on many systems running many different operating systems, the OS is able to do precisely that: provide a reliable source of entropy. This is of course because many channels which only the operating system can watch do contain a lot of entropy and the operating system is able to mix the data up to create a nice random number, better than applications can. An implementation bug in a non-release version of FreeBSD does not disprove that. Furthermore, it is a given that in modern times random numbers a

          • >And yet, on many systems running many different operating systems, the OS is able to do precisely that:

            You should be concerned about the situations where it doesn't work, which are probably in the majority of Linux deployments. The people taking advantage of low entropy crypto systems don't just focus on the ones that work.

            FreeBSD isn't doing the 'wrong' thing. It's doing all it can in a bad situation. However my application code can know where to go look for well defined sources of entropy and use it

            • Re: (Score:2)

              by Bengie ( 1121981 )
              No one trusts hardware anymore. It can be used to mix with the entropy pool, but it should never be used directly.

              • The entropy is coming from nothing but hardware. Your software is running on the hardware. You typed in that post using hardware. If you don't trust the hardware, why do you think an entropy pool implemented in software will save you?

        • Re: (Score:2)

          by Bengie ( 1121981 )

          where we think the OS will solve a problem it cannot solve in the general case, is brittle and fails frequently

          If your OS is so bad that you don't trust it's entropy, then STOP using that OS. If you can't, then sucks to be you, it's a crap OS and the programmers should die in a fire.

  • Alternate strategy... (Score:3, Informative)

    by damn_registrars ( 1103043 ) <damn.registrars@gmail.com> on Wednesday February 18, 2015 @10:06PM (#49084315) Homepage Journal
    Just don't use keys for remote ssh logins. I know, keys are supposed to be all that any more. But based on my experience fending off billions of script kiddy attempts from my home system, it appears they aren't worth the effort and may even be counter productive.

    I say this because my home server faces the world and allows anyone who wants to, to make an attempt to login via ssh on port 22. You may say this is completely insane, but my logs suggest it isn't that bad. The overwhelming majority of all attempts on my system attempt to come straight in as root. As everyone knows, you can very easily disable root login in your sshd.conf file which leaves the person on the other end completely incapable of knowing whether or not they ever got your root password right as the response is the same.

    The end result is they make their 10,000+ attempts in a couple hours, then leave and never come back. They might take a few parting shots at other well known account names but they won't get in that way either.

    • Re:Alternate strategy... (Score:5, Insightful)

      by fisted ( 2295862 ) on Thursday February 19, 2015 @12:16AM (#49084869)

      my home server [runs public facing sshd] on port 22. You may say this is completely insane.

      Gasp. How extremely uncommon.

      Just don't use keys for remote ssh logins.

      What? Why?

      But based on my experience [...] it appears they [...] may even be counter productive.

      And that is why exactly? None of your post explains that or seems to have anything to do with key-based login at all.

      As everyone knows, you can very easily disable root login in your sshd.conf file which leaves the person on the other end completely incapable of knowing whether or not they ever got your root password right as the response is the same.

      As happens when key-based logins are used. Your point being?

    • Re:Alternate strategy... (Score:5, Informative)

      by ColaMan ( 37550 ) on Thursday February 19, 2015 @04:59AM (#49085763) Journal

      Sweet Jesus, at least install Fail2Ban and block an IP for 24 hours after 3 failed attempts.

      • This guy is the low hanging fruit that keeps all those automated attacks from China from developing something more sophisticated :P Not that i'm suggesting security through obscurity is the only way or anything... just an extra line of Darwinian defence.

      • Re: (Score:1)

        by Anonymous Coward
        I prefer sshguard. Way faster and simpler to use.

  • I have never seen a bunch of Linux users get so excited over a bug in a development branch before.

  • This is a DEVDELOPER SNAPSHOT (Score:3)

    by gweihir ( 88907 ) on Thursday February 19, 2015 @04:33AM (#49085661)

    As apparently nobody bothered to find out, this is a bleeding-edge developer snapshot, not anything that was in any way "released", hence no normal users are affected.

    I do have two questions though:
    1. Why was that code touched in the first place?
    2. Who touched that code and broke it?

    It may be simple incompetence (it usually is), but it may also be a mole in the FreeBSD project. It should be ascertained that the person that did this did so in good faith. Still, some level of shaming is required even then to make people pay attention when they touch security-critical code and keep their fingers off it unless they have the required level of skill and understanding and there is actually a real need to touch that code.

    • The "code was touched" in order to bring some new features in. Here is the commit for that branch to /dev/random r 273872 [freebsd.org]

      This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.

      This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven

      • Re: (Score:2)

        by gweihir ( 88907 )

        Excellent. This is a completely satisfactory explanation.

        I still hope the people involved have learned to be extra careful with /dev/urandom, as it can break so very many things in ways that are not readily obvious. Unfortunately, problems with CPRNGs that break the security of applications and systems have a long history and people working on these need to be reminded time and again of that.

        Anyways, thanks for the info!

  • Do you mean to say that the tool behind the die roller for my D&D characters is all wrong?

    I have to re-roll my characters all over again!

Slashdot Top Deals

If all else fails, lower your standards.

Close