CycloneDDS: Integer Underflow in DDS_Security_Deserialize_ methods may lead to OOB read

Requesting a CVE for https://github.com/eclipse-cyclonedds/cyclonedds/security/advisories/GHSA-6jj6-w25p-jc42

assigned to @eboasson and @acorsaro

We're going to use CVE-2024-10838

added cvereserved label

I put together a CVE draft:

Title: Integer Underflow in DDS_Security_Deserialize_ methods may lead to OOB read

Description: An integer underflow during deserialization may allow any unauthenticated user to read out of bounds heap memory. This may result into secret data or pointers revealing the layout of the address space to be included into a deserialized data structure, which may potentially lead to thread crashes or cause denial of service conditions.

CWE: CWE-191: Integer Underflow (Wrap or Wraparound)

Vendor/Project: Eclipse Cyclone DDS

Product name: cyclonedds

Versions: ?

References:

• https://github.com/eclipse-cyclonedds/cyclonedds/security/advisories/GHSA-6jj6-w25p-jc42
• https://github.com/eclipse-cyclonedds/cyclonedds/releases/tag/0.10.5
• #46 (closed)

Credits: Robert Femmer

CVSS: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:L/SI:L/SA:L

@acorsaro @eboasson could you please take a look and review it before we move onto publishing? Also, some questions:

• What are the version bounds affected by this vulnerability?
• The CVSS from the advisory was in v3.1, we need to use v4.0. This has an additional SC/SI/SA which refers to Subsequent Systems Confidentiality/Integrity/Availability. I marked them as Low in the CVSS score above, is this correct?

Hi @ioanailiescu, 0.10.5 is the first fixed version, all earlier versions are affected.

I am afraid I have no experience with CVSS scoring. I get the impression that it makes the most sense to set SC, SI and SA to None for a library because it (usually) gets embedded in an application process without any further protection measures and so the vulnerability of the library automatically also applies to the application process. The subsequent system would then be any other parts of the system of which the application process would be part (and anything beyond).

Of course one could take additional protection measures to protect the application from vulnerabilities in the library, but that arguably results in "impact is constrained to the Vulnerable System." (e.g., table 9 of https://www.first.org/cvss/v4.0/specification-document)

Embedding the vulnerable library in an application should result in a CVSS for that application, I think. Perhaps the subsequent system vulnerability is meant to prevent the need for that, but then I would expect VA:H to result in SA:H.

Hi @eboasson , thank you for the answers, I changed the CVSS to reflect the above: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N. Will move onto publishing and let you know once it's done.

removed cvereserved label

added cvepublished label

CVE published, removing confidentiality.

made the issue visible to everyone

closed