The Math.random implementation in Hermes is collision prone for the App use case

[psaha-rbi]

Bug Description

The implementation is

CallResult<HermesValue> mathRandom(void *, Runtime &runtime, NativeArgs) {
  RuntimeCommonStorage *storage = runtime.getCommonStorage();
  if (!storage->randomEngineSeeded_) {
    std::minstd_rand::result_type seed;
    seed = std::random_device()();
    storage->randomEngine_.seed(seed);
    storage->randomEngineSeeded_ = true;
  }
  std::uniform_real_distribution<> dist(0.0, 1.0);
  return HermesValue::encodeUntrustedNumberValue(dist(storage->randomEngine_));
}

As you can see, it uses std::random_device() as seed. It is an unsigned int and therefore there are only about 4B possible values. There is a 71% chance of a single collision if you generate 100k values using the Birthday problem formulation. So many different instances of this will go through the exact same sequence. While this is not used for security, this is also unusable for things like UUID v4 generation since there will be tons of collisions.

Please consider using a much larger seed space - ideally, 100+ bits. A simple way would be to concatenate multiple outputs from std::random_device().

• I have run gradle clean and confirmed this bug does not occur with JSC

Hermes version: latest
React Native version (if any): all
OS version (if any): all
Platform (most likely one of arm64-v8a, armeabi-v7a, x86, x86_64): all

Steps To Reproduce

Theoretical but we have seen collisions matching the birthday problem formula out in the wild.

code example:

The Expected Behavior

Much harder to produce collisions.

[tmikov]

Hi, I removed the "bug" label, since this not a bug - EcmaScript specifies it as implementation defined and puts no requirements for its "randomness".

Can you provide links to the relevant implementations in v8 or JSC? If we are to change this, we should probably match their behavior.

The best way to improve this would probably be to submit a PR.

[tmikov]

Also, can you please clarify your 4B values comment. That is just the seed, which is used once. How does it affect the quality of the values that are generated after?

[psaha-rbi]

@tmikov If two instances of the PRNG are seeded with the same value then they'll generate the same sequence of pseudo-random values. In this case, let's say you have 1M Hermes instances. In about 7 of them, the randomEngine_ will have the same seed and therefore end up generating the same sequence of "random" values. Now imagine an app that starts up and generates a sequence of UUID v4s. In 7 out of that million instances, you get the exact same sequence of uuid v4s.

Here's a good blog post that explains similar issues much better than I can

[psaha-rbi]

Hi, I removed the "bug" label, since this not a bug - EcmaScript specifies it as implementation defined and puts no requirements for its "randomness".

Can you provide links to the relevant implementations in v8 or JSC? If we are to change this, we should probably match their behavior.

The best way to improve this would probably be to submit a PR.

here's the v8 one
As you can see, it uses a 64 bit seed - so much less chance of a collision if the seeds are uniformly distributed.

[here's the JSC one] (https://github.com/WebKit/WebKit/blob/32f02266555bda2527e0a5fc1b9126bd33555a8e/Source/WTF/wtf/WeakRandom.h#L64) It seems to have 32 bit seed and therefore has the same problem as Hermes.

[johnculviner]

I think it's important to note that this issue is prone to happening specifically because this issue is deemed out of scope. There isn't a built in cryptographically secure mechanism to PRNG which can cause collisions when using libraries that may fall-back to Math.random() like some versions of https://www.npmjs.com/package/uuid .

I think increasing the seed-space should be done at a minimum to reduce likelihood of collisions which we have personally observed using UUID with it's Math.random() fallback.

Ideally it'd be great to see crypto built in too since this is an enormous potential (as in a pure probability game!) foot-gun when using hermes but I understand your concerns on the other issue.

[tmikov]

@johnculviner it is not really out of scope. See #1003 where we asked for a PR. It is just something that we don't feel competent to implement, especially since we won't use it.

[tmikov]

@psaha-rbi Thanks for posting the v8 and JSC links. I see at least two complications:

1. Where do we get a good 64-bit seed from in a portable way? If not, we would need multiple implementations, at least for Apple, Android, Linux, Windows. Seems like v8 is using a random generator for the seed (why?), but presumably that generator itself is seeded somewhere.
2. minstd_rand apparently takes a 32-bit seed.

This does not appear to be a trivial fix.

[purujit]

@psaha-rbi Thanks for posting the v8 and JSC links. I see at least two complications:

1. Where do we get a good 64-bit seed from in a portable way? If not, we would need multiple implementations, at least for Apple, Android, Linux, Windows. Seems like v8 is using a random generator for the seed (why?), but presumably that generator itself is seeded somewhere.
2. minstd_rand apparently takes a 32-bit seed.

This does not appear to be a trivial fix.

1. You can use a similar technique as v8. On BSD (and Darwin) it uses the ARC4 algorithm to get a 64 bit seed. The ARC4 system itself (I think) tries to get entropy from the kernel and therefore, should be able to give a good random 64 bit seed. Or trivially, assuming std:: random_device() is a good implementation, you can just concat two 32 bit random numbers from it. At least in the LLVM implementation, it seems to do the right thing for std:: random_device (https://github.com/llvm/llvm-project/blob/f2517cbceec0bd9b049ba24f36cb3a2508c988fa/libcxx/src/random.cpp#L67)
2. It looks like if you use 64 bit LCG (minstd_rand is the 32 bit version of this) you can use a 64 bit seed

[chakrihacker]

Can I give it a try??

[tmikov]

@chakrihacker you don't need to ask for permission. Hermes is open source, anyone can submit a PR. We can't "assign tasks" to people 😀

[woshiccm]

Hi @tmikov @psaha-rbi I have created a PR, please review it, thanks #1171

[tmikov]

@psaha-rbi to confirm, assuming we had a random generator with a 64-bit seed, would constructing the seed by two calls to std::random_device()() eliminate the problem?

[tmikov]

@woshiccm thanks for the PR! Can you please explain your solution in detail? How it addresses the problem - is using system time considered good enough? Also, what random generator algorithm are you using? Is it a standard one?

[purujit]

I'm not a fan of the time based solution from @woshiccm since it depends on the clock resolution of the system. I think calling random_device() twice to construct a 64 bit seed and using a 64 bit LCG is a better solution like @tmikov proposed. (Responding from my personal account, I'm @psaha-rbi).

[sebholl]

I put up an alternate PR here: #1175

[woshiccm]

I'm not a fan of the time based solution from @woshiccm since it depends on the clock resolution of the system. I think calling random_device() twice to construct a 64 bit seed and using a 64 bit LCG is a better solution like @tmikov proposed. (Responding from my personal account, I'm @psaha-rbi).

OK, I have refer to v8's code to implement it, could you pls help review again @tmikov @purujit #1171

[tmikov]

Fixed in 34f0b2b