Incorrect AuthorizationAffected versions of this package are vulnerable to Incorrect Authorization in org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals through external MLS commit Remove proposal validation. An attacker can evict an arbitrary group member and take over that slot in the ratchet tree by supplying an external commit that names that member’s LeafIndex while holding only the group’s public GroupInfo. The vulnerable validation counted Remove proposals and bounded the removed leaf index, but it did not verify that the removed leaf was the joiner’s own prior leaf. As a result, any external joiner could submit a Remove for another participant and have other members apply it, forcing that member out of the group and disrupting the user’s session state.
How to fix Incorrect Authorization? Upgrade org.bouncycastle:bcmls-jdk18on to version 1.86 or higher.
| |
Signed to Unsigned Conversion ErrorAffected versions of this package are vulnerable to Signed to Unsigned Conversion Error due to unsigned leaf_index values being compared as signed integers in GroupKeySet.SecretTree.hasLeaf and Group.validateRemove. An attacker can exhaust heap memory and crash the JVM by sending a small MLS message with a wire-encoded leaf_index whose top bit is set, causing the out-of-range sender to pass the membership check and drive NodeIndex.parent() into an unbounded cycle.
How to fix Signed to Unsigned Conversion Error? Upgrade org.bouncycastle:bcmls-jdk18on to version 1.86 or higher.
| |
Improper Certificate ValidationAffected versions of this package are vulnerable to Improper Certificate Validation in LeafNode.verify() in org.bouncycastle.mls.codec, which never checks that the subject public key of the X.509 credential's end entity certificate matches the leaf's signature_key field, although RFC 9420 section 5.3 requires the two to represent the same identity. An attacker can be admitted to an MLS group under a victim's X.509 identity and decrypt the group messages that follow, by presenting the victim's certificate as their credential while signing the leaf with an unrelated key they control. This affects applications using the MLS implementation, with no second check available, since both KeyPackage.verify() and the Group leaf validation path authenticate through that same method, and validating the certificate chain to a trust anchor is a separate concern that the application handles and that does not establish this binding.
How to fix Improper Certificate Validation? Upgrade org.bouncycastle:bcmls-jdk18on to version 1.86 or higher.
| |
Memory Allocation with Excessive Size ValueAffected 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-jdk18on to version 1.85 or higher.
| |
Excessive IterationAffected 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-jdk18on to version 1.85 or higher.
| |
