New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CVE-2022-28355] Scala.js should not provide a cryptographically insecure UUID.randomUUID() implementation
#4657
Comments
|
That is very unfortunate, and concerning. This code was introduced during the infancy of Scala.js, 8 years ago: Unfortunately, removing the method now is not an option, since that would break backward binary compatibility. We can only do so in Scala.js 2.0.0. The best we can do is mitigate the issue by using the available secure random facilities of recent browsers and Node.js when they are there. Hopefully, that will be good enough, as it's unlikely that such kind of security would be a concern in another obscure environment. I've never had to submit a CVE. I'll have to check what is involved there. |
|
We might do a similar thing we did with weakref for java.secure.Random or UUID. That would isolate the CVE into a single "fake" package. Most users will likely be OK to depend on |
|
Thanks for your attention to this. I was also thinking along the lines of of @gzm0's suggestion: isolate the current implementation into an aptly named "not-cryptographically-strong-uuid-use-at-your-own-risk" package, like the fake weakref. Then provide "webcrypto-uuid" and "node-uuid" packages, for example.
IMO I think it's best to let the users make this sort of judgement call. |
|
Ah yes, we could use a trick similar to The situation is a bit different, though, since for We might need to be a bit more creative than for the weak references. |
Well, not really. Libraries won't need UUID support for compiling. They may need it to run their tests, but that's only a test dependency. I do agree with your point though, that this is confusing. |
|
But then they would have to tell their users to add a dependency on some of the UUID libs? That's not helping. There is 0 chance we can clearly explain to all library maintainers how they must or must not depend on UUID and what to tell their users to do about that. |
|
The alternative is that we implement |
|
That's tempting from a linking architecture point of view but:
That is probably not acceptable. That would mean deliberately introduce in the ecosystem vulnerabilities that do not exist today, in order to mitigate one that does. Plus, while |
|
Ok, here's a new idea: what if we extract UUID into a separate artifact, that supports both Node.js and WebCrypto and throws a runtime error otherwise. This should cover the majority of use-cases, so libraries can depend on it without too much disruption for their users. By keeping it a separate artifact, it still gives opportunity for applications to specifically exclude that dependency and replace it with something else suitable for their obscure environment. It's not very convenient to do this, but it is possible. I think it's best to avoid providing the insecure implementation anywhere, if possible. It's what started this mess to begin with. Bonus points: add something to the sbt-scalajs plugin to make it easy to exclude the default UUID dependency. |
Well, if we are willing to go down that path, we can provide a But at that point, I do not see the upside of this compared to making |
|
I have requested a CVE for this issue. We'll see whether they actually give us one. From what I read about CVEs, this is a bit borderline when it comes to what "deserves" a CVE or not (it's a library method, and an actual vulnerability can only be created in a context-dependent fashion, based on how it's used). I have given more thoughts about the possible fixes here, also talking to some other people here to get ideas. I am actually warming up to the idea of depending on
For the latter, we could implement some CSPRNG algorithm. We would have to seed with a relatively bad source such as a combination of time + |
|
Thanks for looking into the CVE. Yes, I like the
This also sounds like a good idea, and is certainly better than using an insecure PRNG :) FWIW I'm still not entirely sure if anybody actually needs this, but I guess it's good to have just in case? |
|
After discussion with the Scala Center, actually implementing the CSPRNG as fallback in the insecure version does not seem to be worth it. At least not as an urgent thing to do right now. @gzm0 If that seems OK to you, I'll proceed with creating two repos for |
…cureRandom. Since Scala.js core does not implement `SecureRandom`, this means that `randomUUID()` will fail to link unless `SecureRandom` is otherwise provided. We move the tests for `randomUUID()` in the test-suite-ex, and we implement a fake `SecureRandom` in the javalib-ext-dummies for testing purposes.
|
SGTM. |
|
OK, the 3 PRs are open. As I see it, the next steps are:
(I am still waiting for a reply about the CVE number.) |
Fix #4657: Implement UUID.randomUUID() using java.security.SecureRandom.
|
We received the CVE number CVE-2022-28355 for this issue. |
UUID.randomUUID() implementationUUID.randomUUID() implementation
|
It seems there are some failures when upgrading Scala.js to 1.10 |
|
@Atry the Scala.js 1.10 release notes explain how to fix it :) |
|
Yes, that is expected. Please read the release notes: http://www.scala-js.org/news/2022/04/04/announcing-scalajs-1.10.0/ |
|
Thank you! I found the related issue in ScalaTest scalatest/scalatest#2116 |
…tingReporter. The UUIDs are only used as an in-memory identifier for `Slot`s. It is more efficient and more reliable to use an object identity instead, for that purpose. This removes the dependency on `UUID.randomUUID()`, which unblocks using ScalaTest with Scala.js >= 1.10.0. See GHSA-j2f9-w8wh-9ww4 and scala-js/scala-js#4657 for the reason why `randomUUID()` fails to link by default in recent Scala.js.
…tingReporter. The UUIDs are only used as an in-memory identifier for `Slot`s. It is more efficient and more reliable to use an object identity instead, for that purpose. This removes the dependency on `UUID.randomUUID()`, which unblocks using ScalaTest with Scala.js >= 1.10.0. See GHSA-j2f9-w8wh-9ww4 and scala-js/scala-js#4657 for the reason why `randomUUID()` fails to link by default in recent Scala.js.
* Remove dependency to UUID.randomUUID() as a workaround for scala-js/scala-js#4657 * [ci skip] fix comment
I'm specifically referencing this section of code:
scala-js/javalib/src/main/scala/java/util/UUID.scala
Lines 139 to 147 in 058532a
The Java 8 docs for
UUID.randomUUID()state:Furthermore, https://github.com/tc39/proposal-uuid states that:
It's unclear to me how a developer cross-compiling their library or application for Scala.js should become aware that in fact they cannot rely on
UUID.randomUUID()for cryptographically strong UUIDs.This seems a lot like a CVE to me.
See also discussion in typelevel/cats-effect#2882 (comment).
PS would be good to set up a security policy at https://github.com/scala-js/scala-js/security.
The text was updated successfully, but these errors were encountered: