4 ms·

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 seri

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.

agwa 12y ago
> 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.
- quotemstr 12y ago
  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-Core-generic/baselib--register-atfork.html 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!)
  - pavpanchekha 12y ago
    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.
    - quotemstr 12y ago
      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.
      - coder23 12y ago
        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.
- binarycrusader 12y ago
  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.
colmmacc 12y ago
http://yarchive.net/comp/linux/getpid_caching.html 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?
- agwa 12y ago
  > 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().
  - quotemstr 12y ago
    > 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.
    - agwa 12y ago
      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.
    - colmmacc 12y ago
      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.
xorcist 12y ago
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?
- clarry 12y ago
  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.
  - xorcist 12y ago
    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!
    - deleted 12y ago
      [deleted]
edwintorok 12y ago
Looks like they fixed it: https://github.com/libressl-portable/portable/commit/32d9eeeecf4e951e1566d5f4a42b36ea37b60f35 https://github.com/libressl-portable/portable/commit/32d9eee... https://github.com/libressl-portable/openbsd/commit/c5188a3add7ae5189da041d891ec9435b7c53e00 https://github.com/libressl-portable/openbsd/commit/c5188a3a... And there's a new tarball out: http://marc.info/?l=openbsd-tech&m=140548206911600&w=2 http://marc.info/?l=openbsd-tech&m=140548206911600&w=2

agwa 12y ago

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

quotemstr 12y ago
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-Core-generic/baselib--register-atfork.html 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!)
- pavpanchekha 12y ago
  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.
  - quotemstr 12y ago
    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.
    - coder23 12y ago
      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.
binarycrusader 12y ago
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.

colmmacc 12y ago

http://yarchive.net/comp/linux/getpid_caching.html 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?

agwa 12y ago
> 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().
- quotemstr 12y ago
  > 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.
  - agwa 12y ago
    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.
  - colmmacc 12y ago
    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.

xorcist 12y ago

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?

clarry 12y ago
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.
- xorcist 12y ago
  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!
  - deleted 12y ago
    [deleted]

edwintorok 12y ago

Looks like they fixed it: https://github.com/libressl-portable/portable/commit/32d9eeeecf4e951e1566d5f4a42b36ea37b60f35 https://github.com/libressl-portable/portable/commit/32d9eee... https://github.com/libressl-portable/openbsd/commit/c5188a3add7ae5189da041d891ec9435b7c53e00 https://github.com/libressl-portable/openbsd/commit/c5188a3a... And there's a new tarball out: http://marc.info/?l=openbsd-tech&m=140548206911600&w=2 http://marc.info/?l=openbsd-tech&m=140548206911600&w=2