LibreSSL PRNG Vulnerability Patched

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

Comments

This is not how you inspire confidence

[Jonathan C. Patschke]

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

Re:This is not how you inspire confidence

[jandrese]

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

Re:This is not how you inspire confidence

[viperidaenz]

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.

Re:This is not how you inspire confidence

[Dishevel]

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.

Re:This is not how you inspire confidence

[Qzukk]

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.

Re:This is not how you inspire confidence

[QuietLagoon]

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.

Re:This is not how you inspire confidence

[Bengie]

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.

Re:This is not how you inspire confidence

[serviscope_minor]

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.

Re:This is not how you inspire confidence

[serviscope_minor]

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.

'Vulnerability" is rubbish.

[gnasher719]

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.

LibreSSL not ready for deployment yet

[Kardos]

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

Re:Shocked I am! Shocked!

[KiloByte]

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.

Re:Shocked I am! Shocked!

[jandrese]

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.

Re:You're holding the phone wrong

[maliqua]

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"

Re:LibreSSL cannot be different by being the same

[Carnildo]

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.