The Shortest Path to Failure: Trivial Authentication Bypass in OpenMLS

Messaging Layer Security (MLS) is the designated successor to the Double Ratchet protocol (used by Signal, WhatsApp, etc.), designed to bring end-to-end encryption to large groups efficiently. It is complex, math-heavy, and relies entirely on strict cryptographic verification. openmls is a prominent Rust implementation of this standard.

The core of any such system is the ability to verify that a message actually came from who it says it did. This is done via Message Authentication Codes (MACs) or confirmation tags. When a message arrives, the system calculates what the tag should be and compares it to what was received.

Usually, we worry about timing attacks here—where an attacker measures how long the comparison takes to guess the secret key byte-by-byte. The openmls team knew this. They wrote a equal_ct (constant-time equality) function to prevent it. Unfortunately, in their pursuit of side-channel safety, they opened a massive logical door: they stopped checking if the provided tag was actually the right size.

The vulnerability lies in a fundamental behavior of Rust's iterator system, specifically the .zip() method. In many languages, if you try to zip two arrays of different lengths, you might get an error or an exception. In Rust, .zip() is designed to be safe and lazy: it creates an iterator that yields pairs of elements until either of the two underlying iterators is exhausted.

This behavior is documented, standard, and usually desirable—except when you are comparing cryptographic secrets. The vulnerable function, equal_ct, took two byte slices (a and b) and zipped them together to check for differences.

If the attacker controls a (the input tag) and the system controls b (the expected secret tag), the attacker can simply provide an empty slice []. The .zip() iterator sees that a is empty and immediately stops. The loop body never executes. The difference accumulator variable, initialized to 0, remains 0. The function returns true. It's the cryptographic equivalent of a bouncer stepping aside because you didn't hand him an ID card to check.

Let's look at the code that caused the issue. It's elegant, idiomatic Rust, and completely insecure.

The Vulnerable Code:

fn equal_ct(a: &[u8], b: &[u8]) -> bool {
    let mut diff = 0u8;
    // CRITICAL: .zip() stops at the shortest iterator
    for (l, r) in a.iter().zip(b.iter()) {
        diff |= l ^ r;
    }
    diff == 0
}

If a is empty, the loop runs 0 times. diff stays 0. 0 == 0 is true. Access granted.

The Fix:

The patch is painfully simple. Before doing the fancy constant-time loop, you must assert that the two things being compared are actually the same size. Since the length of a MAC is usually public knowledge (defined by the cipher suite), this check doesn't leak sensitive data.

fn equal_ct(a: &[u8], b: &[u8]) -> bool {
    // The Fix: Explicitly check lengths first
    if a.len() != b.len() {
        log::error!("Incompatible values");
        return false;
    }
 
    let mut diff = 0u8;
    for (l, r) in a.iter().zip(b.iter()) {
        diff |= l ^ r;
    }
    diff == 0
}

This addition ensures the loop always processes the full expected length of bytes, preventing the truncation attack.

Exploiting this does not require a supercomputer or advanced math. It requires a debugger and the audacity to send nothing.

Scenario: You are an attacker sitting on the network (MITM) or a malicious member of a group. You want to inject a fake Commit message into the MLS group, which normally requires a valid ConfirmationTag.

1. Craft the Payload: Create a valid MLS Commit message structure with your malicious content.
2. Neutering the Tag: When the protocol asks for the ConfirmationTag (usually 32 bytes of high-entropy randomness), you provide a 0-byte array (or just an empty vector).
3. Transmission: Send the packet to the victim client.
4. Verification: The victim's openmls client receives the message. It calculates what the tag should be (e.g., 0xDEADBEEF...).
5. The Bypass: It calls equal_ct(received_tag, expected_tag). Since received_tag is empty, the check passes instantly.
6. Success: The client accepts your malicious commit, potentially rotating keys or adding compromised members to the group.

Alternatively, you could brute-force the first byte. If you send a 1-byte tag, you have a 1 in 256 chance of matching the first byte of the real tag. But why gamble when sending nothing wins 100% of the time?

This is a catastrophe for a cryptographic library. The entire premise of MLS is that membership changes and message streams are cryptographically secured. By bypassing the equal_ct check, an attacker effectively disables authentication.

In a real-world scenario, this could allow:

• Message Forgery: Injecting messages that appear to come from trusted group members.
• Group Takeover: Forging Add or Remove proposals to kick out legitimate users or add attacker-controlled ghost users.
• Denial of Service: corrupting the group state such that legitimate members can no longer decrypt messages.

This vulnerability is a stark reminder that "memory safety" (which Rust provides) does not equal "logic safety". The memory was never corrupted; the logic was simply flawed.

The fix was released in openmls v0.7.2. If you are using an older version, your application is wide open.

Remediation Steps:

1. Open your Cargo.toml.
2. Check the openmls version.
3. Run cargo update -p openmls to pull the latest version.
4. Verify in Cargo.lock that you are on at least 0.7.2.

If you cannot upgrade immediately, you must implement a wrapper around calls to openmls that explicitly validates the length of incoming tags before passing them to the library, though this is risky and difficult to cover 100% of code paths.