CVE-2024-45192

Executive Summary

CVE-2024-45192 identifies a cache-timing side-channel vulnerability in Matrix libolm through version 3.2.16. The flaw arises from the use of a non-constant-time base64 decoding function when processing group session keys. An attacker with the ability to observe execution timing (e.g., via a shared physical or virtualized environment) can recover secret key material. This vulnerability only affects the unmaintained libolm library; the maintainer has declared it end-of-life, and no patch will be released. Users must migrate to the successor library, vodozemac.

Supply Chain & Package Security

This vulnerability affects the libolm library, which is distributed as a C/C++ source package and is a dependency for many Matrix client implementations. Since the library is end-of-life, no updated packages will be published to package registries (e.g., PyPI, npm, or system package managers). Any software still depending on libolm is at risk. Supply chain security teams should audit all dependencies for libolm usage and plan migration to vodozemac.

CVSS Breakdown & Threat Level

The NVD has not assigned a CVSS score or vector for this CVE. Based on the nature of the vulnerability (cache-timing side-channel), a reasonable assessment would be:

• Attack Vector (AV): Local (L) – requires ability to observe timing on the same hardware.
• Attack Complexity (AC): High (H) – requires precise timing measurements and multiple observations.
• Privileges Required (PR): None (N) – attacker does not need prior access.
• User Interaction (UI): None (N) – no user action required beyond normal key exchange.
• Scope (S): Unchanged (U) – exploitation does not affect other components.
• Confidentiality (C): High (H) – secret key material can be recovered.
• Integrity (I): None (N) – no data modification.
• Availability (A): None (N) – no denial of service.

Estimated CVSS:3.1 Vector: AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Estimated Base Score: 5.1 (Medium)

Threat Level: Medium. Exploitation requires local access or co-tenancy on shared hardware, making remote exploitation unlikely. However, in cloud or multi-tenant environments, the risk increases.

Deep Dive & Mechanics

The vulnerability resides in the base64 decoding routine used to parse group session keys in libolm. The decoding function performs conditional branches based on the input data, leading to measurable differences in execution time. An attacker who can observe the time taken to decode a key can infer the secret bytes.

Technical Details:

• The affected function is olm::decode_base64 (or similar) in src/base64.cpp.
• The decoding loop uses a lookup table and conditional checks that are not constant-time.
• By sending crafted group session keys and measuring response times, an attacker can recover the key byte-by-byte.
• The attack requires multiple timing measurements (typically thousands) to statistically filter noise.

Root Cause: The use of non-constant-time base64 decoding violates the principle of constant-time cryptography, which is essential for preventing side-channel attacks.

Vulnerable vs. Patched Code

Since no patch exists, the comparison is between the vulnerable libolm implementation and the recommended successor, vodozemac.

Vulnerable Code (libolm):

// Simplified example of non-constant-time base64 decode
std::uint8_t decode_base64_char(char c) {
    if (c >= 'A' && c <= 'Z') return c - 'A';
    if (c >= 'a' && c <= 'z') return c - 'a' + 26;
    if (c >= '0' && c <= '9') return c - '0' + 52;
    if (c == '+') return 62;
    if (c == '/') return 63;
    return 0xFF; // error
}

Patched Approach (vodozemac):

// Constant-time base64 decode using lookup table and bit masking
fn decode_base64_char(c: u8) -> u8 {
    // Use a precomputed lookup table with 256 entries
    // All entries are accessed regardless of input
    BASE64_DECODE_TABLE[c as usize]
}

The key difference is that vodozemac uses a lookup table accessed with a constant index, avoiding conditional branches.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Local access to the target system (e.g., via SSH, co-located VM, or container).
• Ability to send crafted group session keys to a Matrix client using libolm.
• High-resolution timer (e.g., clock_gettime with CLOCK_MONOTONIC).

Exploitation Steps:

1. Setup: Deploy a Matrix client using libolm (e.g., an older version of Element).
2. Timing Measurement: For each byte position in the key, send multiple decoding requests with varying candidate bytes.
3. Statistical Analysis: Use a tool like scipy to perform a t-test on timing distributions to identify the correct byte.
4. Key Recovery: Repeat for all bytes until the full group session key is recovered.

Example Python Snippet:

import socket
import time
import numpy as np

def measure_decode_time(key_bytes):
    # Send key to target and measure response time
    start = time.perf_counter()
    # ... send key via Matrix protocol ...
    end = time.perf_counter()
    return end - start

# For each byte position
for pos in range(32):  # 32-byte key
    timings = {}
    for candidate in range(256):
        key = b'\x00' * pos + bytes([candidate]) + b'\x00' * (31 - pos)
        times = [measure_decode_time(key) for _ in range(1000)]
        timings[candidate] = np.mean(times)
    # The candidate with the highest mean timing is likely correct
    correct_byte = max(timings, key=timings.get)

Blue Team

Detection:

• Monitor for unusual patterns of key exchange requests from a single source.
• Look for high-frequency, low-variance timing patterns in network traffic.
• Use performance monitoring tools to detect anomalous CPU cache behavior.

Mitigation:

• Immediately migrate from libolm to vodozemac.
• If migration is not possible, isolate Matrix clients on dedicated hardware to prevent cross-tenant timing attacks.
• Implement noise injection in the decoding path (temporary workaround).

Indicators of Compromise (IOCs)

• Network: Repeated key exchange requests with varying payloads from the same IP.
• Host: High-frequency calls to decode_base64 function (detectable via perf or eBPF).
• Logs: Unusual error messages from libolm related to key decoding failures.
• File: Presence of libolm library version <= 3.2.16 in the software stack.

Detection Engineering

YARA Rule

rule CVE_2024_45192_libolm_timing_vuln {
    meta:
        description = "Detects libolm binary with vulnerable base64 decode"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-45192"
    strings:
        $decode_func = "decode_base64" ascii wide nocase
        $libolm_str = "libolm" ascii wide nocase
    condition:
        $decode_func and $libolm_str
}

Sigma Rule

title: Potential Cache-Timing Attack on libolm
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects high-frequency key exchange requests indicative of timing attack
logsource:
    category: network_connection
    product: matrix
detection:
    selection:
        EventID: 5156  # Windows Filtering Platform connection
        DestinationPort: 443
        Protocol: TCP
    condition: selection | count() by SourceIp > 100 in 60 seconds
falsepositives:
    - Legitimate high-traffic Matrix clients
level: medium

Suricata Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 443 (msg:"CVE-2024-45192 Potential libolm Timing Attack"; flow:to_server; content:"|01|"; depth:1; threshold: type both, track by_src, count 100, seconds 60; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Migrate to vodozemac: Replace libolm with the actively maintained successor library.
2. Isolate Workloads: Run Matrix clients using libolm on dedicated hardware to prevent cross-tenant timing attacks.
3. Monitor: Deploy the detection rules above to identify potential exploitation attempts.

Long-Term Fix:

• No patch will be released for libolm. The only permanent fix is to stop using libolm entirely.

Workaround (Temporary):

• Add artificial noise to the decoding function by introducing random delays. This reduces the signal-to-noise ratio for attackers but does not eliminate the vulnerability.

Valters IT Signature: This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters.it.