[#88925] [Ruby trunk Feature#15095] [PATCH] share VM stack between threads and fibers if identical — ko1@...
Issue #15095 has been updated by ko1 (Koichi Sasada).
4 messages
2018/09/09
[#88927] Re: [Ruby trunk Feature#15095] [PATCH] share VM stack between threads and fibers if identical
— Eric Wong <normalperson@...>
2018/09/09
ko1@atdot.net wrote:
[#88926] [Ruby trunk Feature#15095] [PATCH] share VM stack between threads and fibers if identical — ko1@...
Issue #15095 has been updated by ko1 (Koichi Sasada).
3 messages
2018/09/09
[#89218] [Ruby trunk Bug#15130] open-uri hangs on cygwin — duerst@...
Issue #15130 has been updated by duerst (Martin D端rst).
5 messages
2018/09/30
[ruby-core:88802] [Ruby trunk Bug#15039] Random.urandom and SecureRandom arc4random use
From:
tom@...
Date:
2018-09-01 16:19:53 UTC
List:
ruby-core #88802
Issue #15039 has been updated by Freaky (Thomas Hurst).
shyouhei (Shyouhei Urabe) wrote:
> While I'm not against these points, I feel it is not a good idea to wait for such new API. Can we focus on fixing FreeBSD first? Maybe the OpenBSD issue should be handled separately in another thread.
Yeah, I guess for now let's focus on making sure we're only using arc4random_buf() where it's a modern CSPRNG with robust fork detection.
OpenBSD has since 5.6: https://www.openbsd.org/plus56.html "Use MAP_INHERIT_ZERO in arc4random(3), to zero out the RNG state if the process forks."
NetBSD has since 7.0 (ChaCha20, uses MAP_INHERIT_ZERO): https://github.com/NetBSD/src/blob/netbsd-7-0/lib/libc/gen/arc4random.c
FreeBSD has since this commit to 12-CURRENT: https://v4.freshbsd.org/commit/freebsd/src/338061
So something like:
#if (defined(__OpenBSD__) && OpenBSD >= 201411) || \
(defined(__NetBSD__) && __NetBSD_Version__ >= 700000000) || \
(defined(__FreeBSD__) && __FreeBSD_version >= 1200079)
Earlier versions are likely to be ARC4 and/or have weaker fork detection vulnerable to pid wraparounds.
----------------------------------------
Bug #15039: Random.urandom and SecureRandom arc4random use
https://bugs.ruby-lang.org/issues/15039#change-73842
* Author: Freaky (Thomas Hurst)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v:
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
Random.urandom defaults to arc4random() on a lot of platforms, including FreeBSD.
On all currently released versions of FreeBSD, arc4random() is, as the name suggests, a dubious ARC4-based userspace PRNG dating from circa 1997. Given the entire point of #9569 was that using the userspace CSPRNG in OpenSSL over /dev/urandom or equivalent is a bad idea, this seems to mean it's regressed to an *even worse* state on these platforms. Even in cases where it's using something more modern (FreeBSD 12, OpenBSD), it's still a userspace CSPRNG.
If that's fine, we might as well *pick a known-good one* and use that everywhere. Like, say, OpenSSL's.
Since the conclusion of #9569 seems to have been otherwise, I'd suggest dropping arc4random() as a potential source for Random.urandom due to it not matching the desired semantics.
Rust's OsRng seems a good template for alternative _syscall implementations: https://docs.rs/rand/0.5.5/rand/rngs/struct.OsRng.html#platform-sources
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>