Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

LibreSSL PRNG Vulnerability Patched

Soulskill posted about 4 months ago | from the looking-forward-to-the-next-two-day-panic dept.

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

Sorry! There are no comments related to the filter you selected.

You're holding the phone wrong (2, Funny)

Anonymous Coward | about 4 months ago | (#47470121)

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

Re:You're holding the phone wrong (4, Insightful)

maliqua (1316471) | about 4 months ago | (#47470891)

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

Re:You're holding the phone wrong (0)

Anonymous Coward | about 4 months ago | (#47471083)

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 (5, Insightful)

Jonathan C. Patschke (8016) | about 4 months ago | (#47470147)

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

Re:This is not how you inspire confidence (4, Interesting)

jandrese (485) | about 4 months ago | (#47470217)

To exploit this, you needed a program that was written like so:
1. Grandparent initializes SSL state, sends some data, then exits.
2. Parent forks a child
3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.

It's a program structure that doesn't make a whole lot of sense in the real world. Maybe it has happened somewhere.

The big issue is that the original discoverer found an easily filled molehill and somehow it got reported as a world destroying volcano across the the various tech sites. A minor flaw in the first public release of the test version of a library with no production users is not "catastrophic".

Re:This is not how you inspire confidence (1)

asmkm22 (1902712) | about 4 months ago | (#47470321)

Seems like the type of thing a malware author would design around in order to take advantage of a security flaw.

Re:This is not how you inspire confidence (4, Insightful)

QuietLagoon (813062) | about 4 months ago | (#47471503)

The LibreSSL developers apparently agreed that it was a bug that should be fixed, and fix it they did.

.
The discussion seems to center more around whether or not this was a "catastrophic" bug, or a "minor" bug. A bug in a library that has not yet seen a production release. So one really should ask, why not just report the bug and have it fixed, instead of seeking headlines?

There seem to be some people who would like to see the LibreSSL project fail. It makes one wonder why, as the OpenSSL near-monoculture has served the world so well.

Re:This is not how you inspire confidence (0)

Anonymous Coward | about 4 months ago | (#47472529)

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

Re:This is not how you inspire confidence (1)

asmkm22 (1902712) | about 4 months ago | (#47472547)

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.

Re:This is not how you inspire confidence (0)

Anonymous Coward | about 4 months ago | (#47470405)

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.

Re:This is not how you inspire confidence (4, Insightful)

viperidaenz (2515578) | about 4 months ago | (#47470455)

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

Re:This is not how you inspire confidence (0)

Anonymous Coward | about 4 months ago | (#47471073)

You can do pretty much anything you want

Except decrypt your SSL private key.

I suppose I could do a keylogger, though.

Re:This is not how you inspire confidence (2)

Jonathan C. Patschke (8016) | about 4 months ago | (#47470777)

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.

Re:This is not how you inspire confidence (4, Interesting)

Dishevel (1105119) | about 4 months ago | (#47470983)

What they did though was point out that the bug has almost no ability to really be exploited and then fixed it anyways.

I thought they did quite well.

Re:This is not how you inspire confidence (1)

cheater512 (783349) | about 4 months ago | (#47471257)

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 (4, Informative)

Qzukk (229616) | about 4 months ago | (#47471281)

OpenSSL's RNG is used in many places separately from the SSL communication protocol itself, sometimes just for encryption in general (S/MIME) or sometimes someone just wants really random bytes.

Many servers fork twice in order to reparent to init, repeated forking is a common idiom in unixland.

Apache with MPM-prefork forks a bunch of children from a master process, which is typically itself a descendant of apachectl. In apache's case, this shouldn't be a problem since the "master-process-rng" would have recognized the fork and reinitialized on the first openssl connection, so the children are protected because they cannot have the same PID as the master-process.

Where it would be a problem would be an application or daemon that starts up, initializes the RNG, forks twice, then without this fork touching the RNG, starts forking children to do something random (say, encrypting one file per process or establishing a single SSL connection per process or something). Without having the RNG reset by the master process, one in 65534 or so processes will have the exact same RNG, because it will have inherited the original RNG untouched and be assigned the PID that created the RNG.

Re:This is not how you inspire confidence (2)

gnu-sucks (561404) | about 4 months ago | (#47471593)

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 (4, Informative)

Bengie (1121981) | about 4 months ago | (#47471941)

It's not a flaw in LibReSSL, it's a flaw in the portability layer that only happens in non-OpenBSD OSes with situations where the sysadmin blocks access to /dev/urandom like a tard. The only reason the portability implementation even supports this fall-back is because there are a lot of stupid sysadmins using OpenSSL and LibReSSL needs to be as much a drop-in replacement as possible. It's a flaw in the bandaid for a situation that shouldn't happen, but does.

Re:This is not how you inspire confidence (1)

kesuki (321456) | about 4 months ago | (#47471639)

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.

Re:This is not how you inspire confidence (1)

phantomfive (622387) | about 4 months ago | (#47472539)

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 (-1)

Anonymous Coward | about 4 months ago | (#47470229)

I want your butthole on my cock.

Re:This is not how you inspire confidence (0)

Anonymous Coward | about 4 months ago | (#47470607)

I don't have a butthole, you insensitive clod! You can try sticking it my colostomy hole, though.

Re:This is not how you inspire confidence (2, Interesting)

Anonymous Coward | about 4 months ago | (#47470313)

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.

Re:This is not how you inspire confidence (0)

Anonymous Coward | about 4 months ago | (#47470951)

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

'Vulnerability" is rubbish. (5, Insightful)

gnasher719 (869701) | about 4 months ago | (#47470247)

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.

Re:'Vulnerability" is rubbish. (0)

Anonymous Coward | about 4 months ago | (#47470399)

Yup, there are easier ways to write bad software, and most of those would give you plausible deniability more easily.

Re:'Vulnerability" is rubbish. (1)

Bill, Shooter of Bul (629286) | about 4 months ago | (#47470847)

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.

Re:'Vulnerability" is rubbish. (0)

sinij (911942) | about 4 months ago | (#47470491)

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.

Re:'Vulnerability" is rubbish. (1)

Noryungi (70322) | about 4 months ago | (#47471091)

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:'Vulnerability" is rubbish. (0)

Anonymous Coward | about 4 months ago | (#47471627)

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.

Re:'Vulnerability" is rubbish. (2)

Bengie (1121981) | about 4 months ago | (#47472011)

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.

Re:'Vulnerability" is rubbish. (1)

sinij (911942) | about 4 months ago | (#47471993)

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.

Re:'Vulnerability" is rubbish. (1)

gnu-sucks (561404) | about 4 months ago | (#47471607)

Or a bad developer that assumes the PRNG is "good".

You're holding it wrong (0)

Anonymous Coward | about 4 months ago | (#47470323)

...

Field Tested (0)

Anonymous Coward | about 4 months ago | (#47470371)

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

Re:Field Tested (1)

Anonymous Coward | about 4 months ago | (#47470497)

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.

Re:Field Tested (0)

Anonymous Coward | about 4 months ago | (#47471019)

When did LibreSSL get audited, and how did the auditors miss this bug?

Re:Field Tested (1)

Anonymous Coward | about 4 months ago | (#47470807)

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

Re:Field Tested (0)

Anonymous Coward | about 4 months ago | (#47470973)

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

OpenBSD has never (1)

Anonymous Coward | about 4 months ago | (#47470445)

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:OpenBSD has never (2)

0123456 (636235) | about 4 months ago | (#47470487)

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 (1)

ConstantineM (965345) | about 4 months ago | (#47470831)

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.

Re:LibreSSL cannot be different by being the same (2)

gnu-sucks (561404) | about 4 months ago | (#47471613)

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 (5, Informative)

Carnildo (712617) | about 4 months ago | (#47472309)

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.

LibreSSL not ready for deployment yet (5, Insightful)

Kardos (1348077) | about 4 months ago | (#47470483)

> 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:LibreSSL not ready for deployment yet (1)

maliqua (1316471) | about 4 months ago | (#47471015)

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:LibreSSL not ready for deployment yet (1)

Noryungi (70322) | about 4 months ago | (#47471101)

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

Shocked I am! Shocked! (0)

TechyImmigrant (175943) | about 4 months ago | (#47470499)

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.
 

Shocked I am! Shocked! (2, Interesting)

Anonymous Coward | about 4 months ago | (#47470549)

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! (3, Insightful)

KiloByte (825081) | about 4 months ago | (#47470613)

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

Re:Shocked I am! Shocked! (0)

TechyImmigrant (175943) | about 4 months ago | (#47470663)

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:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47470895)

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.

Re:Shocked I am! Shocked! (1)

TechyImmigrant (175943) | about 4 months ago | (#47470941)

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:Shocked I am! Shocked! (1)

lgw (121541) | about 4 months ago | (#47471291)

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:Shocked I am! Shocked! (1)

Darinbob (1142669) | about 4 months ago | (#47471657)

If it got as far as the testing phase before the bug was found then the process must be broken!

Re:Shocked I am! Shocked! (-1)

Anonymous Coward | about 4 months ago | (#47471011)

The LibreSSL developers were not aware that Linux has a bug and instead of Linux developers fixing it in the kernel, people have chosen to blame LibreSSL.

Re:Shocked I am! Shocked! (5, Informative)

jandrese (485) | about 4 months ago | (#47470707)

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

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

Re:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47470595)

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 ?

Re:Shocked I am! Shocked! (0)

TechyImmigrant (175943) | about 4 months ago | (#47470689)

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:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47471041)

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?

Re:Shocked I am! Shocked! (2)

TechyImmigrant (175943) | about 4 months ago | (#47471209)

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.

Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47470605)

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.

Re:Shocked I am! Shocked! (2)

TechyImmigrant (175943) | about 4 months ago | (#47470729)

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:Shocked I am! Shocked! (1)

Darinbob (1142669) | about 4 months ago | (#47471793)

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.

Re:Shocked I am! Shocked! (2)

athe!st (1782368) | about 4 months ago | (#47470647)

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

Re:Shocked I am! Shocked! (1)

TechyImmigrant (175943) | about 4 months ago | (#47470769)

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.

Re:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47471047)

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.

Re:Shocked I am! Shocked! (1)

TechyImmigrant (175943) | about 4 months ago | (#47471121)

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:Shocked I am! Shocked! (0)

Bengie (1121981) | about 4 months ago | (#47472071)

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.

Re: Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47471057)

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.

Re:Shocked I am! Shocked! (1)

rev0lt (1950662) | about 4 months ago | (#47472227)

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:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47470857)

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.

Re:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47471055)

No, it indicates that people cannot understand the problem is with Linux and OpenSSL masked this kernel bug all these years.

Re:Shocked I am! Shocked! (1)

TechyImmigrant (175943) | about 4 months ago | (#47471133)

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:Shocked I am! Shocked! (1)

rev0lt (1950662) | about 4 months ago | (#47472245)

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?

Re:Shocked I am! Shocked! (1)

Darinbob (1142669) | about 4 months ago | (#47471859)

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

Re:Shocked I am! Shocked! (1)

Noryungi (70322) | about 4 months ago | (#47471239)

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 [random.org] . But don't take my word for it, go ahead and read this instead [dwheeler.com] .

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.

Re:Shocked I am! Shocked! (1)

TechyImmigrant (175943) | about 4 months ago | (#47471293)

>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:Shocked I am! Shocked! (1)

Noryungi (70322) | about 4 months ago | (#47471365)

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:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47471523)

And also, h/w rng's are hard to inspect for backdoors!

Re:Shocked I am! Shocked! (1)

WaffleMonster (969671) | about 4 months ago | (#47472369)

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.

Re:Shocked I am! Shocked! (0)

Anonymous Coward | about 4 months ago | (#47472033)

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.

sshutup-theo (0)

Anonymous Coward | about 4 months ago | (#47470817)

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.

Damn it's hard to find meaningful comments on slas (0)

Anonymous Coward | about 4 months ago | (#47470875)

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 (1)

fnj (64210) | about 4 months ago | (#47470927)

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.

Re:Curious OS design shortcoming (0)

Anonymous Coward | about 4 months ago | (#47471063)

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 :)

NEWS FLASH! (0)

Anonymous Coward | about 4 months ago | (#47471097)

SIGNED INT "ROLL-OVER" EVENT != 2 CALLS (unless properly staged)

Re:Curious OS design shortcoming (1)

gnasher719 (869701) | about 4 months ago | (#47471111)

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:Curious OS design shortcoming (2)

TechyImmigrant (175943) | about 4 months ago | (#47471155)

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:Curious OS design shortcoming (1)

Anonymous Coward | about 4 months ago | (#47471253)

FWIW, grsecurity (a patch for the Linux kernel) implements random-seeded PRNG-based unpredictable PIDs.

Re:Curious OS design shortcoming (1)

TechyImmigrant (175943) | about 4 months ago | (#47471327)

Lets hope their PRNG is good :)

Re:Curious OS design shortcoming (0)

Anonymous Coward | about 4 months ago | (#47471191)

Why would using incrementing PIDs be any better than using the lowest free one? Or just a random unused PID?

Re:Curious OS design shortcoming (1)

TechyImmigrant (175943) | about 4 months ago | (#47471405)

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.

Re:Curious OS design shortcoming (1)

nedlohs (1335013) | about 4 months ago | (#47471263)

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:Curious OS design shortcoming (1)

Noryungi (70322) | about 4 months ago | (#47471265)

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:Curious OS design shortcoming (0)

Anonymous Coward | about 4 months ago | (#47471501)

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.

Re:Curious OS design shortcoming (0)

Anonymous Coward | about 4 months ago | (#47471917)

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.

Not realistic indeed. (1)

gweihir (88907) | about 4 months ago | (#47471307)

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.

Should read (1)

Adam (3469959) | about 4 months ago | (#47471931)

LibreSSL prng vulnerable to psyops.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?