Hacker News new | comments | show | ask | jobs | submit login

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 be some scenarios where even the best automatic fork detection fails (imagine a program calling the clone syscall directly for whatever reason, in which case pthread_atfork handlers won't be called). Since LibreSSL is billed as a drop-in replacement for OpenSSL, you should not be able to write a valid program that's safe under OpenSSL's guarantees but not when linked with LibreSSL.


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.


threads.h are the lowest common denominator. If you want system specific functionality you can always wrap those functions.

Static mutex init can be emulated with call_once() function, with some limitations of its own of course.


  That requires linking with libpthread, which a single
  threaded program would not normally do. Otherwise, it's
  not a bad suggestion.
Note that doesn't hold for Solaris, all of the thread functionality is in libc; libpthread only exists for historical compatibility at this point.


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.


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.


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


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.



Why would you want to reseed the PRNG?

If the PRNG is good enough (no visible correlation in the statistics tests you can imagine thrown at it), and it's properly seeded with true randomness, then isn't everything peachy?

I am much more afraid of the seeding part of it than the actual algorithm. The algorithms are well studied by smart people, the actual implementation and seeding aren't always.

There mere fact that one could reseed the PRNG makes me nervous. That could be used in devious ways. But I am not a cryptographer, not even a mathematician, so don't take my word for it!

Am I wrong here? Why?


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!




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: