CVE-2024-45191

Executive Summary

CVE-2024-45191 identifies a cache-timing side-channel vulnerability in the Matrix libolm library (versions up to and including 3.2.16). The flaw resides in the AES implementation, which uses lookup tables (S-boxes) for the SubWord step, making it susceptible to cache-timing attacks. An attacker with the ability to observe cache access patterns (e.g., via a co-located process or precise timing measurements) could potentially recover secret cryptographic keys. The maintainer has declared the product end-of-life, meaning no official patch will be released. This vulnerability is classified as a local side-channel attack with a CVSS score of 0.0 due to the lack of a CVSS vector in the NVD data, but the underlying weakness is significant for systems relying on this library for encryption.

Supply Chain & Package Security

This vulnerability affects the libolm library, which is a core component of the Matrix communication protocol. It is distributed as a C library and is often compiled from source or included as a dependency in various Matrix client and server implementations. Since the library is end-of-life, no package updates will be issued. Organizations using libolm must migrate to a maintained fork or alternative implementation (e.g., vodozemac) to ensure continued security.

CVSS Breakdown & Threat Level

The NVD has assigned a CVSS score of 0.0, indicating that no CVSS vector was provided. However, based on the vulnerability description, a reasonable assessment would be:

• Attack Vector (AV): Local (L) – requires co-located access or precise timing measurements.
• Attack Complexity (AC): High (H) – requires detailed knowledge of cache behavior and multiple measurements.
• Privileges Required (PR): None (N) – attacker does not need prior privileges.
• User Interaction (UI): None (N) – no user action required.
• Scope (S): Unchanged (U) – vulnerability does not affect other components.
• Confidentiality (C): High (H) – secret keys could be recovered.
• Integrity (I): None (N) – no data modification.
• Availability (A): None (N) – no denial of service.

Threat Level: Medium. While the attack is local and complex, the potential to recover encryption keys makes it critical for high-security environments.

Deep Dive & Mechanics

The vulnerability lies in the AES implementation within libolm. AES uses a SubBytes step that substitutes each byte of the state using a fixed S-box. In many software implementations, this S-box is implemented as a lookup table (LUT) in memory. When the CPU accesses this table, the data is cached. An attacker who can observe cache timing (e.g., via Flush+Reload or Prime+Probe techniques) can infer which table entries were accessed, thereby leaking information about the secret key.

Specifically, the SubWord step in AES key expansion also uses the S-box. If the attacker can measure the time taken for encryption operations, they can correlate cache hits/misses with key bytes. This is a classic cache-timing side-channel attack.

The libolm library is used for Olm (Olm) and Megolm (Megolm) cryptographic ratchets in Matrix. An attacker who recovers the Olm session key could decrypt past and future messages in that session.

Vulnerable vs. Patched Code

Vulnerable Code (libolm <= 3.2.16): The AES implementation uses a direct lookup table for the S-box. For example, in aes.c:

static const uint8_t sbox[256] = {
    // ... S-box values ...
};

void aes_sub_bytes(uint8_t state[16]) {
    for (int i = 0; i < 16; i++) {
        state[i] = sbox[state[i]];
    }
}

This table access is not constant-time and leaks cache timing information.

Patched Code (Not available): A constant-time implementation would replace the lookup table with bit-sliced or bitsliced AES, or use hardware AES instructions (AES-NI) where available. For example:

// Constant-time SubBytes using bitslicing (simplified)
void aes_sub_bytes_ct(uint8_t state[16]) {
    // Implement SubBytes using logical operations only
    // No table lookups
}

Since no official patch exists, users must migrate to a different library.

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker needs:

• Co-location on the same physical machine as the victim (e.g., in a cloud environment).
• Ability to run code (e.g., a malicious process) that can perform cache-timing measurements.
• Multiple encryption operations to gather statistical data.

Lab Setup:

1. Set up two virtual machines on the same hypervisor (e.g., KVM).
2. On the victim VM, run a Matrix client using libolm (e.g., Element with an older version).
3. On the attacker VM, run a cache-timing tool (e.g., Flush+Reload) targeting the S-box memory addresses.
4. Perform many encryption operations on the victim (e.g., sending messages).
5. Analyze timing data to recover the AES key.

Example Attack Script (Conceptual):

import time
import ctypes

# Load libolm
lib = ctypes.CDLL("libolm.so.3")

# Flush+Reload attack
def flush_reload(address):
    # Flush cache line
    # ... (platform-specific)
    # Measure access time
    start = time.perf_counter_ns()
    # Access memory
    _ = ctypes.c_char.from_address(address)
    end = time.perf_counter_ns()
    return end - start

# Target S-box address
sbox_addr = ctypes.addressof(lib.sbox)

# Collect timing samples
timings = []
for _ in range(1000):
    # Trigger encryption
    lib.olm_encrypt(...)
    # Measure S-box access
    t = flush_reload(sbox_addr)
    timings.append(t)

# Analyze timings to infer key bytes

Blue Team

Detection:

• Monitor for unusual cache-timing patterns using performance counters (e.g., perf stat).
• Use eBPF to detect Flush+Reload or Prime+Probe attacks.
• Look for processes with high cache miss rates or frequent clflush instructions.

Mitigation:

• Migrate from libolm to a maintained alternative (e.g., vodozemac).
• If migration is not possible, isolate sensitive processes using containers or VMs with dedicated CPU cores.
• Disable simultaneous multithreading (SMT) to reduce side-channel risk.
• Use hardware AES instructions (AES-NI) if available, as they are constant-time.

Indicators of Compromise (IOCs)

• File Hashes:
  • libolm.so.3.2.16: SHA256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (example)
• Network Traffic:
  • Unusual timing patterns in Matrix message encryption/decryption.
• Process Behavior:
  • High frequency of clflush instructions.
  • Abnormal cache miss rates in the Matrix client process.
• Memory Access:
  • Repeated access to memory regions containing AES S-box tables.

Detection Engineering

YARA Rule

rule CVE_2024_45191_libolm_cache_timing {
    meta:
        description = "Detects libolm binary with vulnerable AES S-box lookup table"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-45191"
    strings:
        $sbox = { 63 7c 77 7b f2 6b 6f c5 30 01 67 2b fe d7 ab 76 } // AES S-box start
    condition:
        $sbox at 0 and filesize < 1MB
}

Sigma Rule

title: Cache-Timing Attack on libolm AES
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential cache-timing side-channel attacks against libolm
author: Valters IT
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith: '/matrix-client'
        CommandLine|contains: 'olm'
    condition: selection
falsepositives:
    - Legitimate Matrix client usage
level: medium

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-45191 Potential libolm Cache-Timing Exploit"; flow:to_server; content:"|01 02 03 04|"; depth:4; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Migrate from libolm to a maintained fork or alternative implementation such as vodozemac (Rust-based, constant-time).
2. Short-term Mitigation:
   • Isolate Matrix processes on dedicated CPU cores.
   • Disable SMT/hyper-threading on sensitive systems.
   • Use hardware AES instructions (AES-NI) if available.
3. Long-term Solution:
   • Replace all instances of libolm with a constant-time cryptographic library.
   • Implement runtime monitoring for cache-timing anomalies.
4. Detection:
   • Deploy YARA rules to scan for vulnerable libolm binaries.
   • Use eBPF-based tools to detect cache side-channel attacks.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert