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

31–40 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#31

Post by agwa »

quotemstr wrote: post #29
agwa wrote: post #28

Earlier quoted context omitted.

> The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle. Wow, great find! LibreSSL could avoid this by calling the getpid() syscall directly. > Any idea if direct calls to clone(2) also bypass pthread_atfork? They do, since atfork handlers are invoked by the userspace wrapper for fork().

> They do, since atfork handlers are invoked by the userspace wrapper for fork(). I don't think user libraries should try to deal with users subverting the facilities on which they rely. There are defined interfaces to system functionality. Break or bypass these interfaces, and you're on your own. If you subvert the usual API semantics by calling clone(2) directly or bypassing the fork(2) wrappers, you should be cogn…

I would agree, were LibreSSL designing its API from scratch. The problem is that OpenSSL's API provides a way to explicitly reseed the PRNG, so a programmer doing something nutty like bypassing the fork() wrapper has a way to make sure the PRNG is still safe to use. If LibreSSL wants to be a drop-in replacement for OpenSSL, its API needs to provide the same functionality.

Edit: to be clear, none of this is an argument against using pthread_atfork - I just want LibreSSL to provide an explicit way to reseed the PRNG like OpenSSL does.

Re: LibreSSL's PRNG is Unsafe on Linux

#32

Post by quotemstr »

agwa wrote: post #25
quotemstr wrote: post #13

Earlier quoted context omitted.

Warn? Hell, I'd hard-fail. Libraries need resources to do their jobs. The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle.

> The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle. To be fair to the LIbreSSL devs, the Linux-specific /dev/urandom code is currently encapsulated rather nicely behind an interface that's compatible with the OpenBSD getentropy() syscall. Following your suggestion would create a layer v…

> Following your suggestion would create a layer violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility.

The OpenSSL approach to portability is doomed: it can only deal with cosmetic differences between platforms. I appreciate the principle of using compatibility functions instead of #ifdef, but at some point, you need to incorporate the panoply of architectures into your design. It galls me to see the OpenBSD people claim that Linux is broken merely because it is different. That's incredibly arrogance.

Re: LibreSSL's PRNG is Unsafe on Linux

#33

Post by orik »

rlpb wrote: post #27

Why must it have its own PRNG? Is there a problem asking the kernel (via /dev/urandom) for all required entropy, at the time it is needed? Or would this cause a real-world performance problem? Surely this is an obvious first question that all commentators are stepping over?

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 more than I trust the OpenSSL foundation.

Re: LibreSSL's PRNG is Unsafe on Linux

#34

Post by colmmacc »

quotemstr wrote: post #29
agwa wrote: post #28

Earlier quoted context omitted.

> The key is to acquire resources in places that can fail and use them in places that can't. I'm amazed and disappointed that the LibreSSL people aren't following this basic principle. Wow, great find! LibreSSL could avoid this by calling the getpid() syscall directly. > Any idea if direct calls to clone(2) also bypass pthread_atfork? They do, since atfork handlers are invoked by the userspace wrapper for fork().

> They do, since atfork handlers are invoked by the userspace wrapper for fork(). I don't think user libraries should try to deal with users subverting the facilities on which they rely. There are defined interfaces to system functionality. Break or bypass these interfaces, and you're on your own. If you subvert the usual API semantics by calling clone(2) directly or bypassing the fork(2) wrappers, you should be cogn…

It would not be unreasonable for a runtime or VM (like a JVM for example) to use a native library for TLS (performance reasons). It would also not be unreasonable for a VM to use clone() directly, maybe it's part of how it implements its own threading or co-routines for example.

Combine those two reasonable patterns with LibreSSL, and suddenly you have a vulnerability. This is even more likely when you take into consideration that LibreSSL is intended as a direct replacement for OpenSSL; callers are even less likely to examine the fine print of the documentation for undefined and unsupported behaviour.

Still, the LibreSSL work is commendable and should be appreciated. The real problem is a lack of good regression tests - and there may be a messy future of niggly issues because of that. I've already had to deal with some.

I'll give another tricky example. One of the earliest pieces of functionality LibreSSL ripped out was an in-library DNS cache. It was poorly documented and the assumption was that it was there as a crutch for shoddy OS-level DNS caching. But I think this cache also played another role; it helped certificate validation workflows function. Sometimes endpoints bind different certificates to different IP addresses for the same DNS-name that uses DNS-level load balancing. If you don't make the name resolve to the same IP address consistently, then what can happen is that the first connect() gets certificate "A" and some user-facing UI or validation process authenticates it, but then then another connect() gets certificate "B" and the caller logic gets confused.

Of course we could blame the caller; or the folks mixing certificates for the same name, but it doesn't really help; users still experience these problems. Just one example of why it is very hard to remove code in fully backwards compatible ways, even if the change seems very innocuous.

Re: LibreSSL's PRNG is Unsafe on Linux

#35

Post by Buge »

rlpb wrote: post #27

Why must it have its own PRNG? Is there a problem asking the kernel (via /dev/urandom) for all required entropy, at the time it is needed? Or would this cause a real-world performance problem? Surely this is an obvious first question that all commentators are stepping over?

It mentions chroot jails in which you can't access /dev/urandom.

Re: LibreSSL's PRNG is Unsafe on Linux

#36

Post by tcoppi »

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…

Linux since 3.4 has MADV_DONTDUMP [1], and there also appears to be a /proc filter file you can use to exclude general segments of memory from being dumped [2].

1. http://man7.org/linux/man-pages/man2/madvise.2.html

2. http://man7.org/linux/man-pages/man5/core.5.html

Re: LibreSSL's PRNG is Unsafe on Linux

#37

Post by elithrar »

orik wrote: post #33
rlpb wrote: post #27

Why must it have its own PRNG? Is there a problem asking the kernel (via /dev/urandom) for all required entropy, at the time it is needed? Or would this cause a real-world performance problem? Surely this is an obvious first question that all commentators are stepping over?

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…

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

On OpenBSD, /dev/urandom does the right thing, unlike Linux. As per http://www.2uo.de/myths-about-urandom/ -

> FreeBSD does the right thing: they don't have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won't block ever again.

Re: LibreSSL's PRNG is Unsafe on Linux

#38

Post by quotemstr »

tcoppi wrote: post #36
lcampbell wrote: post #30

Earlier quoted context omitted.

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

Linux since 3.4 has MADV_DONTDUMP [1], and there also appears to be a /proc filter file you can use to exclude general segments of memory from being dumped [2]. 1. http://man7.org/linux/man-pages/man2/madvise.2.html 2. http://man7.org/linux/man-pages/man5/core.5.html

It's hard to blacklist every piece of memory that might be sensitive. It's a much better idea, IMHO, to just put corefiles in a location accessible only to root. That's how Windows, OS X, Ubuntu, Android, and lots of other commercial systems work.

Re: LibreSSL's PRNG is Unsafe on Linux

#39

Post by amalcon »

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 does work well.

Re: LibreSSL's PRNG is Unsafe on Linux

#40

Post by hsivonen »

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?

Post reply on HN