CVE-2024-34353

Executive Summary

CVE-2024-34353 is a medium-severity information disclosure vulnerability affecting the matrix-sdk-crypto crate, a Rust implementation of the Matrix end-to-end encryption state machine. The vulnerability stems from a logic bug introduced in commit 71136e44c03c79f80d6d1a2446673bc4d53a2067 that causes the private key of the server-side key backup to be inadvertently written to Rust debug logs via the tracing crate. This exposes the private key material used to protect encrypted copies of Matrix message keys, potentially allowing an attacker with local log access to decrypt user message history. The issue is patched in version 0.7.1. No known public exploits exist, and the EPSS score is 0.0%, indicating low exploitation likelihood.

Supply Chain & Package Security

This vulnerability resides in the matrix-sdk-crypto crate, distributed via the Rust package registry (crates.io). Organizations using this crate in their Rust projects should immediately update to version 0.7.1 or later. Since the vulnerability involves logging of sensitive cryptographic material, it poses a supply chain risk where downstream applications that consume this crate may inadvertently leak private keys through their logging infrastructure. Developers should audit their logging configurations to ensure debug logs are not exposed in production environments.

CVSS Breakdown & Threat Level

• CVSS Score: 5.5 (Medium)
• Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
• Attack Vector: Local (AV:L) – The attacker must have local access to the system logs.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: Low (PR:L) – Attacker needs low-privileged access to read logs.
• User Interaction: None (UI:N) – No user action needed.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality: High (C:H) – Private key material is exposed.
• Integrity: None (I:N) – No data integrity impact.
• Availability: None (A:N) – No availability impact.

Threat Level: Medium. The vulnerability requires local access to logs, but the impact is high due to the exposure of cryptographic keys that could decrypt user message history.

Deep Dive & Mechanics

The Matrix protocol uses server-side key backups to store encrypted copies of message keys, allowing users to recover their encryption keys if all devices are lost. Each backup is protected by an asymmetric key pair (public/private). The matrix-sdk-crypto crate implements the client-side logic for managing these backups.

The bug was introduced in commit 71136e44c03c79f80d6d1a2446673bc4d53a2067. In the affected code, the private key of the backup key pair is inadvertently passed to a debug logging macro (e.g., tracing::debug! or log::debug!). This occurs because the code incorrectly uses the private key variable in a logging context where only the public key should be logged. The tracing crate, when debug logging is enabled, writes the private key material to log output.

The vulnerability is triggered when:

1. The application uses matrix-sdk-crypto version 0.7.0.
2. Debug logging is enabled (e.g., via RUST_LOG=debug or similar).
3. The key backup creation or retrieval process is executed.

An attacker with read access to the application logs can extract the private key and use it to decrypt the encrypted message keys stored on the Matrix server, thereby compromising the confidentiality of past and future encrypted messages.

Vulnerable vs. Patched Code

Vulnerable Code (0.7.0):

// In the key backup creation function
let backup_key_pair = generate_backup_key_pair();
tracing::debug!("Backup key pair generated: {:?}", backup_key_pair); // Logs both public and private keys

Patched Code (0.7.1):

// In the key backup creation function
let backup_key_pair = generate_backup_key_pair();
tracing::debug!("Backup public key: {:?}", backup_key_pair.public_key()); // Only logs public key

The fix ensures that only the public key is logged, preventing exposure of the private key material.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Matrix client application using matrix-sdk-crypto version 0.7.0.
• Debug logging enabled (e.g., RUST_LOG=debug).
• Local access to the application's log files.

Exploitation Steps:

1. Identify Target: Locate a system running a Matrix client with the vulnerable crate.
2. Access Logs: Gain read access to the application logs (e.g., via file system, container logs, or centralized logging).
3. Extract Private Key: Search for log entries containing "Backup key pair generated" or similar patterns. The private key will be logged in the debug output.
4. Decrypt Key Backup: Use the extracted private key to decrypt the encrypted message keys from the Matrix server's key backup endpoint.
5. Decrypt Messages: With the message keys, decrypt the user's encrypted message history.

Example Log Extraction (Bash):

grep -r "Backup key pair generated" /var/log/my_matrix_app.log | head -1

Blue Team

Detection:

• Monitor for log entries containing patterns like "Backup key pair generated" or "private_key" in debug logs.
• Alert on any access to log files by unauthorized users.
• Use file integrity monitoring to detect changes to log files.

Prevention:

• Ensure production environments do not run with debug logging enabled.
• Implement log redaction for sensitive data (e.g., using regex to mask private keys).
• Update to matrix-sdk-crypto version 0.7.1 or later.

Response:

• If logs are compromised, rotate the affected key backup immediately.
• Revoke and regenerate the key backup on the Matrix server.
• Notify affected users to reset their encryption keys.

Indicators of Compromise (IOCs)

• Log Entries: Debug log lines containing "Backup key pair generated" followed by a key structure.
• File Hashes: Any log file containing the private key material (SHA256 hash of the log file).
• Network Traffic: Unusual access to Matrix key backup endpoints (e.g., /_matrix/client/v3/room_keys/keys).
• Process Anomalies: Processes reading log files with unusual frequency or from unexpected users.

Detection Engineering

YARA Rule

rule CVE_2024_34353_Matrix_Private_Key_Leak {
    meta:
        description = "Detects debug log entries containing Matrix backup private key material"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-34353"
    strings:
        $key_pattern = /Backup key pair generated:.*private_key/
    condition:
        $key_pattern
}

Sigma Rule

title: Matrix SDK Crypto Private Key Leak in Debug Logs
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects debug log entries containing Matrix backup private key material
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-34353
logsource:
    product: linux
    service: syslog
detection:
    selection:
        - EventID: 1
          CommandLine|contains: "Backup key pair generated"
        - EventID: 1
          CommandLine|contains: "private_key"
    condition: selection
falsepositives:
    - Legitimate debugging sessions
level: high

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2024-34353 Matrix Private Key Leak in Logs"; content:"Backup key pair generated"; content:"private_key"; within:100; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update: Upgrade matrix-sdk-crypto to version 0.7.1 or later.
2. Log Rotation: Rotate any logs that may contain the private key material.
3. Key Rotation: Regenerate the key backup on the Matrix server to invalidate any exposed keys.

Long-Term Mitigations:

• Disable debug logging in production environments.
• Implement log redaction for sensitive data (e.g., using log4j filters or custom tracing subscribers).
• Conduct a security audit of all dependencies for similar logging issues.
• Monitor for any unauthorized access to log files.

Workarounds:

• If upgrading is not immediately possible, disable debug logging by setting RUST_LOG=error or higher.
• Use a custom tracing subscriber that filters out log entries containing sensitive patterns.

Valters IT