June 2024 brought an important security update for MIT Kerberos 5 (krb5), fixing a subtle but serious flaw tracked as CVE-2024-37370. In this article, we’ll break down what this vulnerability means, walk through a simple code demo, and explain how attackers could exploit this bug to disrupt or manipulate secured communications.

What is MIT Kerberos 5 and GSS krb5 Wrap Tokens?

Kerberos is a widely used authentication protocol, especially in enterprise networks and UNIX systems. The MIT implementation of Kerberos 5, known as krb5, is the reference standard.

One of the ways applications use Kerberos for secure messaging is through the GSS-API (Generic Security Service Application Program Interface). This API can both *wrap* (encrypt) and *unwrap* (decrypt) data using so-called "tokens." These tokens can optionally provide confidentiality (encryption), meaning only the intended recipient can see the message contents.

What’s the Problem? Understanding CVE-2024-37370

The CVE-2024-37370 bug is about the "Extra Count" field in a "wrap token" with confidentiality. The wrap token has a field that’s not protected by a cryptographic integrity check, but IS sent in plaintext alongside the encrypted data.

If an attacker is able to intercept and alter this token in transit, they could tamper with this Extra Count field. When the recipient application “unwraps” (decodes) the token, it may believe the message is shorter than it really is, effectively causing the data to appear truncated. This can confuse the application, make it discard data prematurely, or even open the way for more creative attacks depending on the nature of the application.

In short: An attacker could strip trailing bytes off a message *after* it’s been encrypted – simply by messing with this unprotected field. The application never realizes the message was tampered with!

To exploit this bug

1. The attacker must be able to intercept and modify GSS-API traffic between two Kerberos-authenticated parties (client/server).

The attacker finds a confidential wrap token in transit.

3. The attacker changes the Extra Count field in the token, setting it to a value smaller than the actual data length.
4. The recipient “unwraps” the token as usual, but now believes there is less data than was really sent – discarding the leftover.

Potential Harm

- Message tampering: Dropping or hiding part of a message (which might change what the application does next).

Disruption: Applications could act on incomplete data, causing confusion or failure.

- Bypassing logic: If an application’s logic or protocol is sensitive to exact message size, security checks could be evaded.

Exploit Demo: How It Works

Let’s look at a simplified *proof-of-concept* in Python. This doesn’t use real Kerberos tokens, but shows the idea in code.

Suppose we have a function that processes an encrypted message—including this "count" field

def process_wrap_token(token_bytes):
    # Token structure: [EXTRA_COUNT][ENCRYPTED_DATA]
    # For simplicity, EXTRA_COUNT is 1 byte indicating length of the "valid" data
    extra_count = token_bytes[]
    encrypted_data = token_bytes[1:]
    # Here the application "unwraps" the token (decrypts data).
    decrypted_data = fake_decrypt(encrypted_data)
    # Returns only the number of bytes specified by EXTRA_COUNT
    return decrypted_data[:extra_count]

def fake_decrypt(bytes_in):
    # Pretend decryption, just reverses bytes for demo
    return bytes_in[::-1]

# Example usage by the application
# Let's say server sends (EXTRA_COUNT=8, encrypted_data) for "password"
application_sent = bytes([8]) + b'drowssap'  # 'password' reversed

print("Original message received:", process_wrap_token(application_sent))
# OUTPUT: b'password'

An attacker on the network modifies the token before it hits the recipient

# Change the extra_count to 4
tampered_token = bytes([4]) + b'drowssap'
print("Tampered message received:", process_wrap_token(tampered_token))
# OUTPUT: b'pass'

Result: The application now sees only "pass", the rest has been chopped off—without ever detecting tampering.

Real-World Consequences

While the above is simplified, the *actual* GSS krb5 code has a similar logic flaw. A real attacker would:

Trick the application into processing incomplete, possibly invalid or dangerous, data.

The MIT krb5 maintainers fixed this in version 1.21.3 by verifying the Extra Count field *after* decrypting the protected data, ensuring any tampering is detected.

How To Stay Safe

Are you vulnerable?
- If your system uses MIT krb5 older than 1.21.3, and relies on GSS-API with message confidentiality (wrap tokens), you are affected.

What to do:

More Information & References

- MIT Kerberos Security Advisory 2024-001
- Upstream Patch
- CVE-2024-37370 on NVD

Final Words

While this bug may sound like a low-level technicality, it’s a good reminder: Security isn’t just about strong encryption, it’s about protecting every field and assumption in a protocol. Even a single unprotected byte can open the door to clever, dangerous attacks.

Patch early, investigate your deployments, and always keep an eye on advisories for widely-used core libraries.

Timeline

Published on: 06/28/2024 22:15:02 UTC
Last modified on: 08/27/2024 17:48:12 UTC