Slashdot Mirror
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."
"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."
That's not how you're suppose to hold the phone.
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.
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.
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.
> 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.
Think about all the eyes on the code both upstream and downstream.
Or lack thereof, in this case. Just because a project is open source doesn't mean the code's been properly audited as you seem to be assuming. OpenSSL is notorious for its poor code quality and difficulty to understand.
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.
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.
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
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.
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.
This "Theo de Raadt and developer Bob Beck, however, countered saying that the issue is "overblown" because Ayer's test program is unrealistic."
Is why it is bad. Bugs are allowed. But in security, RNGs are special and you do them right or you fail. They failed. Then they tried to claim it wasn't a biggie.
>You should be outraged that the heartbleed bug remain exposed for years due to awful coding practices
Who says I'm not. But that is a symptom of a bigger problem of using transport security to protect things in higher layers. This is wrong.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Wait, when was LibreSSL a completely new SSL library? There was me thinking that they'd spent ages saying that they were only stripping out dead code and refactoring, and listening to BSD lovers on Slashdot saying how often "Theo" and his "boys" have done this kind of thing before... but now there's a vulnerability it's suddenly "a completely new SSL library"?
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 bugs and nuances as the original OpenSSL.
What they're trying to do is be a simple-enough replacement of OpenSSL for most modern software out there (possibly with some minimal patching of the outside software), and not a one-to-one drop-in-replacement for random edge cases.
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 not to make sure all PIDs issued on a given system for a given power cycle are unique? Yeah, it would be a tradeoff against performance.
I know what the attack does.
It if was a deterministic PRNG for the purpose of producing deterministic sequences, then it would be fine. But it is not that and it is not fine. It is the random service in the crypto library and you want this to provide numbers that meet the necessary properties of cryptographically secure random numbers.
If you fork a process and each process call my RNG, you'll get a different result, subject to the normal binomial collision distribution. This is how it should be.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
The reason is because LibreSSL thought it was OK to put a CSPRNG in a place where it was not ok.
>you are a fucking idiot.
Maybe, but on this topic, I know my shit.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Linux's PID behavior is not a security feature. LibreSSL should not rely on it. Security products needs to be held to a higher standard.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
I've spent the past 5 years of my life fully employed in the design, creation, testing, and deployment of secure RNGs.
Citation needed. Seriously, this is /. where everyone is a world-class programmer (except me, of course).
The world is full of bad PRNGs, NRNGs, CSPRNGs, DRBGs, TRNGs and any other form of RNG.
I will grant you that one.
LibreSSL doesn't have a leg to stand on. A good secure RNG will return unpredictable output.
Bzzzzt! Sorry, you lose. As I have already said, this is not a LibreSSL problem - it's a Linux PRNG problem. Unless I am mistaken, the same issue is non-existent under OpenBSD, because it's PRNG is different from Linux, better seeded and because PIDs are randomized under that OS.
We know how to do these things. It isn't trivial, but it isn't hard either.
You contradict yourself: if programming PRNGs is, let's say, a medium difficulty task (neither trivial nor too hard), how come you have spent years designing and programnming PRNGs (your words, not mine) and how come the world is full of bad bad bad PRNGs? Surely, by now, everyone would have agreed on a reasonable implementation?
The truth is, PRNGs are HARD to program, because computers are not good at generating truly random numbers. Period. The best implementations all rely on some form of hardware generator. But don't take my word for it, go ahead and read this instead.
Allowing someone to extract predictable behavior from the service end of a security library is a gross failure and an exposition of incompetence.
As opposed to the magnificent job OpenSSL has done all these years, with information leakage, bug reports that went uncorrected for years and accumulated cruft for such modern OS as VMS, DOS and Windows 3.1?
I think you need to tone down the hysteria a notch right here.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Well, that was the requirement for this RNG to, wasn't it? But they had a bug where the pid was presumed to be unique within the foliation of process forking. Testing found that assumption to be incorrect (given maliciousness on the backend), and so the code was fixed. Seems perfectly fine to me. That's why there's testing: you can't see the errors in your assumptions through any amount of inspection.
Socialism: a lie told by totalitarians and believed by fools.
>how come you have spent years designing and programnming PRNGs
I do them in hardware, where they should be. Software is no place for an RNG.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
how come you have spent years designing and programnming PRNGs
I do them in hardware, where they should be. Software is no place for an RNG.
Good for you. Not everyone can afford an hardware PRNG, though, so software it is for most of us.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
If it got as far as the testing phase before the bug was found then the process must be broken!
Often entropy is used when seeding, not at every call to get a new random number. When you exactly duplicate a process, you get exactly the same state in both PRNGs. A PRNG library which is distinct from the operating system needs to rely on the operating system to allow it to know when its state has been duplicated. The bug was with this operating system interaction.
Now you may have a point that someone should apply entropy at every single iteration of the RNG, but that is often very expensive and thus is reserved for special cases. This is why I assume OpenSSL had a RAND_poll function. So the real discussion here is not whether the LibreSSL people are incompetent, but whether or not a RAND_poll style function is necessary, unnecessary, or provides a false sense of security. LibreSSL does periodically add more entropy. And LibreSSL attempted, with good intentions, to remove the need for a RAND_poll workaround and remove the need to be a expert familiar with all the flaws and workarounds before you attempt to use an SSL library securely.
I am glad that you've never managed to have a bug escape into the public testing phase of a product.
However there were also major flaws in the way OpenSSL was doing this stuff. Using OpenSSL securely required that you know about the flaws that it have and provide specific workarounds to avoid specifically the problem LibreSSL encountered. What LibreSSL did was attempt to make the library more idiot proof so that it would work even if you forgot to do RAND_poll() at key moments. The bug is that they did this wrong; but OpenSSL also did it wrong as well as it was not fork safe in all ports, requiring the programmer to know when to do RAND_poll().
LibreSSL prng vulnerable to psyops.
They failed. Then they tried to claim it wasn't a biggie.
It isn't. Apparently is an issue related to portability (aka Linux), and lack of permissions to access to proper RNGs in real-world scenarios (no access to /dev/urandom). While this is definitely a bug, it *isn't* a biggie. Its an edge case where the implementation should have been more robust, that's it.
Security products needs to be held to a higher standard.
OpenSSL/LibreSSL are *not* security products. They are crypto middleware. They can be used to build security products, or to build completely unsecured products. They do nothing by itself. Which is fun, because the LibreSSL Linux port actually required *extra* code so it would work with dumbass admins. And this extra code had the bug. True, Linux PID behaviour is not a security feature, but it is an entropy source. Maybe not a good one, granted. But it was used as fallback. Want to bitch about it, go ahead. It was detected, it was fixed. It is not a big deal. What is the problem?
Bzzzzt! Sorry, you lose. As I have already said, this is not a LibreSSL problem - it's a Linux PRNG problem. Unless I am mistaken, the same issue is non-existent under OpenBSD, because it's PRNG is different from Linux, better seeded
Incorrect. OpenSSL manages its own entropy pool and retrieves entropy from operating system as necessary on Linux and most UNIX systems by reading from /dev/urandom.
and because PIDs are randomized under that OS.
Who cares if PIDs are sequential or random? Chance of same sequence of events remains with either scenario.
More amusingly reuse happens quicker with random algorithm than a sequential one as the sequence needs to wrap around first.
As opposed to the magnificent job OpenSSL has done all these years, with information leakage, bug reports that went uncorrected for years and accumulated cruft for such modern OS as VMS, DOS and Windows 3.1?
I think you need to tone down the hysteria a notch right here.
Two wrongs don't make a right. Whatever shortcomings the OpenSSL project has does not excuse shortcomings in LibreSSL.
The last time I looked, OpenSSL claimed to provide command line tools for managing certs. It's a security product. OpenSSL recently greatly improved its RNG code, but the BSD folks borked it.
Not that I'm a fan of OpenSSL at all. I'd like to see it wiped off this planet. But replacing it with another TLS implementation is not what I'd call a success.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
>Entropy is the OS's job.
I've gone for bypassing the OS as best I can and delivering the entropy directly from hardware. OSs don't have the situational awareness to know whether or not what they have is really entropic. It works most of the time until you try and run it on an arm processor in a fully synchronous chip in a cheesy router pulling random numbers at early boot time.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
CSPRNGs are a fine component in a system. But it doesn't let anyone off the hook for gathering and extracting entropy.
Hardware vendors have to do it. Things are ok on PCs these days, but the plethora of amateur SoCs have re-opened the field for entropyless systems.
Something somewhere needs to implement policy, in terms of what is trusted to be entropic and combining and processing sources. A library can do that. But a CSPRNG as we have seen in this case, is particularly precarious in a user library because it's state can be duplicated. You're better off with a system resident service of some sort. An OS will do, or a hardware interface that supports multiple consumers without coordination (like CPU instructions), or anything else than can keep any PRNG state in a well controlled context.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
It's a shame the software didn't have a handy dandy instruction that it could execute without reference to the OS or libraries or permissions.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
That ... makes no sense at all. Again, no amount of code inspection (or unit tests) will find flaws in your assumptions. That's why end-to-end testing is indispensable: it's how you discover your flawed assumptions.
Socialism: a lie told by totalitarians and believed by fools.
>I am glad that you've never managed to have a bug escape into the public testing phase of a product.
It doesn't work like that for some of us. It has to be right first time, every time. Which is probably why I'm always tired.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I'm not. There are normal capability bits though. So software can be written to do the right thing on each platform.
The point is that even in a chroot jail with no access to /dev/urandom and a completely predictable PID, instructions are still there on intel CPUs, VIAs and some arms, yet the library ignores all those options, resulting in a collision case. It's certainly the right thing to do to mix in cheap, fast sources into your CSPRNG state on each call. You don't have to trust the source and no harm will arise, but if the source is actually trustworthy, it will cover for cases such as these very effectively.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
That was supposed to be sarcasm, I know it's hard for some people to detect it.
Why are you using a CPU that doesn't provide an entropy source to run crypto code? Software cannot fix that for you.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
No. Negativity is a normal condition for crypto oriented people.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Detecting sarcasm often requires hearing the tone of voice, and the assumption that the other party is sane, neither of which is available on the internet. :)
Socialism: a lie told by totalitarians and believed by fools.
Or the statement is so absurd that it can't possibly be taken seriously.
It's a shame that you don't realize that *modern* Intel is only a subset of the cpu market, and not even that relevant in network appliances. Have a look at http://en.wikipedia.org/wiki/R..., and you'll quickly see that the instruction you mention is about 2 years old. So, either you have the experience you say you have in other posts, and you're perfectly aware of this and are trolling, or you actually have no clue on the diversity of hardware out there.
The last time I looked, OpenSSL claimed to provide command line tools for managing certs
So, it generates prime numbers and does some math between them. If that is a security product, so is everything else capable of producing that kind of output - it includes both Excel and the C language, as an example.
OpenSSL recently greatly improved its RNG code
Define "recently" and "greatly". Because if this bug actually happened in OpenSSL, I suspect that we'd have to wait months for the proper patch from upstream.
Of course I know about other hardware RNGs. I already pointed to VIAs and the occasional one strapped to an ARM core. I put some of them in some of those chips. Back then I was into iterated hashes, but I've learned the error of my ways and these days it's block ciphers and field arithmetic all the way.
Rumor has is that I may know something about the RNG you just referenced. It may be two years old to you, but it didn't come into existence in 10 minutes. It doesn't really matter. These repeated crypto software failures point to a holier than thou attitude of some crypto software writers that does the public no good. You can't play in this game without accepting that it's easy to be wrong and you'd better have things checked and cross checked by the smartest people you can find and don't get all defensive when you've been found to be wrong. Mark it down to experience and move on. That's how it works. When Theo can't accept that the universe works this way, he automatically loses his security credibility license.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
>So, it generates prime numbers and does some math between them. If that is a security product, so is everything else capable of producing that kind of output - it includes both Excel and the C language, as an example.
I didn't know C and Excel had a native X.509 parser and cert management built into the language. I'll run and check my copy and K&R, but I'm pretty sure it's not in there. That's why libraries like openssl exist.
>Define "recently"
In the last two years. Deployed in the main stream in that last year.
>and "greatly"
Gave the option of using local high rate entropy sources to ensure consistency in the random numbers from it's service interface.
OpenSSL is a mess in many ways, but if you ignore the problems the openssl writers solved, you're doomed to recreate them in your own library.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Of course I know about other hardware RNGs. I already pointed to VIAs and the occasional one strapped to an ARM core. I put some of them in some of those chips.
So, you acknowledge they're still not mainstream, as you tried to imply in your previous comment.
It may be two years old to you, but it didn't come into existence in 10 minutes.
Yeah, it didn't. Crypto support in general purpose CPUs is not new, and as you mentioned, the VIA instructions are way older than the incarnation from Intel.
These repeated crypto software failures point to a holier than thou attitude of some crypto software writers that does the public no good. You can't play in this game without accepting that it's easy to be wrong and you'd better have things checked and cross checked by the smartest people you can find and don't get all defensive when you've been found to be wrong.
The whole point is, probably some of the critical systems running software implementations in userspace shouldn't. Cryptoprocessors exist for a long time, and cryptocards and SoC are quite common well, everywhere. Bugs will always exist, but the attack surface is way smaller.
Mark it down to experience and move on. That's how it works. When Theo can't accept that the universe works this way, he automatically loses his security credibility license.
That's how all software works. It wasn't a serious/catastrophic bug. The peer review process from the community worked as expected, the bug was spotted and then fixed. The bug was tied to a specific implementation that wasn't very well thought of. Doesn't really matter, it was fixed. The bug itself was quite hard to exploit, specially if used on a secure environment (where process accounting is common; in fact, it baffles me the inane amount of Linux servers without any resource accounting at all, and the huge amount of sysadmins that don't even know how to configure this); I'd guess it is quite easier to gain root access on a given Linux server by using a more "generic" exploit (and then do as much hijacking as you want) than to hijack a crypto channel by using a fork bomb. And if it was Linus doing a similar fuckup, no biggie. But because it's Theo, it is newsworthy.
I didn't know C and Excel had a native X.509 parser and cert management built into the language. I'll run and check my copy and K&R, but I'm pretty sure it's not in there.
If you configure any of them to that specific task, there is no technical limitation from their side. But I'm sure you wouldn't consider some scripted operations in Excel to generate and manage certificates a security product, right? That was my point.
In the last two years. Deployed in the main stream in that last year.
And is consistent in every environment? Shall I expect the same quality and behaviour in OpenBSD, Linux and Windows 3.1? Because, you know, this is the actual problem.
Gave the option of using local high rate entropy sources to ensure consistency in the random numbers from it's service interface.
Sure, its called ENGINE API. Did LibreSSL removed it? Doesn't seem so. Check https://github.com/libressl/li...
You do realise this is /. don't you?
God: An invisible friend for grown-ups.
I have heard enough. Feel free to stop digging.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Never forget Poe's Law. Not only is there no statement so absurd that it can't be taken seriously by someone, it will be. Even TimeCube.
Socialism: a lie told by totalitarians and believed by fools.