CVE-2022-2971 - Crashing MZ Automation’s libIEC61850 Servers with a Malicious Payload

If you’re working with industrial control systems (ICS) or the power grid, you’ve probably heard of libIEC61850, a popular library by MZ Automation for IEC 61850 protocol. In mid-2022, security researchers uncovered a nasty vulnerability (CVE-2022-2971) that can let an attacker crash any server running libIEC61850 version 1.4 and earlier, and even version 1.5 before a certain patch.

Let’s take a deep dive into what this bug is, how attackers might use it, and what you should do about it.

What Is CVE-2022-2971?

CVE-2022-2971 is a type confusion vulnerability in the code of libIEC61850. Basically, the library grabs a resource, assumes it’s of type A, but it’s actually of type B. In C, this is a big deal—if you treat memory like it’s one thing but it’s really something else, bad things happen: you might read or write where you shouldn’t.

For libIEC61850, that means someone could craft a special (malicious) network packet, send it to your server, and the server will crash—causing downtime for your critical infrastructure.

Where’s the Bug?

The root of the problem is in the server code that handles incoming messages (Resource Access Functions), specifically in the type checking and casting logic. Before commit a3b04b7, the server would cast pointers without verifying their actual type.

Code Snippet (Vulnerable)

// Simplified pseudocode from libIEC61850 server code (before patch)
void* resource = getResource(resourceId);
DataSet* ds = (DataSet*) resource; // <-- assumes resource is always DataSet

if (ds->memberCount > ) { // If resource is the wrong type, crash!
    // ...process dataset...
}

If getResource(resourceId) returns something that's *not* a DataSet, the cast leads to undefined behavior.

Exploit Scenario: How Could This Be Attacked?

In a real attack, a hacker sends a malformed request—one that targets a resource but tricks the server into treating it as the wrong kind. Imagine sending a generic resource but claiming it's a DataSet. The server tries to process it, but since it's really another object in memory, the worst-case is a crash (segmentation fault).

Simple Exploit Theory

1. Find a Resource: The attacker finds a resource accessible on the network (like an MMS or IEC 61850 object).
2. Send Malicious Payload: The attacker crafts a protocol message referencing that resource but claims it’s a DataSet.

Example Malicious Request

While the actual binary payload will be protocol-specific, the goal is always to force the server to use a resource the "wrong way". One might use an MMS GetDataSetDirectory request for an object that's *not* a DataSet.

Proof-of-Concept Exploit (for Learning, Not Malice!)

Note: Only use this in a lab environment. Never attack systems you don’t own!

import socket

# Connect to IEC 61850 server
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('target-server', 102)) # default port for MMS/IEC 61850

# Craft a payload targeting a non-DataSet as if it were a DataSet
malicious_payload = b'\x30\x33\x80\x01...'

s.sendall(malicious_payload)
resp = s.recv(1024)
print('Server response:', resp)

# If vulnerable, the server may crash or drop the connection
s.close()

*Replace malicious_payload with an actual encoded MMS message that triggers the bug.*

What Patch Fixed It?

The issue was fixed in commit a3b04b7 (May 2022), where more careful type-checking was added before accessing the resource.

Fixed Code (Concept)

void* resource = getResource(resourceId);
if (isDataSet(resource)) { // New check!
    DataSet* ds = (DataSet*) resource;
    if (ds->memberCount > ) { ... }
}
else {
    // ignore or gracefully handle
}

Operate devices directly accessible from the network.

An attacker could crash your ICS server, causing loss of visibility or control.

How To Fix

1. Update to latest libIEC61850: Download here

References

- CVE-2022-2971 on NVD
- MZ Automation’s GitHub
- Patch commit a3b04b7
- libIEC61850 official site

Stay safe! Patch your libraries and keep industrial systems locked down.

*Written by [Your Name], 2024. Share responsibly. For educational use only—do not exploit real systems!*

Timeline

Published on: 09/23/2022 16:15:00 UTC
Last modified on: 09/26/2022 22:42:00 UTC