LibreSSL PRNG Vulnerability Patched

← Back to Stories (view on slashdot.org)

LibreSSL PRNG Vulnerability Patched

Posted by Soulskill on Wednesday July 16, 2014 @08:37AM 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."

151 comments

Min score:

Reason:

Sort:

You're holding the phone wrong by Anonymous Coward · 2014-07-16 08:42 · Score: 2, Funny

That's not how you're suppose to hold the phone.
1. Re:You're holding the phone wrong by maliqua · 2014-07-16 10:17 · 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. Re:You're holding the phone wrong by Anonymous Coward · 2014-07-16 10:48 · Score: 0
  
  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"
  Or, here's this phone we made you. Oops, didn't realize your body was so mangled that you can't hold it properly.
This is not how you inspire confidence by Jonathan+C.+Patschke · 2014-07-16 08:45 · 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 · 2014-07-16 08:52 · 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 · 2014-07-16 09:01 · 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 asmkm22 · 2014-07-16 09:02 · Score: 1
  
  Seems like the type of thing a malware author would design around in order to take advantage of a security flaw.
4. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 09:12 · Score: 0
  
  So that just means I need to replace your insert_secure_binary here with one that forks until it gets the pid it wants, then exec's the hidden_secure_binary while being able to pull the same random numbers out of the hat.
  Great for those people who refuse to store their SSL key without a password so I can't just take it off the server, I have to wait for them to type the passphrase.
5. Re:This is not how you inspire confidence by viperidaenz · 2014-07-16 09:19 · 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.
6. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 09:41 · Score: 0
  
  I don't have a butthole, you insensitive clod! You can try sticking it my colostomy hole, though.
7. Re:This is not how you inspire confidence by Jonathan+C.+Patschke · 2014-07-16 10:01 · 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.
8. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 10:27 · Score: 0
  
  Did they not fix it? in a timely fashion? on the first test release to the public? that's purpose was to be released into the wild and analyzed so exploits may be found aand repaired?
  if hey hadn't fixed it fine your comment would be less asinine but they did fix it, quickly after it was pointed out.
  what more do you want? humility? then open source operating systems are not for you
9. Re:This is not how you inspire confidence by Dishevel · 2014-07-16 10:33 · 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?
10. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 10:47 · Score: 0
  
  You can do pretty much anything you want
  Except decrypt your SSL private key.
  I suppose I could do a keylogger, though.
11. Re:This is not how you inspire confidence by cheater512 · 2014-07-16 11:12 · Score: 1
  
  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?
12. Re:This is not how you inspire confidence by Qzukk · 2014-07-16 11:15 · 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.
13. Re:This is not how you inspire confidence by QuietLagoon · 2014-07-16 11:54 · 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.
14. Re:This is not how you inspire confidence by gnu-sucks · 2014-07-16 12:14 · 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.
15. Re:This is not how you inspire confidence by kesuki · 2014-07-16 12:23 · Score: 1
  
  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 numbers makes more sense than names, but again it is the telco who limits numbers and decides when to reuse the numbers and such, and as such they can put artificial worlds which don't make sense.
  i mean really processes have randomly increasing pids until exhaustion then frees the use of pids in a certain block of pids or hangs and crashes violently. really we need to consider that 32-bit addressing isn't sufficient to a computer that can make 500 trillion operations per second. this is the main reason high end gpus use 256-bit addressing isn't it? so that it can't reuse in chip thread ids? with 2048 pipes with 256bit addressing and random pid growth on a chip that runs each core at 600 mhz i don't care to crunch the numbers as i don't fully realize how a gpu uses pids as i am not a graphics engineer, but man if a gpu executed a forkbomb that wasn't prevented due to obfuscation of code it could exhaust the pids and crash the whole damn computer.
  
  --
  https://www.gnu.org/philosophy/free-sw.html
16. Re:This is not how you inspire confidence by Bengie · 2014-07-16 13:29 · 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.
17. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 16:09 · Score: 0
  
  ... It makes one wonder why, as the OpenSSL near-monoculture has served the world so well.
  If I was one of the semi-competent OpenSSL developers earning $250/hr on consulting projects, I'd be doing everything to discredit LibreSSL too.
18. Re:This is not how you inspire confidence by phantomfive · 2014-07-16 16:13 · Score: 1
  
  3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.
  
  That sounds really hard to exploit
  
  --
  "First they came for the slanderers and i said nothing."
19. Re:This is not how you inspire confidence by asmkm22 · 2014-07-16 16:16 · Score: 1
  
  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 really have to." Makes sense to me, but I'm just a random MS guy 90% of the time.
20. Re:This is not how you inspire confidence by phantomfive · 2014-07-16 16:16 · Score: 1
  
  where the sysadmin blocks access to /dev/urandom
  Why would they do that
  
  --
  "First they came for the slanderers and i said nothing."
21. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 16:16 · Score: 0
  
  Because you can create code that does this and have it be fully open source, and no one would think the wiser of the child-object's malicious intent.
  If you think it's not worth thinking about then STFU, moron. This is how you build backdoors into OSS.
22. Re:This is not how you inspire confidence by someoneOtherThanMe · 2014-07-16 17:56 · Score: 1
  
  But... think of the children!
23. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 18:34 · Score: 0
  
  I thought the response was crap:
  - Say the scenario is unrealistic
  - Blame the user
  - Blame Linux
  - Make another dig at OpenSSL anyway
  This is not at all the response that should come from people working on secure software.
24. Re:This is not how you inspire confidence by jandrese · 2014-07-16 19:17 · Score: 1
  
  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.
  
  --
  
  I read the internet for the articles.
25. Re:This is not how you inspire confidence by maevius · 2014-07-16 19:18 · Score: 1
  
  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 secure or it is not. There is no "kinda" secure in most user scenarios etc.
26. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 20:37 · Score: 0
  
  Oh sure, you've got access to a system via code injection so you immediately start thinking keyloggers or dumping the contents of a database. Why doesn't the PRNG ever get some love? In a world of social justice I demand that we exploit everything equally or nothing at all.
27. Re:This is not how you inspire confidence by serviscope_minor · 2014-07-16 21:17 · 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.
28. Re:This is not how you inspire confidence by serviscope_minor · 2014-07-16 21:21 · 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.
29. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-16 23:18 · 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.
30. Re: This is not how you inspire confidence by Anonymous Coward · 2014-07-17 00:21 · Score: 0
  
  What you mean? dMBaSSL is working perfectly fine. It synergizes money out from your pockets into ours.
31. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-17 00:52 · Score: 0
  
  By accident. Trying to chroot a process and forgetting to create a /dev/urandom in the chroot?
32. Re:This is not how you inspire confidence by hairyfeet · 2014-07-17 02:16 · Score: 1
  
  Nice to see that I'm not the only one who thought the response was completely unprofessional.
  What is it lately with all these OSS guys in key positions turning into Ulrich Drepper clones? Have they gotten so used to being told how great they are that when anybody dares point out a mistake they HAVE to go nuclear? You got Torvalds flipping off companies and throwing fits like a 14 year old Halo player, you got de Raadt acting like a giant ass, now you got this guy...wtf? Has everybody forgotten what it means to act like a professional?
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
33. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-17 04:02 · Score: 0
  
  However, this is not a Linux fork. It is a a fork written for BSD. I have seen lots of silly remarks that the BSD developers should be working on the Linux version.
  That does not make sense when the Linux version is such a mess, and shows such a slow update cycle.
34. Re:This is not how you inspire confidence by Anonymous Coward · 2014-07-17 04:07 · Score: 1
  
  Noticed that too. In the same time frame that BSD people have stripped down and delivered working code the OpenSSL people have gotten a road map out. More interestingly the OpenSSL road map requires almost as large a strip-down as the BSD version yet has delivered far less work. What are they doing anyway?
35. Re:This is not how you inspire confidence by Qzukk · 2014-07-17 06:21 · Score: 1
  
  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 become a zombie.
  Step-by-step "how to daemon" guide here.
  
  --
  If I have been able to see further than others, it is because I bought a pair of binoculars.
'Vulnerability" is rubbish. by gnasher719 · 2014-07-16 08:54 · 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 Anonymous Coward · 2014-07-16 09:10 · Score: 0
  
  Yup, there are easier ways to write bad software, and most of those would give you plausible deniability more easily.
2. Re:'Vulnerability" is rubbish. by sinij · 2014-07-16 09:23 · Score: 0
  
  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.
3. Re:'Vulnerability" is rubbish. by Bill,+Shooter+of+Bul · 2014-07-16 10:11 · Score: 1
  
  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.
  
  --
  Well.. maybe. Or Maybe not. But Definitely not sort of.
4. Re:'Vulnerability" is rubbish. by Noryungi · 2014-07-16 10:48 · Score: 1
  
  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)...
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
5. Re:'Vulnerability" is rubbish. by gnu-sucks · 2014-07-16 12:16 · Score: 1
  
  Or a bad developer that assumes the PRNG is "good".
6. Re:'Vulnerability" is rubbish. by Anonymous Coward · 2014-07-16 12:20 · Score: 0
  
  That is absolutely right, but I will note right away that this is a problem specific to the Linux PRNG
  Not quite. It is a PRNG in the libressl code (nothing about its source originated from Linux). It exists so the libresll developers wouldn't have to use /dev/[u]random to access entropy as would be required on Linux.
  I read the rational, it wasn't compelling to me, but its their project.
7. Re:'Vulnerability" is rubbish. by sinij · 2014-07-16 13:40 · Score: 1
  
  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 these can be exploited to break strongest crypto. Why? Because all our crypto is deterministic.
8. Re:'Vulnerability" is rubbish. by Bengie · 2014-07-16 13:43 · 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.
You're holding it wrong by Anonymous Coward · 2014-07-16 09:02 · Score: 0

...
1. Re:You're holding it wrong by Anonymous Coward · 2014-07-16 21:12 · Score: 0
  
  Holding the mouthpiece to the ear and the earpiece to the mouth is indeed wrong.
Field Tested by Anonymous Coward · 2014-07-16 09:08 · Score: 0

Rolling out a completely new SSL library is no trivial feat. There will be bumps in the road and only time will tell if all the effort was worth it. The same goes for BoringSSL. Just consider how long OpenSSL has been around. If you leave OpenSSL because THE WORLD missed heart bleed, you are a fool. Think about all the eyes on the code both upstream and downstream.
Knee Jerk reactions seldom create something better, but they are good for perception. Maybe that is what this whole thing is really about...
1. Re:Field Tested by Anonymous Coward · 2014-07-16 09:23 · Score: 1
  
  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.
2. Re:Field Tested by Anonymous Coward · 2014-07-16 10:05 · 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"?
3. Re:Field Tested by Anonymous Coward · 2014-07-16 10:32 · Score: 0
  
  no most of us BSD fan-boys are simply saying that it was a first test release and they fixed the problem so quit bitching about the way they classified the extremity of the issue and focus on the fact that a bug was found, and fixed and testing is continuing on a promising new ssl library
4. Re:Field Tested by Anonymous Coward · 2014-07-16 10:37 · Score: 0
  
  When did LibreSSL get audited, and how did the auditors miss this bug?
5. Re:Field Tested by Anonymous Coward · 2014-07-16 16:44 · Score: 0
  
  quit bitching about the way they classified the extremity of the issue and focus on the fact that a bug was found
  
  Theo & Co. would do well to take this advice themselves.
OpenBSD has never by Anonymous Coward · 2014-07-16 09:18 · 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.
1. Re:OpenBSD has never by 0123456 · 2014-07-16 09:22 · Score: 2
  
  But they have apparently 'fixed' the code that allowed a developer to ensure this never happened... by making it a no-op.
LibreSSL not ready for deployment yet by Kardos · 2014-07-16 09:22 · 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.
1. Re:LibreSSL not ready for deployment yet by maliqua · 2014-07-16 10:36 · Score: 1
  
  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.
2. Re:LibreSSL not ready for deployment yet by Noryungi · 2014-07-16 10:50 · Score: 1
  
  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... ;-)
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
3. Re:LibreSSL not ready for deployment yet by Anonymous Coward · 2014-07-17 02:10 · Score: 0
  
  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... ;-)
  As GP said, for "by OpenBSD standards" values of "tactful".
Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 09:23 · Score: 0

I've spent the past 5 years of my life fully employed in the design, creation, testing, and deployment of secure RNGs.
The world is full of bad PRNGs, NRNGs, CSPRNGs, DRBGs, TRNGs and any other form of RNG.
LibreSSL doesn't have a leg to stand on. A good secure RNG will return unpredictable output. A good PRNG will return data indistinguishable from random. A good CSPRNG will do that with guarantees on the computational complexity of predicting the output.
We know how to do these things. It isn't trivial, but it isn't hard either. Allowing someone to extract predictable behavior from the service end of a security library is a gross failure and an exposition of incompetence.

--
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
1. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 09:40 · Score: 0
  
  Are you shocked that they fixed it anyway, that this was an early version released to solicit feedback and that no production system use libressl today ?
2. Re:Shocked I am! Shocked! by KiloByte · 2014-07-16 09:42 · 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.
3. Re:Shocked I am! Shocked! by athe!st · 2014-07-16 09:48 · 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
4. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 09:50 · Score: 0
  
  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.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
5. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 09:52 · Score: 0
  
  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().
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
6. Re:Shocked I am! Shocked! by jandrese · 2014-07-16 09:54 · 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.
7. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 09:56 · 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.
8. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 10:00 · Score: 1
  
  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.
9. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 10:12 · Score: 0
  
  Unfortunately, you are speaking from a position of knowledge and experience with crypto technology - such commentary will go sailing over the head of the typical slashdot commenter.
  Faulty PRNG's are a primary weak point for crypto engines - in fact, there were allegations that the NSA had been involved in deliberately weakening PRNG's in various packages as part of creating 'backdoors' to exploit for cracking encrypted messages.
  Standard software developers are unfamiliar with adversarial programming - looking for ways to exploit the behavior of a module to compromise its intended usage. Their response to these sorts of scenarios are generally "well, yeah, but so what" - and so is born a new exploit...
  This sort of mistake indicates the relative crypto-inexperience of the people working on LibreSSL (as well as their contempt for the reasons behind why OpenSSL did some of the things that it does). This is the smoke indicating that LibreSSL is going to have a completely new set of vulnerabilities due to its refactoring work for some time to come.
10. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 10:17 · Score: 0
  
  Two calls to two different PRNGs provided the same output. That is the problem.
  No, it's two calls to the same PRNG. The libreSSL folks apparently weren't aware that it's common practice for developers to assume that fork() has magical properties that cause identical things to become non-identical. Now they know, and they "fixed" the problem in their pre-release software. That's the whole point of the story.
  p.s. I used the word problem with scare quotes, because I think calling it a bug is nonsense. At worst, it was a missing feature.
11. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 10:26 · Score: 1
  
  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.
12. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 10:41 · Score: 0
  
  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().
  It sounds like they're saying BSD's don't have the same issue, is there a problem with Linux?
13. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 10:42 · Score: 0
  
  It is odd that this does not manifest itself on OpenBSD or FreeBSD.The reason is because the flaw is with Linux. Then stop blaming LibreSSL. And for somebody that has supposedly 5 years of experience, you are a fucking idiot.
14. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 10:44 · Score: 0
  
  No, it indicates that people cannot understand the problem is with Linux and OpenSSL masked this kernel bug all these years.
15. Re: Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 10:45 · Score: 0
  
  This. RNG should not be dependent on PID alone. Ideally the seed should have as many inputs as possible. Getting the same data repeatedly out of a function dependent on PID, when the PID is controlled, means that there is no other independent input. That's bad design, but luckily it was caught and fixed. Hopefully reviewers will look for other areas like that.
16. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 10:53 · Score: 1
  
  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.
17. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 10:54 · Score: 1
  
  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.
18. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 11:04 · 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.
19. Re:Shocked I am! Shocked! by Noryungi · 2014-07-16 11:09 · Score: 1
  
  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)
20. Re:Shocked I am! Shocked! by lgw · 2014-07-16 11:17 · Score: 1
  
  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.
21. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 11:18 · Score: 1
  
  >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.
22. Re:Shocked I am! Shocked! by Noryungi · 2014-07-16 11:29 · Score: 1
  
  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)
23. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 11:58 · Score: 0
  
  And also, h/w rng's are hard to inspect for backdoors!
24. Re:Shocked I am! Shocked! by Darinbob · 2014-07-16 12:28 · Score: 1
  
  If it got as far as the testing phase before the bug was found then the process must be broken!
25. Re:Shocked I am! Shocked! by Darinbob · 2014-07-16 12:57 · Score: 1
  
  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.
26. Re:Shocked I am! Shocked! by Darinbob · 2014-07-16 13:11 · Score: 1
  
  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().
27. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 13:49 · Score: 0
  
  Entropy is the OS's job. LibreSSL only supports it's own RNG for compatibility with OpenSSL. The official LibreSSL on OpenBSD, ONLY supports the OS entropy pool and nothing else. It's not a flaw in LibreSSL, it's a flaw in the portability layer trying to accommodate bad practices.
28. Re:Shocked I am! Shocked! by Bengie · 2014-07-16 13:56 · Score: 0
  
  LibreSSL doesn't use CSPRNG, the Linux port uses it, against the recommendations of the LibreSSL.
  
  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.
29. Re:Shocked I am! Shocked! by rev0lt · 2014-07-16 14:30 · Score: 1
  
  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.
30. Re:Shocked I am! Shocked! by rev0lt · 2014-07-16 14:35 · Score: 1
  
  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?
31. Re:Shocked I am! Shocked! by WaffleMonster · 2014-07-16 15:11 · Score: 1
  
  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.
32. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 18:12 · Score: 1
  
  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.
33. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 18:18 · Score: 1
  
  >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.
34. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 18:33 · Score: 1
  
  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.
35. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 18:48 · Score: 1
  
  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.
36. Re:Shocked I am! Shocked! by lgw · 2014-07-16 19:02 · Score: 1
  
  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.
37. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-16 19:09 · Score: 1
  
  >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.
38. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 21:24 · Score: 0
  
  They relied on it as a last-effort after several (usually available on sane systems) other good safe ways have been found unavailable. no BSD will have an issue (unless senselesly configured to be unsafe) and only very rare cases of the portable users will even be theoretically insecure - again only on systems that in the first place arent secure or provides a secure rng of any kind. if this is a real issue on your system, your system have a lot of problems already.
39. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 21:33 · Score: 0
  
  Ah, you are working on a competing product, that explains all your negativity and mudslinging on this story.
40. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 23:25 · Score: 0
  
  It if was a deterministic PRNG for the purpose of producing deterministic sequences, then it would be fine.
  That's what a PRNG is. The P stands for pseudo, as in "pseudo random", as in "not really random at all".
  For cryptography, you want a real RNG, like /dev/urandom, and apparently this PRNG is only used if no real RNG is available, and even then, the PID is only used for the seed if no better seed is available.
41. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-17 04:35 · Score: 0
  
  It is Linux, why are you assuming an Intel CPU?
  That is a far bigger mistake than BSD developer not understanding Linux forking limitations.
42. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-17 06:11 · Score: 1
  
  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.
43. Re:Shocked I am! Shocked! by Darinbob · 2014-07-17 06:33 · Score: 1
  
  That was supposed to be sarcasm, I know it's hard for some people to detect it.
44. Re:Shocked I am! Shocked! by Anonymous Coward · 2014-07-17 06:49 · Score: 0
  
  Then why are you pointing to an Intel instruction that does not have an equivalent on my CPUs that Linux runs on?
  I think your hardware bias is showing.
  Another thing I have observed over decades of computer use. Most hardware people don't properly understand software development and most software people don't understand hardware development.
45. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-17 07:17 · Score: 1
  
  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.
46. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-17 07:26 · Score: 1
  
  No. Negativity is a normal condition for crypto oriented people.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
47. Re:Shocked I am! Shocked! by lgw · 2014-07-17 09:12 · Score: 1
  
  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.
48. Re:Shocked I am! Shocked! by Darinbob · 2014-07-17 10:08 · Score: 1
  
  Or the statement is so absurd that it can't possibly be taken seriously.
49. Re:Shocked I am! Shocked! by rev0lt · 2014-07-17 15:33 · Score: 1
  
  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.
50. Re:Shocked I am! Shocked! by rev0lt · 2014-07-17 15:37 · Score: 1
  
  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.
51. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-17 15:54 · Score: 1
  
  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.
52. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-17 16:13 · Score: 1
  
  >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.
53. Re:Shocked I am! Shocked! by rev0lt · 2014-07-18 01:42 · Score: 1
  
  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.
54. Re:Shocked I am! Shocked! by rev0lt · 2014-07-18 01:51 · Score: 1
  
  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...
55. Re:Shocked I am! Shocked! by andy.ruddock · 2014-07-18 02:55 · Score: 1
  
  You do realise this is /. don't you?
  
  --
  God: An invisible friend for grown-ups.
56. Re:Shocked I am! Shocked! by TechyImmigrant · 2014-07-18 03:43 · Score: 1
  
  I have heard enough. Feel free to stop digging.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
57. Re:Shocked I am! Shocked! by lgw · 2014-07-18 08:57 · Score: 1
  
  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.
called it by Anonymous Coward · 2014-07-16 09:29 · Score: 0

first security vulnerability to be discovered! in 3....2.......1............
Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 09:32 · 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.
Shocked I am! Shocked! by Anonymous Coward · 2014-07-16 09:40 · Score: 0

I've spent the past 5 years of my life fully employed in the design, creation, testing, and deployment of secure RNGs.
The world is full of bad PRNGs, NRNGs, CSPRNGs, DRBGs, TRNGs and any other form of RNG.
LibreSSL doesn't have a leg to stand on. A good secure RNG will return unpredictable output. A good PRNG will return data indistinguishable from random. A good CSPRNG will do that with guarantees on the computational complexity of predicting the output.
We know how to do these things. It isn't trivial, but it isn't hard either. Allowing someone to extract predictable behavior from the service end of a security library is a gross failure and an exposition of incompetence.
I can't tell if you are sarcastic or not. The headline makes me think you are, the last sentence of the post makes me think you might be honest. If you manage to get control of all the seeds for your RNG you get predictable results unless you go hardware random which makes the seed uncontrollable. You usually don't have that much control over the seeds not to mention getting the same PID twice. As someone else already mentioned that much control over the system means you don't need to get the RNG anymore, you already own the system.
sshutup-theo by Anonymous Coward · 2014-07-16 10:06 · Score: 0

OpenBSD founder Theo de Raadt and developer Bob Beck, however, countered saying that the issue is "overblown"
Yeah, last time he was complacent about the risk of an exploit being practically weaponizable, I seem to remember GOBBLES making him look rather foolish. "Dismissive about risks" is not a responsible attitude for a supposedly security-conscious project to adopt.
1. Re:sshutup-theo by Anonymous Coward · 2014-07-16 17:04 · Score: 0
  
  I think downplaying the risk in early test releases to avoid needless bad publicity like this isn't outside the realm of reason.
  Realistically even if it was entirely broken and exploitable in every known way, its a test release... you know that even great programs start out lacking many core features or have unexpected behaviors that's why testing exists...
LibreSSL cannot be different by being the same by ConstantineM · 2014-07-16 10:08 · Score: 1

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.
1. Re:LibreSSL cannot be different by being the same by gnu-sucks · 2014-07-16 12:18 · 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...
2. Re:LibreSSL cannot be different by being the same by Carnildo · 2014-07-16 14:52 · 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.
3. Re:LibreSSL cannot be different by being the same by Anonymous Coward · 2014-07-17 00:40 · 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.
4. Re:LibreSSL cannot be different by being the same by Anonymous Coward · 2014-07-17 04:49 · Score: 0
  
  Every single thread about this should have this post put at the top then immediately closed. It would save a lot of hot air.
Damn it's hard to find meaningful comments on slas by Anonymous Coward · 2014-07-16 10:14 · Score: 0

So many comments but so few actually took the time and have the necessary knowledge to comment. This community is horrible... ah Internet. This bug doesn't belong on Slashdot, it's meaningless.
Curious OS design shortcoming by fnj · 2014-07-16 10:23 · Score: 1

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.
1. Re:Curious OS design shortcoming by Anonymous Coward · 2014-07-16 10:45 · Score: 0
  
  what i think is funny, is the misrepresentation i am reading in " Ayer’s test program, when linked to LibreSSL and made two different calls to the PRNG, returned the exact same data both times.".
  as per one of the above comments, the grandchild's PID would have to be obtained from a roll-over event,
  so it wasn't technically 2 calls
  it's a multitude of calls from two callers
  eg. very rudimentary fuzzing?
  good idea on his part tho to test if he trusts a PRNG to not solely be based on PID :)
2. Re:Curious OS design shortcoming by gnasher719 · 2014-07-16 10:51 · Score: 1
  
  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.
3. Re:Curious OS design shortcoming by TechyImmigrant · 2014-07-16 10:57 · 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.
4. Re:Curious OS design shortcoming by Anonymous Coward · 2014-07-16 11:02 · Score: 0
  
  Why would using incrementing PIDs be any better than using the lowest free one? Or just a random unused PID?
5. Re:Curious OS design shortcoming by Anonymous Coward · 2014-07-16 11:11 · Score: 1
  
  FWIW, grsecurity (a patch for the Linux kernel) implements random-seeded PRNG-based unpredictable PIDs.
6. Re:Curious OS design shortcoming by nedlohs · 2014-07-16 11:13 · Score: 1
  
  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...
7. Re:Curious OS design shortcoming by Noryungi · 2014-07-16 11:14 · Score: 1
  
  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.
  
  --
  The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
8. Re:Curious OS design shortcoming by TechyImmigrant · 2014-07-16 11:24 · Score: 1
  
  Lets hope their PRNG is good :)
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
9. Re:Curious OS design shortcoming by TechyImmigrant · 2014-07-16 11:35 · Score: 1
  
  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.
  
  --
  I should use this sig to advertise my book ISBN-13 : 978-1501515132.
10. Re:Curious OS design shortcoming by Anonymous Coward · 2014-07-16 11:53 · Score: 0
  
  Why they shoud be?
  There's any technical reason for random pids being anything better than consecutive ones?
  They must just be unique, AFAIK that's the only requirement.
  If someone else uses it as a seed for a RNG, well... chose better.
11. Re:Curious OS design shortcoming by Anonymous Coward · 2014-07-16 13:26 · Score: 0
  
  the same PID a very recent process had
  If you fork bomb the machine, you go through pids very quickly.
  adequately large integers
  For the purpose of a process id, 15 bits is plenty for most systems. It is very rare to need 32000 running programs.
  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.
  Eventually you will hit the maximum number, at which point no new process could be created.
  Two, the pid is traditionally an index into the process table, which is a fixed size memory array allocated in kernel space. This is done for performance reasons. A 16 bit pid means 64k table entries.
  For the purposes pids are for, the method most *NIX systems use (and have used since the '70s) is about optimal. Using the pid as your PRNG seed is beyond stupid for several reasons:
  1) in early startup, running processes are often deterministic, so a program started during boot will often get the same pid across multiple boots.
  2) pid is usually only 15 bits, which is nowhere near adequate for a random seed. Using the system clock is actually better, and that was proven foolish 20 years ago.
  PRNG seeds should be read from /dev/random. That is why it exists. I am surprised Theo did this, he knows better.
NEWS FLASH! by Anonymous Coward · 2014-07-16 10:49 · Score: 0

SIGNED INT "ROLL-OVER" EVENT != 2 CALLS (unless properly staged)
Not realistic indeed. by gweihir · 2014-07-16 11:21 · Score: 1

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.
1. Re:Not realistic indeed. by maevius · 2014-07-16 21:19 · Score: 1
  
  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'....
2. Re:Not realistic indeed. by gweihir · 2014-07-17 04:20 · Score: 1
  
  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... 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...., but with the clear warning above. Also note that it says "OpenSSL will attempt to seed the random number generator automatically upon instantiation...", which is another warning not to trust the internal initialization.
  Now, I would say that this is enough to warn anybody. But in order to prevent people from shooting themselves in the foot, I agree that RAND_poll() should not even be there unless it works reliable or at least tells the user its success or lack thereof in a return code. (In a sense, it is not there. It likely should be hidden better though.) My guess would be that the LibreSSL team wants to remove this broken-by-design function and in a first step mistakenly disabled it, making the problem temporarily worse on some platforms. This also means that a careful developer will use RAND_seed() or RAND_add() and at most use RAND_poll() in addition. To prevent platform dependency, you can pull, say 256 bit from the CPRNG and use that with RAND_seed()/RAND_add() in the child, while the parent continues without using it. As RAND_poll() (if done right) may be quite slow, that is also superior from a performance perspective.
  Trusting these transparent mechanisms has historically been a real risk. A careful crypto user will know that. The last time it went haywire was with Android, where if you seeded in addition yourself, this wiped out the secure initialization. This was documented as well, but only in the Android Java pages, not the regular ones. And some 50k Apps fell for it. Seems solid understanding of crypto is still hard to come by. CPRNG seeding is critical and _must_ be done right. That includes reading and understanding all the documentation of the functions you use. The person using RAND_poll() after a fork clearly failed at that, by a) not reading or not understanding the documentation and b) using an internal, hidden function for a critical task. This had non-surprising consequences.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Should read by y5t3m · 2014-07-16 13:28 · Score: 1

LibreSSL prng vulnerable to psyops.
Patch the bug, move on by Anonymous Coward · 2014-07-17 00:45 · Score: 0

Shut the fuck up with your lame ass excuses