PRNG not fork-safe on FreeBSD

[jiixyj]

Hi,
LibreSSL uses the arc4random function directly on FreeBSD. The implementations of arc4random on FreeBSD and possibly other systems, such as NetBSD and DragonFly BSD, suffer from the PID wraparound issue described here: https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux.
I'm not sure how to implement a stir-less API on FreeBSD that can properly deal with forking. There does not seem to be anything like MAP_INHERIT_ZERO. There is "pthread_atfork(NULL, NULL, arc4random_stir)", but that is only available when using pthreads.

[bob-beck]

You need to take this up with FreeBSD - If arc4random is provided by the OS

• we use it. We have to assume the OS developers know they are doing the
  right thing in this case for their OS.

In a nutshell, our policy is generally

1. if the os provides arc4random, we use it, and assume it is correct for
   the os, otherwise we include arc4random.
2. if the os does not provide arc4random, but provides getentropy() we use
   it (inside arc4random) and assume it is correct for the os.

On Wed, Jul 16, 2014 at 2:27 PM, jiixyj notifications@github.com wrote:

Hi,
LibreSSL uses the arc4random function directly on FreeBSD. The
implementations of arc4random on FreeBSD and possibly other systems, such
as NetBSD and DragonFly BSD, suffer from the PID wraparound issue described
here: https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux.
I'm not sure how to implement a stir-less API on FreeBSD that can properly
deal with forking. There does not seem to be anything like
MAP_INHERIT_ZERO. There is "pthread_atfork(NULL, NULL, arc4random_stir)",
but that is only available when using pthreads.

—
Reply to this email directly or view it on GitHub
#17.

[bob-beck]

You need to take this up with FreeBSD - If arc4random is provided by the OS

• we use it. We have to assume the OS developers know they are doing the
  right thing in this case for their OS.

In a nutshell, our policy is generally

1. if the os provides arc4random, we use it, and assume it is correct for
   the os, otherwise we include arc4random.
2. if the os does not provide arc4random, but provides getentropy() we use
   it (inside arc4random) and assume it is correct for the os.

On Wed, Jul 16, 2014 at 2:27 PM, jiixyj notifications@github.com wrote:

Hi,
LibreSSL uses the arc4random function directly on FreeBSD. The
implementations of arc4random on FreeBSD and possibly other systems, such
as NetBSD and DragonFly BSD, suffer from the PID wraparound issue described
here: https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux.
I'm not sure how to implement a stir-less API on FreeBSD that can properly
deal with forking. There does not seem to be anything like
MAP_INHERIT_ZERO. There is "pthread_atfork(NULL, NULL, arc4random_stir)",
but that is only available when using pthreads.

—
Reply to this email directly or view it on GitHub
#17.

[bob-beck]

.. and to put it into context, I don't know of any piece of software in our
7000 package ports tree where this is a real issue. So I don't know what
priority FreeBSD will put on fixing it.

On Wed, Jul 16, 2014 at 2:32 PM, Bob Beck beck@obtuse.com wrote:

You need to take this up with FreeBSD - If arc4random is provided by the
OS - we use it. We have to assume the OS developers know they are doing the
right thing in this case for their OS.

In a nutshell, our policy is generally

1. if the os provides arc4random, we use it, and assume it is correct for
   the os, otherwise we include arc4random.
2. if the os does not provide arc4random, but provides getentropy() we use
   it (inside arc4random) and assume it is correct for the os.

On Wed, Jul 16, 2014 at 2:27 PM, jiixyj notifications@github.com wrote:

Hi,
LibreSSL uses the arc4random function directly on FreeBSD. The
implementations of arc4random on FreeBSD and possibly other systems, such
as NetBSD and DragonFly BSD, suffer from the PID wraparound issue described
here: https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux.
I'm not sure how to implement a stir-less API on FreeBSD that can
properly deal with forking. There does not seem to be anything like
MAP_INHERIT_ZERO. There is "pthread_atfork(NULL, NULL, arc4random_stir)",
but that is only available when using pthreads.

—
Reply to this email directly or view it on GitHub
#17.

[bob-beck]

.. and to put it into context, I don't know of any piece of software in our
7000 package ports tree where this is a real issue. So I don't know what
priority FreeBSD will put on fixing it.

On Wed, Jul 16, 2014 at 2:32 PM, Bob Beck beck@obtuse.com wrote:

You need to take this up with FreeBSD - If arc4random is provided by the
OS - we use it. We have to assume the OS developers know they are doing the
right thing in this case for their OS.

In a nutshell, our policy is generally

1. if the os provides arc4random, we use it, and assume it is correct for
   the os, otherwise we include arc4random.
2. if the os does not provide arc4random, but provides getentropy() we use
   it (inside arc4random) and assume it is correct for the os.

On Wed, Jul 16, 2014 at 2:27 PM, jiixyj notifications@github.com wrote:

Hi,
LibreSSL uses the arc4random function directly on FreeBSD. The
implementations of arc4random on FreeBSD and possibly other systems, such
as NetBSD and DragonFly BSD, suffer from the PID wraparound issue described
here: https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux.
I'm not sure how to implement a stir-less API on FreeBSD that can
properly deal with forking. There does not seem to be anything like
MAP_INHERIT_ZERO. There is "pthread_atfork(NULL, NULL, arc4random_stir)",
but that is only available when using pthreads.

—
Reply to this email directly or view it on GitHub
#17.

[janbrennen]

Just a bit of trivia that I think may need to be taken into account: OpenBSD 5.5's arc4random() call actually uses ChaCha20 and not {,A}RC4. As far as I know, Linux and other BSDs' arc4random() functions have not caught up with this.

[janbrennen]

Just a bit of trivia that I think may need to be taken into account: OpenBSD 5.5's arc4random() call actually uses ChaCha20 and not {,A}RC4. As far as I know, Linux and other BSDs' arc4random() functions have not caught up with this.

[bob-beck]

That little point is not important for that discussion. The fix would be
the same no matter if it was chacha or arc4.

On Wed, Jul 16, 2014 at 2:59 PM, Jan notifications@github.com wrote:

Just a bit of trivia that I think may need to be taken into account:
OpenBSD 5.5's arc4random() call actually uses ChaCha20 and not {,A}RC4. As
far as I know, Linux and other BSDs' arc4random() functions have not caught
up with this.

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

[bob-beck]

That little point is not important for that discussion. The fix would be
the same no matter if it was chacha or arc4.

On Wed, Jul 16, 2014 at 2:59 PM, Jan notifications@github.com wrote:

Just a bit of trivia that I think may need to be taken into account:
OpenBSD 5.5's arc4random() call actually uses ChaCha20 and not {,A}RC4. As
far as I know, Linux and other BSDs' arc4random() functions have not caught
up with this.

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

[jiixyj]

Thanks for your quick response. Sadly, all implementations of arc4random that I've looked at (except OpenBSD's) are not 100% fork safe. OS X's arc4random apparently is so bad that LibreSSL uses getentropy_osx.c instead.
Some "solutions":

• Keep using arc4random as is. The user must be aware that arc4random is used under the hood, and carefully work around its deficiencies on each platform until reliable fork detection with something like MAP_INHERIT_ZERO is implemented. Best in the long term, but won't help for current systems.
• Vendors providing arc4random_stir must think it may be needed in some situations where the OS lacks functionality. It may be dangerous to assume that arc4random works fine when arc4random_stir is present. Expose arc4random_stir via RAND_poll.
• Use pthread_atfork(NULL, NULL, arc4random_stir) at the cost of having to link against pthreads on some systems. May not work if the user calls the syscalls directly.

I'm not sure what the best solution is. All of them place some burden on the user. But then again, I agree that the example from the article may be a bit contrived. I just fear it might be somehow exploitable.

[jiixyj]

Thanks for your quick response. Sadly, all implementations of arc4random that I've looked at (except OpenBSD's) are not 100% fork safe. OS X's arc4random apparently is so bad that LibreSSL uses getentropy_osx.c instead.
Some "solutions":

• Keep using arc4random as is. The user must be aware that arc4random is used under the hood, and carefully work around its deficiencies on each platform until reliable fork detection with something like MAP_INHERIT_ZERO is implemented. Best in the long term, but won't help for current systems.
• Vendors providing arc4random_stir must think it may be needed in some situations where the OS lacks functionality. It may be dangerous to assume that arc4random works fine when arc4random_stir is present. Expose arc4random_stir via RAND_poll.
• Use pthread_atfork(NULL, NULL, arc4random_stir) at the cost of having to link against pthreads on some systems. May not work if the user calls the syscalls directly.

I'm not sure what the best solution is. All of them place some burden on the user. But then again, I agree that the example from the article may be a bit contrived. I just fear it might be somehow exploitable.

[bob-beck]

Sorry guys, we have to draw the line at what are supposed to be safe primitives. If your operating system provides getentropy() or arc4random() they should be equivalent to the reference implemention (On OpenBSD). If they have flaws, this is a bug in your operating system, not in LibreSSL. Failing that we make fixing the operating system our problem - which as we have seen already drags out the fun types who prefer to report bugs through yellow journalism than any other way. Going forward we want to have less compatibility layer in here, not more.

[bob-beck]

Sorry guys, we have to draw the line at what are supposed to be safe primitives. If your operating system provides getentropy() or arc4random() they should be equivalent to the reference implemention (On OpenBSD). If they have flaws, this is a bug in your operating system, not in LibreSSL. Failing that we make fixing the operating system our problem - which as we have seen already drags out the fun types who prefer to report bugs through yellow journalism than any other way. Going forward we want to have less compatibility layer in here, not more.