LibreSSL PRNG Vulnerability Patched 151
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."
You're holding the phone wrong (Score:2, Funny)
That's not how you're suppose to hold the phone.
Re:You're holding the phone wrong (Score:5, 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"
This is not how you inspire confidence (Score:5, Insightful)
A: Exploits.
Re:This is not how you inspire confidence (Score:5, Interesting)
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: (Score:2)
Re:This is not how you inspire confidence (Score:5, Insightful)
.
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: (Score:2)
Re:This is not how you inspire confidence (Score:4, 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.
Re: (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
Re:This is not how you inspire confidence (Score:5, Interesting)
I thought they did quite well.
Re: (Score:2)
Exactly!
The disclosure is very well written, says exactly why this is a big problem and proposes a very implementable solution that would fix it. Nevertheless, the dev decided to try to dismiss the disclosure, called his daddy (de Raadt) and they both threw a tantrum, and fixed it in a way that is questionable (an update on the disclosure raises some good questions on why it is questionable)
Btw, forgetting about ssl for a minute (open/libressl are crypto libraries, not ssl libraries), a PRNG is either secur
Re: (Score:2)
Re: (Score:2)
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?
Re:This is not how you inspire confidence (Score:5, 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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3)
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.
Re:This is not how you inspire confidence (Score:5, Informative)
Re: (Score:2)
where the sysadmin blocks access to /dev/urandom
Why would they do that
Re: (Score:1)
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.
Re:This is not how you inspire confidence (Score:4, 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.
Re: (Score:2)
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
Re: (Score:2)
3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.
That sounds really hard to exploit
Re:This is not how you inspire confidence (Score:5, 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.
Re: (Score:1)
But... think of the children!
Re: (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.
'Vulnerability" is rubbish. (Score:5, Insightful)
Re: (Score:1)
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.
Re: (Score:2)
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)...
Re: (Score:2)
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
Re: (Score:3)
I read the rational, it wasn't compelling to me, but its their project.
OpenBSD's moto: Do it correctly, or GTFO
/dev/urandom, well too bad. They were forced to add this because of OpenSSL allowing bad practice.
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
Not to mention it was patched within hours. Compar
Re: (Score:2)
Or a bad developer that assumes the PRNG is "good".
Re: (Score:2)
I don't know, this is pretty good plausible deniability. The only flaw is calling the function twice. That's easily hid in a program and doesn't look evil on first glance.
OpenBSD has never (Score:1)
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.
Re: (Score:3)
But they have apparently 'fixed' the code that allowed a developer to ensure this never happened... by making it a no-op.
LibreSSL cannot be different by being the same (Score:2)
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
Re: (Score:3)
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...
Re:LibreSSL cannot be different by being the same (Score:5, Informative)
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.
Re: (Score:1)
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.
LibreSSL not ready for deployment yet (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.
Re: (Score:2)
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.
Re: (Score:2)
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... ;-)
Curious OS design shortcoming (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:1)
FWIW, grsecurity (a patch for the Linux kernel) implements random-seeded PRNG-based unpredictable PIDs.
Re: (Score:2)
Lets hope their PRNG is good :)
Re: (Score:2)
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...
Re: (Score:2)
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.
Re: (Score:2)
The incrementing PID would collide with itself less than a random PID of the same number of bits.
PIDs aren't good sources of entropy.
Not realistic indeed. (Score:2)
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.
Re: (Score:2)
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'....
Re: (Score:2)
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
Should read (Score:1)
Re: (Score:1)
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.
Re: (Score:1)
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"?
Shocked I am! Shocked! (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.
Re:Shocked I am! Shocked! (Score:4, 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.
Re: (Score:1)
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.
Two calls to two different PRNGs provided the same output. That is the problem.
Well designed PRNG algorithms have procedures to prevent this. Whatever you think of SP800-90A, the update procedure allowed for additional entropy in each update and would have prevented this.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
If it got as far as the testing phase before the bug was found then the process must be broken!
Re: (Score:2)
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.
Re: (Score:2)
That was supposed to be sarcasm, I know it's hard for some people to detect it.
Re: (Score:2)
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. :)
Re: (Score:2)
Or the statement is so absurd that it can't possibly be taken seriously.
Re: (Score:2)
Re: (Score:2)
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.
Re:Shocked I am! Shocked! (Score:5, Informative)
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: (Score:2)
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
Re: (Score:2)
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 th
Re: (Score:2)
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.
Re: (Score:2)
It's a shame the software didn't have a handy dandy instruction [intel.com] that it could execute without reference to the OS or libraries or permissions.
Re: (Score:2)
Re: (Score:2)
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 softw
Re: (Score:2)
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 surfa
Re: (Score:2)
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 wi
Re: (Score:2)
Why are you using a CPU that doesn't provide an entropy source to run crypto code? Software cannot fix that for you.
Re: (Score:2)
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.
Re: (Score:1)
Quote: "In LibreSSL, entropy is the responsibility of the OS. If your OS cannot provide you with entropy, LibreSSL will not fake it."
The Linux port is faking it. Blame the design limitations of Linux that forced the port team to "fake it" in some situations.
Re: (Score:2)
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
Re: (Score:2)
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 trivia
Re: (Score:2)
>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.
Re: (Score:2)
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.
Re: (Score:2)
No. Negativity is a normal condition for crypto oriented people.
Re: (Score:2)
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 Lib
Re: (Score:1)
I'm shocked that they acted like it was no biggie.
They should have thanked Andrew Ayer profusely and acknowledged that a good RNG would not be vulnerable to state duplicate through fork().
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
>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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
>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
Re: (Score:2)
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.c [github.com]
Re: (Score:2)
I have heard enough. Feel free to stop digging.
Re: (Score:2)
>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.