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

81–90 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#81

Post by vidarh »

agwa wrote: post #5
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.

The comments don't justify why going to the sketchy entropy is better than SIGKILLing the process, except with: > This code path exists to bring light to the issue that Linux does not provide a failsafe API for entropy collection. Trying to make a point about Linux doesn't seem like a very good reason to me.

It seems to be working, given the number of articles I've seen about this issue so far.

Re: LibreSSL's PRNG is Unsafe on Linux

#82

Post by vidarh »

agwa wrote: post #18
amalcon wrote: post #15

Note that the usual post-fork catch-all security advice (having the child process exec() to wipe process state, thereby making a state leak really hard) solves the fork safety problem by giving the child a whole new PRNG instance, but actually makes it harder to solve the chroot safety problem. There are various tricks to get a limited number of bytes from /dev/urandom into the chroot jail (such as by writing them to…

How about passing the /dev/urandom file descriptor to the new process? That seems like the most robust solution to me.

That assumes that first process after the chroot knows how to receive and pass on that filedescriptor to the process that will eventually use libressl, which is not a given.

Re: LibreSSL's PRNG is Unsafe on Linux

#83

Post by pling »

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.

Sorry but that's just an idiotic assertion.

Closed source proprietary crypto, you just don't know who wrote it, who audited it and who backdoored it and who knows of any flaws in it.

Open source crypto, it's there. Go read the source. Anyone can and it's open for audit.

There aren't enough eyeballs I agree but there are infinitely more trustworthy people looking at it than closed source.

Re: LibreSSL's PRNG is Unsafe on Linux

#84

Post by vidarh »

agwa wrote: post #59
blahrf wrote: post #55

Earlier quoted context omitted.

"If that's the case?" - Didn't you read the code? :) Sounds like you would prefer no stirring of any new entropy after you chroot... Looks to me like they're trying to require that additional entropy be available, always. (and if you don't have a completely hacked up kernel sysctl is still there..) - maybe we might get something better before it (sysctl) goes away for real instead of just in c-library-du-jour.

You're correct :-) - it does periodically stir in new entropy. I'm fine with stirring in new entropy after chrooting - I just don't want to see sketchy entropy being used, especially for the initial entropy source. If you could make LibreSSL open (and keep open) /dev/urandom before you chroot, LibreSSL could read additional entropy from the already open file descriptor, even after chrooting. In any case, note that th…

There are many potential cases where LibreSSL won't be initialized until after a chroot, by a program with no special rights running inside the chroot, that is entirely unable to open /dev/urandom or create a device node, so this is not a solution.

Re: LibreSSL's PRNG is Unsafe on Linux

#85

Post by djmdjm »

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?

Being able to call it from inside a chroot, or within a syscall-based sandbox (like SECCOMP_FILTER).

Re: LibreSSL's PRNG is Unsafe on Linux

#86

Post by quotemstr »

vidarh wrote: post #80
quotemstr wrote: post #70

Earlier quoted context omitted.

No. read(2) is one syscall, and the cost of the initial open is negligible. One real motivation seems to be wanting programs to work without a /dev. I don't think that's a reasonable requirement.

Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits.

> Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits.

That's why you open /dev/urandom in advance of performing operations that require randomness. If that open fails, you don't go on to perform the operation that requires randomness.

Re: LibreSSL's PRNG is Unsafe on Linux

#87

Post by [deleted] »

ryan-c wrote: post #22
darthsitius wrote: post #14

How can 2 processes have the same PID, even if it is grandparent and grandchild? When I try killing a process using the PID, how the kernel know which to kill?

Assume a fairly busy system * Original process with PID 17519 * PID 17519 forks producing a new process with PID 26606 * PID 17519 produces some "random" bytes then exits * PID 26606 forks producing a new process with the now unused PID 17519 * New PID 17519 produces some "random" bytes, which will be the same as the "random" bytes produced by original PID 17519, causing a raptor to attack the user.

[deleted]

Re: LibreSSL's PRNG is Unsafe on Linux

#88

Post by [deleted] »

vidarh wrote: post #78
quotemstr wrote: post #76

Earlier quoted context omitted.

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.

It is not a given that the process that runs LibreSSL at some point after the chroot happens will have CAP_SYS_CHROOT/root. Also, it doesn't solve the issue, as /dev/urandom will also be unaccessible temporarily if you run out of file handles.

[deleted]

Re: LibreSSL's PRNG is Unsafe on Linux

#89

Post by vidarh »

[deleted] wrote: post #88
vidarh wrote: post #78

Earlier quoted context omitted.

It is not a given that the process that runs LibreSSL at some point after the chroot happens will have CAP_SYS_CHROOT/root. Also, it doesn't solve the issue, as /dev/urandom will also be unaccessible temporarily if you run out of file handles.

[deleted]

I agree, partly. The problem is that LibreSSL needs to decide what to do. The comments in the file outline why they believe they have few options: They are concerned about aborting, because of potentially unsafe core files (consider if someone lets you execute a suid process in a chroot that has access to read SSL keys you should not have access to, and you can cause it to dump a core file that you can read simply by DOS'ing access to /dev/urandom), and lack of other safe ways of reporting failure.

Couple that with the fact that whether or not the /dev/ is set up correctly is a distraction: You have no guarantee that you will be able to open and read any file, as they can not guarantee that there's nothing available on the server that can't easily be used to hit file descriptor limits for a suitable process or open file limits for the entire system.

So this problem is there regardless of whether or not you're willing to demand a correctly configured /dev.

Re: LibreSSL's PRNG is Unsafe on Linux

#90

Post by vidarh »

quotemstr wrote: post #86
vidarh wrote: post #80

Earlier quoted context omitted.

Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits.

> Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits. That's why you open /dev/urandom in advance of performing operations that require randomness. If that open fails, you don't go on to perform the operation that requires randomness.

Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. Yes, that would be stupid of the user of the library, but many security lapses happens because people makes stupid assumptions. Code to close all file descriptors on fork for example is fairly common, so you can not safely assume that the file descriptor remains valid.
Post reply on HN