Integer overflow in the GenericReader::ParseNumber() function of include/rapidjson/reader.h when parsing JSON text from a stream.

[shreyaaapatil]

The integer overflow issue appears to reported in https://nvd.nist.gov/vuln/detail/CVE-2024-39684

Any fix for this issue provided in the current version 1.1.0?

[apoorv56]

Hello all,
is there any plan to fix this issue in new release ?
I could see one more similer vulnerability (reference -> https://www.mend.io/vulnerability-database/CVE-2024-38517)

[Mike276849]

The integer overflow issue appears to reported in https://nvd.nist.gov/vuln/detail/CVE-2024-39684

Any fix for this issue provided in the current version 1.1.0?

Can you demonstrate this issue?

If rapidjson::Document is parsed from some file with a large number (via IStreamWrapper isw(ifs); Document d; d.ParseStream(isw); ), any integer value within the acceptable value range of uint64_t or int64_t, the parser will parse correctly and show the type with GetType() and IsInt64()/IsUInt64().

If an integer value exceeding these range limits is passed to the parser, the parser treats it as the type double and does some rounding if the integer value doesn't have a fully accurate double representation.

If the numeric value, be it integer or a decimal, exceeds the limits of double then the parser will report the error ParseErrorCode::kParseErrorNumberTooBig.

I don't see where is the integer overflow that CVE-2024-39684 has reported in GenericReader::ParseNumber.

[laurentcau]

Hello,

Based on the original Microsoft report, they use GitHub CNA to communicate CVE details to maintainers:
"The vulnerability assigned to this CVE is in RapidJSON library which is consumed by Microsoft Active Directory Rights Management Services Client. The CVE for this open source component, which is used in a Microsoft product, is assigned by GitHub CNA." (source:https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-39684)
If you are a maintainer you should have received something from them. Probably with a patch to apply.
(see https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories)

[sspivey98]

Hey, I would just like to clarify - I believe the original link from NIST is misguiding. This seems to be an issue with the Microsoft team who manages Microsoft Active Directory Rights Management Services Client program failing to upgrade rapidjson (probably past the 1.10 release). The github commit 8269bc2 and PR referenced in the writeup that fixed this issue is from 2018.

https://www.cybersecurity-help.cz/vulnerabilities/94061/
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38517

[laurentcau]

But the CVE is reported with:
"version: affected at <= 1.1.0"
(see https://www.cve.org/CVERecord?id=CVE-2024-38517)
You seem to say Microsoft did a mistake in the reported version.
I don't think man can easily change this version in a CVE report once it has been created.
So, the best solution I see, would be to publish a new minor version 1.1.1 of rapidjson.
(I'm not 100% sure for this solution because our check tools seems to use checksum to identify versions.)
(Actually our build process prevent us to launch new product with known CVE.)

[sspivey98]

I think that link proves my point, right? 1.1.0 was released 9 years ago, meaning that rapidjson versions that are older than 9 years old are vulnerable. In the page you linked - if you look references, the GitHub links are to the patches that fixed the vulnerability from 2018. Then Microsoft link that is in the references also states:

The vulnerability assigned to this CVE is in RapidJSON library which is consumed by Microsoft Active Directory Rights Management Services Client. The CVE for this open source component, which is used in a Microsoft product, is assigned by GitHub CNA.

I think it is safe to assume that the Microsoft team used an outdated version of rapidjson. If this was an issue for the current release, the finders of the CVE are required to contact the maintainers before releasing it as a CVE. I would close this issue as it doesn't pertain to actionable issue from this repo's perspective. But, only the maintainers would know all the relevant information.

Speaking of releases, my guess why this even happened is due to confusion how this repo does releases. Because its a header only library, they don't need to ship binaries for releases, so cloning the library suffices. However, they did a line of releases (where 1.1.0 is STILL the most current release), making one think that it is the most up-to-date, official release of rapidjson. I think it would better communicate to users to either remove the releases section, or push releases. But, this is just an opinion of a security researcher.