Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Security Software Linux

LibreSSL PRNG Vulnerability Patched 151

Posted by Soulskill
from the looking-forward-to-the-next-two-day-panic dept.
msm1267 writes: The OpenBSD project late last night rushed out a patch for a vulnerability in the LibreSSL pseudo random number generator (PRNG). The flaw was disclosed two days ago by the founder of secure backup company Opsmate, Andrew Ayer, who said the vulnerability was a "catastrophic failure of the PRNG." OpenBSD founder Theo de Raadt and developer Bob Beck, however, countered saying that the issue is "overblown" because Ayer's test program is unrealistic. Ayer's test program, when linked to LibreSSL and made two different calls to the PRNG, returned the exact same data both times.

"It is actually only a problem with the author's contrived test program," Beck said. "While it's a real issue, it's actually a fairly minor one, because real applications don't work the way the author describes, both because the PID (process identification number) issue would be very difficult to have become a real issue in real software, and nobody writes real software with OpenSSL the way the author has set this test up in the article."
This discussion has been archived. No new comments can be posted.

LibreSSL PRNG Vulnerability Patched

Comments Filter:
  • by Anonymous Coward

    That's not how you're suppose to hold the phone.

  • by Jonathan C. Patschke (8016) on Wednesday July 16, 2014 @03:45PM (#47470147) Homepage
    Q: What do we call "contrived test programs" in the "real" word?
    A: Exploits.
    • by jandrese (485) <kensama@vt.edu> on Wednesday July 16, 2014 @03:52PM (#47470217) Homepage Journal
      To exploit this, you needed a program that was written like so:
      1. Grandparent initializes SSL state, sends some data, then exits.
      2. Parent forks a child
      3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.

      It's a program structure that doesn't make a whole lot of sense in the real world. Maybe it has happened somewhere.

      The big issue is that the original discoverer found an easily filled molehill and somehow it got reported as a world destroying volcano across the the various tech sites. A minor flaw in the first public release of the test version of a library with no production users is not "catastrophic".
      • by asmkm22 (1902712)
        Seems like the type of thing a malware author would design around in order to take advantage of a security flaw.
        • by QuietLagoon (813062) on Wednesday July 16, 2014 @06:54PM (#47471503)
          The LibreSSL developers apparently agreed that it was a bug that should be fixed, and fix it they did.

          .
          The discussion seems to center more around whether or not this was a "catastrophic" bug, or a "minor" bug. A bug in a library that has not yet seen a production release. So one really should ask, why not just report the bug and have it fixed, instead of seeking headlines?

          There seem to be some people who would like to see the LibreSSL project fail. It makes one wonder why, as the OpenSSL near-monoculture has served the world so well.

          • by asmkm22 (1902712)
            I don't know about people wanting it to outright fail, but I do agree there are lots of people that don't see the point in forking it. They feel like it's a fork for the sake of being a fork. And like it or not, there's a whole history of open source and linux forks that do nothing but fragment things (people, distros, development, etc). A guy heavy in the Linux field once said something to the effect of "If it's not broken, don't fix it. But if it is broken, fix it. Just don't fork it unless you reall
            • by serviscope_minor (664417) on Thursday July 17, 2014 @04:17AM (#47473295) Journal

              I don't know about people wanting it to outright fail, but I do agree there are lots of people that don't see the point in forking it.

              At some point people are going to form opinions no matter what really and nothing will convince them that a fork is OK. In this case, the combination of bugs hanging around in RT for years (to the point where there were already unofficial distro forks with the bugs fixed) and the add-new-features-and-never-clean and the FIPS requirements meant that the OpenSSL end of things had reached the end of the line.

              Kind of like Xorg versus XFree86.

              I think this was one of the ver much "had to" cases.

              And in the intervening time, libreSSL has done substantial rewrites, cleaned many things and fixed many previously hidden bugs, got it working on OpenBSD and made it portable. Meanwhile over in OpenSSL land, the Linux foundation signed on a lot of corporate sponsors who splattered logos all over a page, made announcements and meybe even appointed someones, and the OpenSSL people fixed a couple of bugs and posted a roadmap.

              So, I would say this is one of the justified times.

      • In this particular case, yes. There will always be non-exploitable bugs.

        The problem is that when you begin to dismiss bugs as non-exploitable (whether you've fixed them or not) and their reports as "overblown," you put yourself in the unfortunate position of only needing to be wrong once. Specifically, dismissing bug reports with the notion that the bug would never be exploitable—not because the bug is "beyond the airtight hatchway," but because no one would be dumb enough to write an application in

        • by Dishevel (1105119) on Wednesday July 16, 2014 @05:33PM (#47470983)
          What they did though was point out that the bug has almost no ability to really be exploited and then fixed it anyways.

          I thought they did quite well.

      • Is there no other way for it to be exploited? Is that contrived example the easiest way to demonstrate it, or is it provably the ONLY way to exploit it?

      • by Qzukk (229616) on Wednesday July 16, 2014 @06:15PM (#47471281) Journal

        OpenSSL's RNG is used in many places separately from the SSL communication protocol itself, sometimes just for encryption in general (S/MIME) or sometimes someone just wants really random bytes.

        Many servers fork twice in order to reparent to init, repeated forking is a common idiom in unixland.

        Apache with MPM-prefork forks a bunch of children from a master process, which is typically itself a descendant of apachectl. In apache's case, this shouldn't be a problem since the "master-process-rng" would have recognized the fork and reinitialized on the first openssl connection, so the children are protected because they cannot have the same PID as the master-process.

        Where it would be a problem would be an application or daemon that starts up, initializes the RNG, forks twice, then without this fork touching the RNG, starts forking children to do something random (say, encrypting one file per process or establishing a single SSL connection per process or something). Without having the RNG reset by the master process, one in 65534 or so processes will have the exact same RNG, because it will have inherited the original RNG untouched and be assigned the PID that created the RNG.

        • by jandrese (485)
          Only if the master process quit after forking twice. This is not typical, since most of the time people will leave the master process around to clean up after the children to avoid zombies. It's such a strange case I think you would be hard pressed to find a real world application that behaved in a way that made it vulnerable to this exploit. I'm glad the OpenBSD guys got a patch for this, but even if they didn't I woudln't be losing much sleep over it.
          • by Qzukk (229616)

            Only if the master process quit after forking twice. This is not typical

            No, this IS typical. The double fork allows the original process to interact with the user ("Enter your private key password:"), then exit and return 0 to the init script so init can print [ OK ] on your console.

            The middle process needs to close file descriptors and do other cleanup then fork and die, causing the final process to become re-parented to init. Init then becomes responsible for cleaning it up if it dies, so it won't becom

      • by gnu-sucks (561404)

        It's not a minor flaw. Getting the same PID causes the same random numbers to return, that is a major flaw and something I would not have expected from an OpenSSL fork.

        They might as well have written it in bash(ie, RANDOM=$$, seeds the random number generator with the current PID), this is ridiculous. It should be HARD to get the same random number twice.

        It's a good thing nobody uses this yet.

        • by Bengie (1121981) on Wednesday July 16, 2014 @08:29PM (#47471941)
          It's not a flaw in LibReSSL, it's a flaw in the portability layer that only happens in non-OpenBSD OSes with situations where the sysadmin blocks access to /dev/urandom like a tard. The only reason the portability implementation even supports this fall-back is because there are a lot of stupid sysadmins using OpenSSL and LibReSSL needs to be as much a drop-in replacement as possible. It's a flaw in the bandaid for a situation that shouldn't happen, but does.
          • where the sysadmin blocks access to /dev/urandom

            Why would they do that

            • by Anonymous Coward

              Presumably for the same reason that they would block "ICMP would fragment", aka "the packet you are trying to send is too big to pass on, and you've told me not to split it in two, so pleasy try again with a smaller packet, as I'm giving up on this one", causing downloads of over 1400 bytes to fail when the other end is behind a VPN.

              I.e. because they are morons.

          • by serviscope_minor (664417) on Thursday July 17, 2014 @04:21AM (#47473305) Journal

            I'm of the opinion that it should crash hard and loundly if it can't open a system PRNG of some sort.

            I think If "fix your OS" is the OpenBSD approach to broken OSs (rather thantrying to work around) then "fix your sysadmin" should surely be the approach to broken sysadmins.

      • by kesuki (321456)

        1. Grandparent initializes SSL state, sends some data, then exits.

        grandma uses aol.

        2. Parent forks a child

        mother marries has a kid

        3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.

        child has same name as grandma uses aol gets into grandma's account.

        it makes a whole lot of sense in the real world. the world where it doesn't make sense is an artificial environment where names aren't ever allowed to be reused.

        okay so maybe names wasn't the best choice perhaps telephone nu

      • 3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.

        That sounds really hard to exploit

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      His point was obviously that you couldn't accidentally write a program to exploit the flaw and that this exploit does not mean that all software using OpenSSL is vulnerable to the exploit as was the case with heartbleed. In fact, this flaw only means that your encryption is weak if you 1) decide to use LibreSSL in your software and 2) decide to intentionally break LibreSSL in your software. The end result is then weak encryption.

  • by gnasher719 (869701) on Wednesday July 16, 2014 @03:54PM (#47470247)
    This is not a problem where an outside attacker can successfully attack the software. It is a problem where a malicious developer can attack his or her own software. So the vulnerability is not that an attacker can shoot at me with a gun, the vulnerability is that I can use my own gun to shoot myself in the foot. But only if I construct a clever framework that causes the anti-shoot-in-the-own-foot measures provided by the gun to be blocked.
    • by sinij (911942)
      Incorrect. If your PRNG is garbage, all crypto is also garbage.

      A car analogy - if I know where and when you started driving I can make fairly accurate guesses of your location without having to rely on GPS tracking.
      • by Noryungi (70322)

        Incorrect. If your PRNG is garbage, all crypto is also garbage.

        A car analogy - if I know where and when you started driving I can make fairly accurate guesses of your location without having to rely on GPS tracking.

        That is absolutely right, but I will note right away that this is a problem specific to the Linux PRNG - OpenBSD does not have this vulnerability (also, because PIDs are randomized under OpenBSD)...

        • by sinij (911942)
          Ok, so best-case scenario is that OpenBSD has additional sources of randomness and that issue simply weakened crypto instead of outright breaking it.

          For ignoramus that downmoded my GPP - all cryptographic functions heavily rely on random numbers being both unpredictable and computationally indistinguishable from true random. It can break two ways - first by broken seeding, where it becomes predictable. Second by having algorithm that has non-uniform (e.g. some numbers have higher chance than 1/u). Both of
    • by gnu-sucks (561404)

      Or a bad developer that assumes the PRNG is "good".

  • by Anonymous Coward

    fixed a condition that was highly unlikely to be able to be exploited in real world conditions and made a big deal out of it. Just fix it and move on, the 'While at first glance this only appears to be a major issue" is something I expect to hear from other camps.

    • by 0123456 (636235)

      But they have apparently 'fixed' the code that allowed a developer to ensure this never happened... by making it a no-op.

      • What a whole lot of people seem to want from LibreSSL is to behave in every little bit EXACTLY as OpenSSL does, even though OpenSSL itself is a complete and utter mess.

        OpenSSL allowed developers to interfere with RNG, so LibreSSL must do that, too?

        Well, you can't really go at improving and cleaning up the library if you have to keep all the old bugs and the whole crusty API around.

        It's inconceivable to expect LibreSSL to be both better than OpenSSL, yet to have the exact same API and the exact same set of b

        • by gnu-sucks (561404)

          It's not an edge case. The random number generator should not be seeded only by a PID.

          Hello Theo, the 1970s called, they want their random number generator back...

          • by Carnildo (712617) on Wednesday July 16, 2014 @09:52PM (#47472309) Homepage Journal

            The random number generator should not be seeded only by a PID.

            The PID is used as an absolute last-ditch fallback in the case that no other sources of randomness are available. In order for this to happen, /dev/urandom needs to be inaccessible, the KERN_RANDOM sysctl needs to be unavailable, gettimeofday() needs to fail, and clock_gettime() needs to fail.

            If you're running on a system that crippled, you've really only got two choices: try seeding using the PID, or use an unseeded RNG. Or follow Theo's advice and get yourself a real operating system.

            • by Anonymous Coward

              Fourth choice: crash the system. "We must protect the data, but if we can't, we must send it anyway" is not a good security model.

  • by Kardos (1348077) on Wednesday July 16, 2014 @04:22PM (#47470483)

    > The OpenBSD project late last night rushed out a patch ...

    Sensationalist introductory sentence. LibreSSL is is not used in any production environment, there is no "rush" here.

    It is an early version released to solicit feedback. Feedback was provided, resulting in a bug fix. This is *exactly* anticipated outcome.

    • by maliqua (1316471)

      I'd say this is almost a best case scenario even, so far the only bug found was one that could not easily exploited. and it was patched, the response from Beck was by OpenBSD standards, tactful.

      • by Noryungi (70322)

        I'd say this is almost a best case scenario even, so far the only bug found was one that could not easily exploited. and it was patched, the response from Beck was by OpenBSD standards, tactful.

        For different values of "tactful", of course... ;-)

  • Not an expert in OS design details, but I'm quite surprised there exists an OS which newly hands out the same PID a very recent process had. Do not PIDs monotonically increase until they wrap around? If not, why not? And why are they not based on adequately large integers? 32 bits for a minimum; why not 64? Yeah, it will uglify a ps display, but eyes on the security ball here. My 64-bit Arch linux on kernel 3.15 is saying 15 bits (cat /proc/sys/kernel/pid_max = 32768).

    For that matter, Is there any reason no

    • Not an expert in OS design details, but I'm quite surprised there exists an OS which newly hands out the same PID a very recent process had. Do not PIDs monotonically increase until they wrap around?

      The suicide candidate (he is not an attacker, the damage is entirely self-inflicted) intentionally created 65,534 other processes in between.

    • The design is requiring the PID to not just be unique, but to be unpredictable. So after untangling the cords, you end up with the same requirement on your PID as you have on your RNG. Therefore the RNG design is wrong.

      • by Anonymous Coward

        FWIW, grsecurity (a patch for the Linux kernel) implements random-seeded PRNG-based unpredictable PIDs.

    • by nedlohs (1335013)

      It's a program tthat exits the grand parent process and then forks in a loop until it happens to get the same process id as the grand parent. Which is of course something that will never happen in a real program. Expanding the size of the pid will just make it take longer.

      You can always "echo 4194303 > /proc/sys/kernel/pid_max" on linux if you want to wait longer for said program - though you will break old binaries though...

    • by Noryungi (70322)

      Precisely - which is why PIDs are randomized on OpenBSD since... well, a long long time.

      Try "ps -auxwww" on, say, Mac OS X and OpenBSD and the difference is truly evident.

  • Sure, needs to be fixed, but it it not going to happen in most situations and an attacker that can provoke it already can do far worse. That said, a competent user of LibreSSL will reseed after a fork anyways. You can do only so much for the incompetent ones.

    • by maevius (518697)

      From the disclosure:

      The difference is that OpenSSL provides a way to explicitly reseed the PRNG by calling RAND_poll. LibreSSL, unfortunately, has turned RAND_poll into a no-op (lines 77-81). fork_rand calls RAND_poll after forking, as do all my OpenSSL-using programs in production, which is why fork_rand is safe under OpenSSL but not LibreSSL.

      Just sayin'....

      • by gweihir (88907)

        The OpenSSL docu says "Be careful when deferring to RAND_poll on some Unix systems because it does not seed the generator." As far as I can see, RAND_poll() is not mentioned in the official OpenSSL interface definition at https://www.openssl.org/docs/c... [openssl.org] at all, so it is more of an internal, hidden function, and should not be used by the library user. It is mentioned on http://wiki.openssl.org/index.... [openssl.org], but with the clear warning above. Also note that it says "OpenSSL will attempt to seed the random numbe

  • LibreSSL prng vulnerable to psyops.

Hold on to the root.

Working...