Libmodbus is a popular C library for communicating with Modbus devices over serial lines or TCP/IP networks. Thanks to its open source nature and widespread use in industrial and embedded systems, vulnerabilities in this library can have serious consequences. In May 2024, a new critical vulnerability was discovered: CVE-2024-36844. This bug could let an attacker remotely crash your software and potentially take more dangerous actions.

Let’s break down CVE-2024-36844 in simple terms, explore what makes it dangerous, show how the exploit works (with code!), and point to original sources for further reading.

What is CVE-2024-36844?

CVE-2024-36844 is a use-after-free vulnerability in libmodbus v3.1.6. Specifically, the problem is with the internal pointer ctx->backend. Under certain crafted network messages, if your application is using libmodbus’s unit-test-server, an attacker can trigger this bug to crash your program—leading to a Denial of Service (DoS).

Technical summary

- Vulnerable library: libmodbus v3.1.6

Why Does This Happen?

In programming, a use-after-free bug happens when the program frees memory (makes it available for reuse) but then tries to use that same memory. If the memory is re-purposed or modified after it was freed, very bad things can happen: crashes, data leaks, or even code execution.

In CVE-2024-36844, if a crafted Modbus request is sent to the server, the server handler might free the backend context too early—and then continue to access it. This results in unstable behavior.

Let's look at a simplified code example (not the actual library code, but a similar logic)

// Pseudocode for demonstration

modbus_t *ctx = modbus_new_tcp("127...1", 1502);
modbus_mapping_t *mb_mapping = modbus_mapping_new(...);

// Server loop, simplified
while (1) {
    int rc = modbus_receive(ctx, query);
    if (rc > ) {
        modbus_reply(ctx, query, rc, mb_mapping);
    }
}

// Somewhere, ctx->backend is freed before it's safe...
// Later code tries to use ctx->backend, causing use-after-free.

In modbus_reply(), if a certain crafted message is received, the library's internal logic could free the backend pointer but the code will continue to use it. This leads to a crash or undefined behavior.

How Can This Be Exploited?

By sending a specific malicious message to your unit-test-server, an attacker can remotely crash your application. The only requirement: your application must have a unit-test-server running and be exposed to the network.

Scan for open Modbus TCP servers (default port 502, or unit-test-server on other ports).

2. Send a crafted Modbus packet that triggers the use-after-free (details are in the references below).

Sample Exploit (Proof-of-Concept)

Below is a basic Python exploit example. This code will connect to your Modbus TCP server and send a crafted message:

import socket

# Change to your unit-test-server's IP and port
SERVER = '127...1'
PORT = 1502  # default for unit-test-server

# Crafted Modbus TCP packet (example, not the real exploit)
# Replace 'data' with the exact payload needed to trigger the bug
data = b'\x00\x01\x00\x00\x00\x06\x01\x03\x00\x00\x00\x01'  # function 3, read registers

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect((SERVER, PORT))
    s.sendall(data)
    print("Payload sent.")

Note: For the real-world attack, you need to craft the message according to the vulnerability specifics as described in the upstream advisory and CVE record.

Fixes and Recommendations

- Upgrade to the latest release of libmodbus as soon as possible. The maintainers have issued a patch that properly manages memory and prevents this use-after-free.

References

- libmodbus v3.1.6 on GitHub
- Security Patch Commit
- CVE-2024-36844 at cve.org
- Original PR Discussing the Fix

Final Thoughts

CVE-2024-36844 shows how a simple programming mistake can have network-wide consequences. If you’re using libmodbus in any way—especially for testing or as a gateway in an industrial network—patch your systems right away.

Feel free to share this post with your team, and always keep your dependencies up to date!


*This exclusive post is written for educational and awareness purposes. Don't use these techniques to attack others’ systems without permission.*

Timeline

Published on: 05/31/2024 20:15:10 UTC
Last modified on: 08/19/2024 16:35:19 UTC