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

121–130 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#121

Post by floatboth »

lcampbell wrote: post #30
dobbsbob wrote: post #2

>First, LibreSSL should raise an error if it can't get a good source of entropy. Comments for getentropy_linux.c explain this http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/cryp... We have very few options: - Even syslog_r is unsafe to call at this low level, so there is no way to alert the user or program. - Cannot call abort() because some systems have unsafe corefiles.

> Cannot call abort() because some systems have unsafe corefiles. Huh, FreeBSD has MAP_NOCORE which allows the program to map pages that will explicitly not be included in the core file. I never realized that this was FreeBSD-specific extension (added in 2007?). I'm really surprised other platforms haven't adopted it, though I surmise there's a good technical reason or two. (EDIT: or maybe there's similar functionali…

Well, there is a way to disable core dumps entirely: setrlimit RLIMIT_CORE to 0

Re: LibreSSL's PRNG is Unsafe on Linux

#122

Post by DCKing »

jodiscr wrote: post #51
wbl wrote: post #48

Earlier quoted context omitted.

Ever hear of BSAFE? They took a million dollars from the NSA to implant a backdoor. How do you evaluate code you cannot see?

yes, but I'm talking about RNG from likes of Microsoft or Apple...

The RNG device for Mac OS X's XNU kernel is open source [1]. The kernel for OS X is open source and you can compile your own kernels if you want.

[1]: http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/bsd...

Re: LibreSSL's PRNG is Unsafe on Linux

#123

Post by anon1385 »

quotemstr wrote: post #119
vidarh wrote: post #115

Earlier quoted context omitted.

> Any application that does that is broken. Please stop trying to bring up this behavior as something a library needs to support. It isn't. If application try to close all file descriptors, then go on to do real work, plenty of things other than LibreSSL will break. It doesn't matter that it is broken. It matters whether or not it is done and how to deal with it when it happens. > If application try to close all file…

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

Re: LibreSSL's PRNG is Unsafe on Linux

#124

Post by AlyssaRowan »

quotemstr wrote: post #116
adobriyan wrote: post #112

Earlier quoted context omitted.

> No. open+read+close + all the mess associated with exhausting file descriptors > getentropy fairly obvious, isn't it?

Of course getentropy would be better . But the current mechanism is not wrong or broken: at best, it's inconvenient. And it's certainly no excuse for the LibreSSL authors to write a library that calls raise(SIGKILL) on file descriptor exhaustion. That behavior, in many cases, amounts to a remote DoS. As long as this code is in the library (even if off by default), I'm hesitant to recommend LibreSSL.

Without a way to getentropy(2) [hint] that doesn't use file descriptors, it has no other secure choice but to raise(SIGKILL) in my opinion; a mere error might be overlooked, but continuing to run could expose secrets and keys, which is much worse than a DoS condition (anything in file-descriptor exhaustion when under attack is already being DoSsed). (It's turned off because coredumps could also do that locally.)

Re: LibreSSL's PRNG is Unsafe on Linux

#125

Post by DCKing »

gpvos wrote: post #92
orik wrote: post #33

Earlier quoted context omitted.

It isn't about performance, but instead /dev/urandom is believed to be a poor source of entropy by the OpenBSD developers. I believe the heart of the issue it that /dev/urandom will give you a string even if it has very low entropy at the time. You can find all sorts of articles for and against /dev/urandom and I don't really know enough to comment on it's security, but I trust the that the team working on this fork…

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 that that was the reason the OpenBSD developers are dismissing it.

Re: LibreSSL's PRNG is Unsafe on Linux

#126

Post by [deleted] »

xorcist wrote: post #113
clarry wrote: post #111

Earlier quoted context omitted.

When your process forks, you end up with two processes with identical state. One or the other will need to reseed or the two processes are going to generate the exact same random stream.

I read the article again and now I think I understand: libressl has its own PRNG which is seeded separately from the system's. Now it's that descision I don't understand but I seems a lot of other people don't either. Thanks!

[deleted]

Re: LibreSSL's PRNG is Unsafe on Linux

#127

Post by AlyssaRowan »

ot wrote: post #63
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?

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 know of its behaviour if it is called too early in the boot process to have been safely seeded, but I hope it either errors loudly or blocks.

Re: LibreSSL's PRNG is Unsafe on Linux

#129

Post by enjolras »

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.

Re: LibreSSL's PRNG is Unsafe on Linux

#130

Post by buster »

quotemstr wrote: post #76
buster wrote: post #75

Earlier quoted context omitted.

How does a program set up the device node in the chroot if it's jailed in the chroot? Is that possible? Would any non-root program be able to create device nodes?

You have to be root (well, have CAP_SYS_CHROOT) to call chroot in the first place. If you're root, you can call mknod to create your device nodes.

So most programs can't "just create a device node".
Post reply on HN