Community
Participate
Working Groups
# [CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)](https://cwe.mitre.org/data/definitions/338.html) This codebase is using an insecure source of randomness to generate random values. This codebase relies upon apache commons lang3 `RandomStringUtils`. (If you look at the source code for RandomStringUtils in leshan you will see it's a direct copy/paste from the Apache version) From the documentation: > Caveat: Instances of Random, upon which the implementation of this class relies, are not cryptographically secure. > \- https://commons.apache.org/proper/commons-lang/javadocs/api-3.9/org/apache/commons/lang3/RandomStringUtils.html ## Examples Here are the examples of this project's use of an insecure PRNG: - https://github.com/eclipse/leshan/blob/13ee2cb236b5c8ef7658205fcf6f16d300a39853/leshan-server-core/src/main/java/org/eclipse/leshan/server/registration/RandomStringRegistrationIdProvider.java#L23-L26 ## Existing Proof of Concept There has been a POC of taking one value generated `RandomStringUtils` and reversing it to generate all of the past/future RNG values public since March 3rd, 2018. https://medium.com/@alex91ar/the-java-soothsayer-a-practical-application-for-insecure-randomness-c67b0cd148cd ## Implications All that is required is that an attacker acquires one random value generated by `RandomStringUtils` and, using the POC above, they can reverse what all future values. ## Existing Vulnerabilities A similar vulnerability was discovered in JHipster. The NVD gave that vulnerability a CVSSv3 score of 9.8/10 (CRITICAL). https://nvd.nist.gov/vuln/detail/CVE-2019-16303 ## Responsible Disclosure Policy **This responsible disclosure follows Google's [90-day vulnerability disclosure policy](https://www.google.com/about/appsecurity/) (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.** Bug Bounties are appreciated but not expected or required.
> Bug Bounties are appreciated but not expected or required. Ignore that. I know the eclipse foundation doesn't offer BB. It was just a leftover from my copy/paste template.
I've added the project leads for Eclipse Leshan in copy since that project owns the cited code. I'll also do a quick survey to see if I can identify other uses of RandomStringUtils.
If the project team determines that we should issue our own related CVE on the topic, the instructions are here: https://www.eclipse.org/projects/handbook/#vulnerability-cve
Thx a lot Jonathan Leitschuh to reporting this. I think I get your point about insecure PRNG, but in this case registrationId is not a cryptography id. It's just an identifier for the registration. Like you could have an identifier for an entry in database table. In real case scenario, registrationId will only be transmitted in some DTLS APPLICATION_DATA. Even if someone is able to guess a registrationId, we always ensure that client which would like to modify it, have the correct DTLS identity (psk, rpk or certificate). So I'm not sure there is a real security issue here.
I wasn't ever able to confirm that this ID was being used in a security-sensitive location, it just looked like it was being used to identify a user, and those unique identifiers usually end up propagating out to a client (from past experience with ids like this). If this ID is truly never used for identifying a user in such a way that being able to determine other users ID's wouldn't allow account/session takeover this report can be ignored. If you want to be safe though, consider just moving to using a UUID and generate new ones using `UUID.randomUUID()` which uses `new SecureRandom()` under the hood.
What is the status of this? Has this vulnerability been addressed? Do we need to report this as CVE? https://www.eclipse.org/projects/handbook/#vulnerability-cve
As explained, I think this is not an issue as this is unsecured generator is not used for critical used. So FMPOV there is nothing to do. Should I close this ?
(In reply to Simon Bernard from comment #7) > As explained, I think this is not an issue as this is unsecured generator is > not used for critical used. > > So FMPOV there is nothing to do. > Should I close this ? If it is your opinion that there is no issue and nothing to do, then yes (I'll do it while I'm here).
