Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LibreSSL's PRNG is Unsafe on Linux

agwa.name

Post reply on HN
Print view View original

131–140 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#131

Post by talideon »

AlyssaRowan wrote: post #127
ot wrote: post #63

Earlier quoted context omitted.

What are the advantages of a syscall in place of /dev/urandom?

Firstly: getentropy(2) is a /dev/random substitute, not urandom. You should call the process-context CSPRNG arc4random(3) in lieu of /dev/urandom. That should be in the standard library (and hopefully will be added). (It uses ChaCha20 nowadays, not RC4.) Secondly: It can fail with EINVAL (bad pointer) or EIO (>256 bytes requested), but does not fail even in a condition where file descriptors are exhausted. I don't kn…

> Firstly: getentropy(2) is a /dev/random substitute, not urandom.

Mind though that under the BSDs, there's no functional difference between /dev/random and /dev/urandom.

Re: LibreSSL's PRNG is Unsafe on Linux

#133

Post by maxlybbert »

DCKing wrote: post #125
gpvos wrote: post #92

Earlier quoted context omitted.

You're completely wrong. According to the OpenBSD devs, on modern BSDs and Linux, /dev/urandom is as good a source of entropy as anything. It's commonly implemented by a good cryptographically secure pseudo-random generator. This code only gets called in cases where /dev/urandom is not available (for example in a chroot jail or when the file descriptor limit is reached).

That was not his point. /dev/urandom on Linux does return low entropy strings when it simply doesn't have any at boot time. /dev/(u)random on BSD actually blocks until it has collected enough entropy to get going, and doesn't block thereafter. So BSD /dev/urandom is more secure in that it never gives bad random numbers for some baseline badness. He was not factually wrong about that, although he is wrong in stating t…

You are correct about BSD /dev/urandom vs Linux /dev/urandom. But since LibreSSL isn't likely to be used at boot time, it doesn't try to work around that issue. Instead, the concern is "what should we do if we can't open /dev/urandom?"

For what it's worth, the "exploit" requires (1) the user deny access to both /dev/urandom and the sysctl interface, (2) multiple levels of forks (a child never has the same PID as its parent, but a grandchild can have the same PID as its grandparent, and (3) the grandparent must exit before the grandchild (PIDs uniquely identify all running processes). It's not something that will happen by accident, even to incredibly careless programmers.

But I do agree with the BSD guys that Linux should have another way to get entropy in this case (note that they have a similar file for OS X for similar reasons). And I hope it's not named CryptGenRandomBytes().

Re: LibreSSL's PRNG is Unsafe on Linux

#134

Post by coder23 »

quotemstr wrote: post #72
pavpanchekha wrote: post #49

Earlier quoted context omitted.

A threading interface was standardized into C 2011, so pthreads should eventually stop being necessary. In a sense, not just POSIX, but C proper has adopted a threading interface.

The C threads interface is missing important functionality --- priority inheritance and static mutex initializers come to mind. C11 threads.h is a lowest-common-denominator portability shim, not a general-purpose pthreads replacement.

threads.h are the lowest common denominator. If you want system specific functionality you can always wrap those functions.

Static mutex init can be emulated with call_once() function, with some limitations of its own of course.

Re: LibreSSL's PRNG is Unsafe on Linux

#135

Post by drdaeman »

clarry wrote: post #110
drdaeman wrote: post #101

Earlier quoted context omitted.

Why setup the device when you should be able to open it way prior to chrooting (if you don't - that's a proper time to abort() on my book) and keep the descriptor open for later use?

What if the random numbers are needed not by the daemon that chroots itself, but by a separate program that gets exec()'d within the chroot?

A good point. Didn't thought about this case.

Re: LibreSSL's PRNG is Unsafe on Linux

#136

Post by nitrogen »

jodiscr wrote: post #53
nitrogen wrote: post #52

Earlier quoted context omitted.

If you can't evaluate it, you can't trust it. Plus, Apple had gotofail, and MS has had its share of issues as well.

can't evaluate > not enough funds to evaluate In other words, with proprietary sw, at least SOMEBODY evaluated it and placed their seal/name on it. With open source, you are relying on a hope that somebody out there somewhere does it. And in various cases, we've seen how that turned out.

These are the arguments people have been making for/against open source software for decades. They are old, tired, and well traveled. If we want to rehash them yet again, let's go to the Slashdot archives or Usenet and have a nostalgia party. Otherwise, let's try to focus on something actually interesting.

Re: LibreSSL's PRNG is Unsafe on Linux

#137

Post by DCKing »

maxlybbert wrote: post #133
DCKing wrote: post #125

Earlier quoted context omitted.

That was not his point. /dev/urandom on Linux does return low entropy strings when it simply doesn't have any at boot time. /dev/(u)random on BSD actually blocks until it has collected enough entropy to get going, and doesn't block thereafter. So BSD /dev/urandom is more secure in that it never gives bad random numbers for some baseline badness. He was not factually wrong about that, although he is wrong in stating t…

You are correct about BSD /dev/urandom vs Linux /dev/urandom. But since LibreSSL isn't likely to be used at boot time, it doesn't try to work around that issue. Instead, the concern is "what should we do if we can't open /dev/urandom?" For what it's worth, the "exploit" requires (1) the user deny access to both /dev/urandom and the sysctl interface, (2) multiple levels of forks (a child never has the same PID as its…

The "unlikely"s and "by accident"s in your comment are correct if and only if you assume too much about the scenario in which LibreSSL is to be deployed. It goes far beyond web servers, you know.

For example, what of routers that have no means of entropy input but interrupt timing? What of Android libraries that just use libcrypto? These systems are usually free to exploit by determined attackers!

LibreSSL/OpenSSL doesn't think "unlikely" and tries to cover as much as possible. The TLS library needs to work as good as possible regardless of the context.

Re: LibreSSL's PRNG is Unsafe on Linux

#138

Post by lomnakkus »

AlyssaRowan wrote: post #54
hsivonen wrote: post #40

Can we, please, have a syscall in Linux that returns random bytes from the system CSPRNG or blocks if not seeded yet and doesn't involve dealing with file descriptors? But even while one isn't available, why is LibreSSL trying to use a userland CSPRNG instead of always reading from /dev/urandom and aborting when that fails?

Yes. Actually, the relevant IETF list is now calling for that: Linux needs getentropy(2). I may cook up my own and submit it to LKML, or perhaps someone else can, but there's no way out of this one without kernel support. I don't know why the rest of the function even exists. It's the kind of cruft libReSSL is trying to get rid of. I am not entirely sure a PRNG should even exist in the library, and personally, I'd pa…

Please do submit it. Bonus points if you can make it work like BSD's random/urandom, i.e. block until the entropy estimator says "OK, it's secure to use now", but never block thereafter.

EDIT to add: Frankly, it's a disgrace that Linux doesn't already do this, instead choosing to push the burden of getting all the details right to userspace where you can be vulnerable to all sorts of interesting timing attacks, FD-based DoS, etc.

Re: LibreSSL's PRNG is Unsafe on Linux

#139

Post by yellowapple »

jodiscr wrote: post #46

Given things like the Debian OpenSSL fiasco and Heartbleed, can we honestly put as much faith into open source crypto as it's well-funded proprietary counterparts? I honestly prefer open source and recognize the problem the author points out as clearly significant problem - as well as the benefits of LibreSSL, but I'm just not convinced there are enough eyeballs looking at open source crypto.

Transparency is a dependency of trust. The "well-funded proprietary counterparts" are non-transparent (per the definition of "proprietary software"), and therefore are untrustworthy.

Re: LibreSSL's PRNG is Unsafe on Linux

#140

Post by ryan-c »

edwintorok wrote: post #77
pbhjpbhj wrote: post #45

Earlier quoted context omitted.

So, PID is used as part of the CSPRNG? If I get a block from /dev/urandom, then another one at some later time, what are the chances it's identical? Isn't that what you're saying here (or was the whole post intended to be comical and not just the last line). [If only it had been raining it would have taken days longer for the raptor to attack, or something /random]

The problem is that (Libre|Open)SSL doesn't use /dev/urandom directly and instead implements a CSPRNG in user-space (seeded from /dev/urandom). And then you need to be careful to reseed the CSPRNG after fork or you'll generate the same random number that the other process did. You could mix in the parent's PID too, but that would only delay the problem (you'd need more layers of fork before triggering the shared-stat…

/dev/urandom is pretty slow on Linux. OpenSSL's CSPRNG is several times faster. On my workstation just now, I get 13MB/sec from /dev/urandom and 61MB/sec from OpenSSL's CSPRNG.

You can't just add the parent pid because that information is lost when the process's parent exits (the ppid becomes 1).

Post reply on HN