CVE-2024-36403

Executive Summary

CVE-2024-36403 is a medium-severity vulnerability in Matrix Media Repo (MMR) versions prior to 1.3.5. The flaw allows an unauthenticated attacker to cause unbounded disk consumption by inducing the server to download and cache large amounts of remote media files. This can lead to a denial of service (DoS) for file-backed or self-hosted S3 storage instances, or unexpected high service fees for cloud-based S3 storage. The vulnerability is rated with a CVSS score of 5.3 (Medium) and is classified under CWE-400 (Uncontrolled Resource Consumption). The patch in version 1.3.5 introduces a leaky bucket rate limit, but proper configuration of the X-Forwarded-For header is required to avoid bypassing the rate limit.

Supply Chain & Package Security

This vulnerability affects the Matrix Media Repo (MMR) package, which is a Go-based application. The supply chain risk is moderate, as MMR is a critical component for Matrix homeservers handling media storage. The patch is available in version 1.3.5, and operators should verify the integrity of the update through official channels. No known malicious packages or compromised dependencies have been reported in relation to this CVE.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The impact is confined to the vulnerable component.
• Confidentiality (C): None (N) – No data exposure.
• Integrity (I): None (N) – No data modification.
• Availability (A): Low (L) – The attack can cause disk exhaustion, leading to denial of service.

Threat Level: Medium. The vulnerability is easy to exploit remotely without authentication, but the impact is limited to availability. The EPSS score of 0.0% suggests low exploitation activity in the wild, but the risk increases for instances with file-backed storage.

Deep Dive & Mechanics

Matrix Media Repo (MMR) is a highly configurable multi-homeserver media repository for the Matrix communication protocol. It handles the storage and retrieval of media files (images, videos, documents) uploaded by users. MMR can be configured to use either a file-backed store (local disk) or an S3-compatible object store (cloud or self-hosted).

The vulnerability lies in the media download and caching mechanism. When a user requests a remote media file (e.g., an image from another homeserver), MMR downloads and caches it locally. An unauthenticated attacker can exploit this by sending a large number of requests for large remote media files, causing MMR to download and cache them. This leads to unbounded disk consumption.

For file-backed stores, this fills the local disk, preventing authenticated users from uploading new media (denial of service). For self-hosted S3 storage, the disk fill attack similarly impacts the storage system. For cloud-based S3, the attack results in high service fees due to excessive data storage and transfer costs.

The root cause is the lack of rate limiting on media download requests. The patch in version 1.3.5 introduces a "leaky bucket" rate limit that limits the amount of data a user can request over time. However, this rate limit relies on the client's IP address. If the reverse proxy does not forward the original client IP via the X-Forwarded-For header, the rate limit is applied to the proxy's IP, effectively bypassing the protection.

Vulnerable vs. Patched Code

The vulnerable code is in the media download handler. Below is a simplified representation of the vulnerable logic and the patched version.

Vulnerable Code (Pre-1.3.5):

func (h *Handler) DownloadMedia(w http.ResponseWriter, r *http.Request) {
    // No rate limiting
    mediaURL := r.URL.Query().Get("url")
    if mediaURL == "" {
        http.Error(w, "Missing URL", http.StatusBadRequest)
        return
    }
    // Download and cache the media
    data, err := h.downloadAndCache(mediaURL)
    if err != nil {
        http.Error(w, "Download failed", http.StatusInternalServerError)
        return
    }
    w.Write(data)
}

Patched Code (1.3.5+):

func (h *Handler) DownloadMedia(w http.ResponseWriter, r *http.Request) {
    // Apply leaky bucket rate limit
    clientIP := getClientIP(r) // Uses X-Forwarded-For if available
    if !h.rateLimiter.Allow(clientIP) {
        http.Error(w, "Rate limit exceeded", http.StatusTooManyRequests)
        return
    }
    mediaURL := r.URL.Query().Get("url")
    if mediaURL == "" {
        http.Error(w, "Missing URL", http.StatusBadRequest)
        return
    }
    data, err := h.downloadAndCache(mediaURL)
    if err != nil {
        http.Error(w, "Download failed", http.StatusInternalServerError)
        return
    }
    w.Write(data)
}

func getClientIP(r *http.Request) string {
    if forwarded := r.Header.Get("X-Forwarded-For"); forwarded != "" {
        parts := strings.Split(forwarded, ",")
        return strings.TrimSpace(parts[0])
    }
    return r.RemoteAddr
}

The key difference is the addition of rate limiting and proper IP extraction from the X-Forwarded-For header.

Exploitation & Lab Setup

Red Team

Objective: Exploit CVE-2024-36403 to cause disk exhaustion on a vulnerable MMR instance.

Prerequisites:

• A vulnerable MMR instance (version < 1.3.5) with file-backed or self-hosted S3 storage.
• Network access to the MMR server.
• A list of large remote media URLs (e.g., from public Matrix servers).

Exploitation Steps:

1. Identify the MMR endpoint: The media download endpoint is typically /download or similar. Use a tool like curl or a custom script.
2. Send a large number of requests: Use a script to repeatedly request large media files. Example using curl in a loop:

   for i in {1..1000}; do
       curl -s "http://target-mmr:8000/download?url=https://example.com/large-file.jpg" &
   done
   

3. Monitor disk usage: Check the disk usage on the MMR server. For file-backed stores, the cache directory will grow rapidly.
4. Achieve denial of service: Once the disk is full, authenticated users will be unable to upload new media.

Advanced Exploitation:

• Use multiple IP addresses to bypass simple rate limits (if any).
• Automate with tools like wget or aria2c for parallel downloads.
• For cloud S3, the goal is to maximize storage costs rather than fill disk.

Blue Team

Objective: Detect and mitigate exploitation attempts.

Detection:

• Monitor disk usage on MMR servers. Sudden spikes in disk consumption indicate an attack.
• Monitor network traffic for a high volume of requests to the media download endpoint from a single or multiple IPs.
• Check logs for repeated requests to the same large media URLs.

Mitigation:

• Upgrade to MMR 1.3.5 or later.
• Ensure the reverse proxy (e.g., Nginx, Apache) is configured to forward the X-Forwarded-For header:

  location / {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://mmr-backend;
  }
  

• Implement additional rate limiting at the reverse proxy level:

  limit_req_zone $binary_remote_addr zone=mmr_download:10m rate=5r/s;
  location /download {
      limit_req zone=mmr_download burst=10 nodelay;
      proxy_pass http://mmr-backend;
  }
  

• Lower the maximum file size allowed in MMR configuration.
• Use a Web Application Firewall (WAF) to block suspicious patterns.

Indicators of Compromise (IOCs)

• Network IOCs:
  • High volume of HTTP GET requests to /download or similar endpoints.
  • Requests for unusually large media files (e.g., >100MB).
  • Multiple requests from the same IP in a short time window.
• System IOCs:
  • Rapid increase in disk usage on the MMR server.
  • Cache directory growing abnormally fast.
  • High CPU or memory usage due to concurrent downloads.
• Log IOCs:
  • Repeated log entries like Downloading media from URL: <url>.
  • Error logs indicating disk full or storage quota exceeded.

Detection Engineering

YARA Rule

rule CVE_2024_36403_MMR_Disk_Exhaustion {
    meta:
        description = "Detects exploitation attempts of CVE-2024-36403 by identifying high-volume download requests"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-36403"
    strings:
        $download_path = "/download" ascii wide nocase
        $media_url = "url=" ascii wide nocase
        $large_file = ".jpg" ascii wide nocase or ".png" ascii wide nocase or ".mp4" ascii wide nocase
    condition:
        #download_path > 100 and #media_url > 100 and #large_file > 50
}

Sigma Rule

title: CVE-2024-36403 - MMR Disk Exhaustion via Unauthenticated Media Downloads
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects a high volume of media download requests to MMR, indicating potential exploitation of CVE-2024-36403.
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: nginx
detection:
    selection:
        c-uri|contains: "/download"
        sc-status: 200
    timeframe: 5m
    condition: selection | count() > 100
falsepositives:
    - Legitimate high traffic from many users
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-36403 MMR Disk Exhaustion Attempt"; flow:to_server; content:"/download"; http_uri; content:"url="; http_uri; threshold: type both, track by_src, count 100, seconds 300; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade MMR: Update to version 1.3.5 or later. This is the primary fix.
2. Configure Reverse Proxy: Ensure the reverse proxy forwards the X-Forwarded-For header to MMR. Example for Nginx:

   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   

3. Apply Rate Limiting: Implement rate limiting at the reverse proxy level to limit requests per IP.
4. Monitor Disk Usage: Set up alerts for disk usage spikes on MMR servers.

Long-term Mitigations:

• Use cloud-based S3 storage with cost alerts to detect unusual spending.
• Implement a Web Application Firewall (WAF) to block automated download attempts.
• Regularly review and update MMR configurations, including maximum file size limits.
• Conduct periodic security audits of the MMR deployment.

Workarounds (if upgrade is not possible):

• Lower the maximum file size in MMR configuration.
• Implement harsh rate limits at the reverse proxy.
• Restrict access to the media download endpoint to authenticated users only (if feasible).

Valters IT