Slashdot Mirror

← Back to Stories (view on slashdot.org)

LibreSSL PRNG Vulnerability Patched

Posted by Soulskill on 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."

27 of 151 comments (clear)

  1. You're holding the phone wrong by Anonymous Coward · · Score: 2, Funny

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

    1. Re:You're holding the phone wrong by maliqua · · Score: 4, Insightful

      more like "I see your using the phone in a way we hadn't anticipated though we don't think thats the best way to use the phone we'll make the appropriate changes to ensure its safe for you to use in this manner"

  2. This is not how you inspire confidence by Jonathan+C.+Patschke · · Score: 5, Insightful

    Q: What do we call "contrived test programs" in the "real" word?
    A: Exploits.

    --
    Pining for the days when The Glorious MEEPT!!! graced SlapDash with his wisdom.
    1. Re:This is not how you inspire confidence by jandrese · · Score: 4, Interesting

      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".

      --

      I read the internet for the articles.
    2. Re:This is not how you inspire confidence by Anonymous Coward · · Score: 2, Interesting

      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.

    3. Re:This is not how you inspire confidence by viperidaenz · · Score: 4, Insightful

      Hang on, if you've already injected your own code on the system you want to exploit, why both trying to exploit the PRNG? You can do pretty much anything you want.

    4. Re:This is not how you inspire confidence by Jonathan+C.+Patschke · · Score: 2

      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 a particularly boneheaded way discounts decades of examples of people writing software in amazingly boneheaded ways.

      Whether it's true or not (and, in this case, it seems true), this is not a way to inspire confidence, and an SSL implementation needs every bit as much community confidence as it does technical correctness.

      --
      Pining for the days when The Glorious MEEPT!!! graced SlapDash with his wisdom.
    5. Re:This is not how you inspire confidence by Dishevel · · Score: 4, Interesting
      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.

      --
      Why is it so hard to only have politicians for a few years, then have them go away?
    6. Re:This is not how you inspire confidence by Qzukk · · Score: 4, Informative

      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.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    7. Re:This is not how you inspire confidence by QuietLagoon · · Score: 4, Insightful
      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.

    8. Re:This is not how you inspire confidence by gnu-sucks · · Score: 2

      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.

    9. Re:This is not how you inspire confidence by Bengie · · Score: 4, Informative

      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.

    10. Re:This is not how you inspire confidence by serviscope_minor · · Score: 3, Insightful

      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.

      --
      SJW n. One who posts facts.
    11. Re:This is not how you inspire confidence by serviscope_minor · · Score: 3, Interesting

      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.

      --
      SJW n. One who posts facts.
  3. 'Vulnerability" is rubbish. by gnasher719 · · Score: 5, Insightful

    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.

    1. Re:'Vulnerability" is rubbish. by Bengie · · Score: 2

      I read the rational, it wasn't compelling to me, but its their project.

      OpenBSD's moto: Do it correctly, or GTFO

      The only reason it wouldn't be compelling is if you don't believe in doing it correctly in the first place. The entire bug is because of a bandaid in the portability layer to accommodate stupid admins. LibReSSL's stance is the OS is responsible for crypto entropy, anything else is not recommended. Don't have access to /dev/urandom, well too bad. They were forced to add this because of OpenSSL allowing bad practice.

      Not to mention it was patched within hours. Compare that to OpenSSL being given fully working patches to bugs that were several years old and still never patched. They had the patches, they just never applied them and left the bug open in the bug tracker.

  4. LibreSSL not ready for deployment yet by Kardos · · Score: 5, Insightful

    > 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.

  5. Re:OpenBSD has never by 0123456 · · Score: 2

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

  6. Shocked I am! Shocked! by Anonymous Coward · · Score: 2, Interesting

    IKR.

    There's a lot of people saying its a non-issue. It's a huge issue. The contract of a PRNG says it's to return a random value. Getting it to do otherwise (without providing the same seed) is tantamount to being able to make a collision in a hash function (in terms of severity) -- which means that it's fundamentally broken. This bug indicates that there is some underlying structural issue with this PRNG's initialization, and downplaying it demonstrates incompetence.

  7. Re:Shocked I am! Shocked! by KiloByte · · Score: 3, Insightful

    In this case, the same seed was provided. Two copies of the same PRNG are supposed to provide exact same output, I don't see any issue here.

    --
    The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
  8. Re:Shocked I am! Shocked! by athe!st · · Score: 2

    A problem was found in a new library and fixed, this wasn't the PRNG itself, it was an interaction with the operating system. To quote (jandrese):
    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.
    Why are you outraged? This was a subtle bug, that was tricky to exploit and couldn't be used to hack into the computer. You should be outraged that the heartbleed bug remain exposed for years due to awful coding practices

  9. Re:Shocked I am! Shocked! by jandrese · · Score: 5, Informative

    That's not exactly the case, but it's close. The issue is that the SSL library has no way of knowing if the process forks other than checking the PID. If the SSL library detects a PID change, it has to reseed the RNG to avoid getting the same random values in both the parent and the child. Due to the way Unix PIDs work, you have a guarantee that the Parent and the Child will have different pids (fork() fails otherwise). However, if a grandparent forks a parent and then exits, and the parent then forks a child, there is nothing in Unix that outright prevents the child from getting the pid of the now deceased grandparent and foiling this detection so the SSL library doesn't know that a fork happened.

    So it's a potential problem, but not one that likely exists in any production code. You could write test code that exploits it fairly easily by forkbombing the machine until the pid wraps before spawning the child, but in real production code it is unlikely to be an issue. Plus it was fixed.

    --

    I read the internet for the articles.
  10. Re:Shocked I am! Shocked! by TechyImmigrant · · Score: 2

    I'm completely serious.

    Some years ago I described "The Paranoid Entropy Trap". The tendency to get no entropy because you trusted none of your sources and turned them all off.

    This is just such an example. If that computer he ran it on was less than a couple of years old, the hardware was almost certainly providing lots of entropy and the library was actively choosing to ignore it in the name of security.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  11. Re:Curious OS design shortcoming by TechyImmigrant · · Score: 2

    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.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  12. Re:Shocked I am! Shocked! by TechyImmigrant · · Score: 2

    LibreSSL relied on specific PID behavior to be secure. Linux has conditions in which recent PIDs of disappeared processes can be reused in new processes. This broke the LibreSSL assumptions.

    From other comments it seems the state space of the PIDs is pretty small anyway. The birthday collision bound is waiting to trip you up even on BSDs.

    Don't rely on the PID to provide you with crypto security properties.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  13. Re:LibreSSL cannot be different by being the same by gnu-sucks · · Score: 2

    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...

  14. Re:LibreSSL cannot be different by being the same by Carnildo · · Score: 5, Informative

    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.

    --
    "They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.