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

71–80 of 151 posts

Re: LibreSSL's PRNG is Unsafe on Linux

#71

Post by quotemstr »

Buge wrote: post #35
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.

Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?

Re: LibreSSL's PRNG is Unsafe on Linux

#72

Post by quotemstr »

pavpanchekha wrote: post #49
quotemstr wrote: post #21

Earlier quoted context omitted.

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!)

A threading interface was standardized into C 2011, so pthreads should eventually stop being necessary. In a sense, not just POSIX, but C proper has adopted a threading interface.

The C threads interface is missing important functionality --- priority inheritance and static mutex initializers come to mind. C11 threads.h is a lowest-common-denominator portability shim, not a general-purpose pthreads replacement.

Re: LibreSSL's PRNG is Unsafe on Linux

#73

Post by justincormack »

colmmacc wrote: post #34
quotemstr wrote: post #29

Earlier quoted context omitted.

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

There is a test for this in the test suite so you get a warning.

Re: LibreSSL's PRNG is Unsafe on Linux

#74

Post by makomk »

gaadd33 wrote: post #56
quotemstr wrote: post #32

Earlier quoted context omitted.

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

Isn't this the same way that they do porting for OpenSSH? Why do you say that method is doomed when it seems to have been working fine for over 10 years?

For OpenSSH, they were using OpenSSL as an abstraction layer for various things, including entropy gathering.

Re: LibreSSL's PRNG is Unsafe on Linux

#75

Post by buster »

quotemstr wrote: post #71
Buge wrote: post #35

Earlier quoted context omitted.

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

Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?

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?

Re: LibreSSL's PRNG is Unsafe on Linux

#76

Post by quotemstr »

buster wrote: post #75
quotemstr wrote: post #71

Earlier quoted context omitted.

Sure you can access /dev/urandom: just set up the device node in advance of the chroot. For better or worse, /dev, /proc, and so on are all part of the Linux system API and provide functionality not found elsewhere. Why would you expect programs to work when deprived of part of the API?

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.

Re: LibreSSL's PRNG is Unsafe on Linux

#77

Post by edwintorok »

pbhjpbhj wrote: post #45
ryan-c wrote: post #22

Earlier quoted context omitted.

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.

So, PID is used as part of the CSPRNG? If I get a block from /dev/urandom, then another one at some later time, what are the chances it's identical? Isn't that what you're saying here (or was the whole post intended to be comical and not just the last line). [If only it had been raining it would have taken days longer for the raptor to attack, or something /random]

The problem is that (Libre|Open)SSL doesn't use /dev/urandom directly and instead implements a CSPRNG in user-space (seeded from /dev/urandom). And then you need to be careful to reseed the CSPRNG after fork or you'll generate the same random number that the other process did.

You could mix in the parent's PID too, but that would only delay the problem (you'd need more layers of fork before triggering the shared-state bug again).

Why can't LibreSSL just open /dev/urandom once, on first call to RAND_poll/RAND_bytes/some-other-init-function, etc. and then always read from it directly. If that first open fails then you return an error from RAND_poll/RAND_bytes.

Re: LibreSSL's PRNG is Unsafe on Linux

#78

Post by vidarh »

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.

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.

Re: LibreSSL's PRNG is Unsafe on Linux

#79

Post by vidarh »

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…

The issue is not that they believe /dev/urandom to be bad, but that it flat out isn't guaranteed to be available: If you're chroot'ed, chances are you won't have read access (or see) /dev/urandom. Furthermore, if you've run out of file handles (maybe intentionally - because someone figures they can try to DOS you to attack the PRNG), it is not a given you'll be able to open it even if it's visible.

LibreSSL tries /dev/urandom first, then falls back on a deprecated sysctl() interface, then tries it's own "last resort fallback".

Re: LibreSSL's PRNG is Unsafe on Linux

#80

Post by vidarh »

quotemstr wrote: post #70
adobriyan wrote: post #66

Earlier quoted context omitted.

Less syscalls.

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.
Post reply on HN