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

21–30 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#21

Post by quotemstr »

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

> There's also pthread_atfork. That requires linking with libpthread, which a single-threaded program would not normally do. Otherwise, it's not a bad suggestion. Still, on top of everything LibreSSL does to automatically detect forks, it should still expose a way to explicitly reseed the PRNG in an OpenSSL-compatible way, since OpenSSL has made guarantees that certain functions will re-seed the PRNG, and there may b…

The libc on my system, Ubuntu 14.04, exports __register_atfork, which is documented here:

> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB...

pthread_atfork itself really should be moved into libc, however. (And POSIX should stop treating it as a redheaded stepchild: it's useful!)

Re: LibreSSL's PRNG is Unsafe on Linux

#22

Post by ryan-c »

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.

Re: LibreSSL's PRNG is Unsafe on Linux

#23

Post by agwa »

quotemstr wrote: post #16
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?

> How can 2 processes have the same PID, PID namespaces?

That's not what I was thinking but it sounds like yet another case where you could fool LibreSSL's fork detection.

Re: LibreSSL's PRNG is Unsafe on Linux

#24

Post by colmmacc »

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.

http://yarchive.net/comp/linux/getpid_caching.html

Reading that thread it seems like direct calls to clone(2) can bypass at least glibc's pid cache (which would likely also break LibreSSL's approach).

Any idea if direct calls to clone(2) also bypass pthread_atfork?

Re: LibreSSL's PRNG is Unsafe on Linux

#25

Post by agwa »

quotemstr wrote: post #13
dobbsbob wrote: post #12

Earlier quoted context omitted.

NSS does something similar since NSS will not be able to access /dev/urandom via file system after the sandbox activates the chroot so they reserve it first and fails with a log warning if no descriptors are available.

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 violation and move LibreSSL closer toward the (much maligned) OpenSSL approach to cross platform compatibility. I don't think this is a great excuse for the current design, but it's an explanation.

Re: LibreSSL's PRNG is Unsafe on Linux

#27

Post by rlpb »

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?

Re: LibreSSL's PRNG is Unsafe on Linux

#28

Post by agwa »

colmmacc wrote: post #24
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.

http://yarchive.net/comp/linux/getpid_caching.html Reading that thread it seems like direct calls to clone(2) can bypass at least glibc's pid cache (which would likely also break LibreSSL's approach). Any idea if direct calls to clone(2) also bypass pthread_atfork?

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

Re: LibreSSL's PRNG is Unsafe on Linux

#29

Post by quotemstr »

agwa wrote: post #28
colmmacc wrote: post #24

Earlier quoted context omitted.

http://yarchive.net/comp/linux/getpid_caching.html Reading that thread it seems like direct calls to clone(2) can bypass at least glibc's pid cache (which would likely also break LibreSSL's approach). Any idea if direct calls to clone(2) also bypass pthread_atfork?

> 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 cognizant of the implications.

Re: LibreSSL's PRNG is Unsafe on Linux

#30

Post by lcampbell »

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 functionality via another API? I haven't been able to turn up anything).

Post reply on HN