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

141–150 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#141

Post by devicenull »

anon1385 wrote: post #123
quotemstr wrote: post #119

Earlier quoted context omitted.

> Plenty of things that applications that do this will have to have successfully dealt with. If I have a choice of accommodating broken applications that close all file descriptors (and you have still not named one) and having a system in which libraries can retain internal kernel handles, I'll take the latter. LibreSSL already breaks compatibility with OpenSSL in areas like FIPS compliance. Compatibility with broken…

>applications that close all file descriptors (and you have still not named one) elinks: https://github.com/yggi49/elinks/blob/master/src/protocol/fi... https://github.com/yggi49/elinks/blob/master/src/protocol/co...

And example of what happens if you don't close all file descriptors: https://bugs.php.net/bug.php?id=38915

Re: LibreSSL's PRNG is Unsafe on Linux

#142

Post by edwintorok »

enjolras wrote: post #129
nwmcsween wrote: post #128

This is just due to ignorance, Linux provides a AT_RANDOM auxv on process creation that could be used to seed the prng.

look at the code. AT_RANDOM is. used when it's avaible in the fallback function. For some reason, the devs don't seem to trust it much, according to the comment.

Is it guaranteed to at least be different for different processes? They could use that in addition to the PID test to know when to reseed.

Re: LibreSSL's PRNG is Unsafe on Linux

#143

Post by quotemstr »

anon1385 wrote: post #123
quotemstr wrote: post #119

Earlier quoted context omitted.

> Plenty of things that applications that do this will have to have successfully dealt with. If I have a choice of accommodating broken applications that close all file descriptors (and you have still not named one) and having a system in which libraries can retain internal kernel handles, I'll take the latter. LibreSSL already breaks compatibility with OpenSSL in areas like FIPS compliance. Compatibility with broken…

>applications that close all file descriptors (and you have still not named one) elinks: https://github.com/yggi49/elinks/blob/master/src/protocol/fi... https://github.com/yggi49/elinks/blob/master/src/protocol/co...

That doesn't count. It's closing file descriptors before exec (and in one case, before doing some tightly-scoped work). It has nothing to do with closing all file descriptors, then expecting to use arbitrary third-party libraries.

Re: LibreSSL's PRNG is Unsafe on Linux

#144

Post by quotemstr »

devicenull wrote: post #141
anon1385 wrote: post #123

Earlier quoted context omitted.

>applications that close all file descriptors (and you have still not named one) elinks: https://github.com/yggi49/elinks/blob/master/src/protocol/fi... https://github.com/yggi49/elinks/blob/master/src/protocol/co...

And example of what happens if you don't close all file descriptors: https://bugs.php.net/bug.php?id=38915

Yes, letting child processes inherit stray file descriptors is dangerous. We're not talking about calling all file descriptors immediately before exec. We're talking about applications that say, "Ok now, I'm going to close all file descriptors and go back to what I was doing". You can't expect libraries to work when you're freed their internal resources from under them.

Re: LibreSSL's PRNG is Unsafe on Linux

#145

Post by AlyssaRowan »

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…

Just adding a link to the IETF discussion thread here (and yes, that's really what the randomness list is called!): https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms...

Theodore T'so isn't completely opposed to the idea, it seems.

Re: LibreSSL's PRNG is Unsafe on Linux

#146

Post by AlyssaRowan »

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.

"Many eyes make bugs shallow", goes the saying; but it's true that that does require that people actually do look at it - and with the state OpenSSL is in it's clear people took it for granted for years. I'm as guilty of that as you. It was ugly and crufty and I'd assumed and hoped that it'd been thoroughly reviewed and was the way it was because it was being conservative with changes; turns out no, actually it's a giant hairball which they're now shaving, BoringSSL is trimming, and LibReSSL is gleefully taking a combine harvester to!

But reflect on this: we're looking at it now. There are more eyeballs looking at open-source crypto than closed source crypto. Reflect on that for a moment, and on the RSA BSAFE/NSA 'enabling' and the like, and remember that being well-funded didn't stop Apple's source-available implementation from going directly to fail.

I wonder, for example, what's really under the hood of, say, Microsoft SChannel/CAPI/CNG? I'm a reverse-engineer (which means I don't need no stinking source code, given a large enough supply of chocolate) so I may look in detail, when I get a large enough patch of free time. I've heard it's not as bad as it could be… but I know on this subject, for example it ships Dual_EC_DRBG as alternative in CNG (but uses CTR_DRBG by default from Vista SP1 onwards, thank goodness). The old RtlGenRandom wasn't too great, I know that much.

Re: LibreSSL's PRNG is Unsafe on Linux

#147

Post by wahern »

edwintorok wrote: post #142
enjolras wrote: post #129

Earlier quoted context omitted.

look at the code. AT_RANDOM is. used when it's avaible in the fallback function. For some reason, the devs don't seem to trust it much, according to the comment.

Is it guaranteed to at least be different for different processes? They could use that in addition to the PID test to know when to reseed.

No. It's only filled on execve, not fork.

Re: LibreSSL's PRNG is Unsafe on Linux

#149

Post by edwintorok »

quotemstr wrote: post #11

There's also pthread_atfork. Use that to reset the PRNG. It's a bad interface, but it'll work for this purpose. It bothers me when people very solemnly and seriously condemn systems for problems that are, in fact, amenable to reasonable solutions.

Looks like they fixed it: https://github.com/libressl-portable/portable/commit/32d9eee... https://github.com/libressl-portable/openbsd/commit/c5188a3a...

And there's a new tarball out: http://marc.info/?l=openbsd-tech&m=140548206911600&w=2

Re: LibreSSL's PRNG is Unsafe on Linux

#150

Post by cnst »

What agwa wants 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 freely, so LibreSSL must do that, too? [Even if times have changed?](http://permalink.gmane.org/gmane.os.openbsd.cvs/129485)

Well, you can't really go at improving and cleaning up the library if you have to keep up 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.

LibreSSL is meant to be a simple-enough replacement of OpenSSL for most modern software out there (http://ports.su/) — possibly with some minimal patching (http://permalink.gmane.org/gmane.os.openbsd.tech/37599) of some of the outside software — and not a one-to-one drop-in-replacement for random edge cases that depend on random and deprecated OpenSSL craft.

Post reply on HN