org.bouncycastle:bcmls-debug-jdk18on@1.83

  • latest version

    1.85

  • latest non vulnerable version

  • first published

    1 years ago

  • latest version published

    26 days ago

  • licenses detected

  • package registry

  • Direct Vulnerabilities

    Known vulnerabilities in the org.bouncycastle:bcmls-debug-jdk18on package. This does not include vulnerabilities belonging to this package’s dependencies.

    Fix vulnerabilities automatically

    Snyk's AI Trust Platform automatically finds the best upgrade path and integrates with your development workflows. Secure your code at zero cost.

    Fix for free
    VulnerabilityVulnerable Version
    • H
    Memory Allocation with Excessive Size Value

    Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the readOpaque() method of MLSInputStream, which decodes a varint length up to 0x3FFFFFFF (about 1 GiB) and calls readAll(size) performing new byte[size] before checking that enough bytes remain in the stream. An attacker can exhaust the JVM heap and crash the process by sending a ~6-byte MLS message whose first opaque length varint is 0xBFFFFFFF, forcing a ~1 GiB allocation per message. This requires only the ability to send raw MLS bytes to the application, since the allocation occurs before any signature or MAC verification.

    How to fix Memory Allocation with Excessive Size Value?

    Upgrade org.bouncycastle:bcmls-debug-jdk18on to version 1.85 or higher.

    [,1.85)
    • H
    Excessive Iteration

    Affected versions of this package are vulnerable to Excessive Iteration in the HashRatchet.get(int generation) method of GroupKeySet, reached through PrivateMessage.unprotect(), which loops while (nextGeneration < generation) next(); and caches every intermediate KeyGeneration in an unbounded HashMap. A user who is an authenticated group member can force every other member to run roughly 2 billion HKDF iterations and allocate multiple gigabytes of cache memory by sending an MLS PrivateMessage whose sender generation field is set to 0x7FFFFFFF. The generation value is processed after only a hasLeaf() check and before any per-message signature verification, and it is carried in sender data encrypted under shared group secrets, so exploitation requires valid membership in the group.

    How to fix Excessive Iteration?

    Upgrade org.bouncycastle:bcmls-debug-jdk18on to version 1.85 or higher.

    [,1.85)