Gửi #865176: MZ Automation libiec61850 1.6.1 Memory Corruption (Out-of-bounds Read)

A heap-based out-of-bounds read vulnerability exists in the client-side processing path of libIEC61850 in the released version 1.6.1. The issue is reachable through a real MMS protocol workflow and can be reproduced with the official example client program. Specifically, the vulnerable path is exercised when the client retrieves a data set directory and processes a GetNamedVariableListAttributesResponse returned by the peer. If a malicious MMS server, or an adversary with man-in-the-middle capabilities on an untrusted connection, modifies a domain-specific itemId inside that response to an unexpectedly short value such as "$", the client later dereferences data beyond the end of a heap-allocated string object and crashes with an AddressSanitizer-reported heap-buffer-overflow read.

The vulnerability affects the client side rather than the server side. It is not dependent on direct invocation of an internal parser with a synthetic buffer outside the normal protocol state machine. The issue occurs during ordinary protocol handling after a successful connection has been established and the client performs normal object model browsing. The official examples can be used as the reproduction basis: the server side can be provided by server_example_basic_io, while the client side can be provided by iec61850_client_example2. A transparent proxy or a malicious server implementation is required only to inject the malformed response element, because the stock example server does not naturally emit such an invalid itemId on its own. This does not reduce the security relevance of the defect, because the bug is triggered by untrusted network input that flows through the library’s standard MMS client processing path.

The affected execution chain is straightforward. The example client enumerates logical devices and logical nodes and then requests data set directory information through IedConnection_getDataSetDirectory. That request is translated into an MMS Named Variable List directory operation. When the response is received, the client parses the GetNamedVariableListAttributesResponse and extracts each returned domain-specific variable access specification. The ASN.1 identifier for the member itemId is decoded into a newly allocated heap string and stored in a MmsVariableAccessSpecification object without enforcing the internal naming constraints later expected by the IEC 61850 object reference conversion code. The malformed itemId then propagates unchanged into MmsMapping_varAccessSpecToObjectReference, where the crash occurs.

The core flaw is a trust-boundary violation between protocol-level parsing and semantic conversion. The response parsing logic accepts the remote domain-specific itemId as a valid string and preserves it in heap-backed form, but the later conversion routine implicitly assumes that the string conforms to an internal IEC 61850 naming layout resembling LN$FC$DO... or a structurally equivalent pattern. Based on that assumption, the conversion code searches for the first '$' separator and then unconditionally reads fixed offsets relative to that position, treating separator + 1 and separator + 2 as the two functional constraint characters. No sufficient validation is performed to ensure that the separator exists in the expected position, that the suffix is long enough, or that the string contains the additional delimiter structure required by the conversion logic.

When the attacker-controlled itemId is the one-character string "$", the situation becomes unsafe immediately. After decoding, the string occupies a two-byte heap object containing the bytes 0x24 and 0x00. The conversion routine computes separator = strchr(itemId, '$'), which causes separator to point to the first byte of that same short string. It then proceeds under the assumption that valid characters follow the separator. Reading separator + 1 still lands on the terminating null byte, but reading separator + 2 steps exactly beyond the allocated object boundary. AddressSanitizer reports this as a heap-buffer-overflow read of size 1. The allocation trace shows that the accessed object originates from the ASN.1 identifier decoding path, which demonstrates that the out-of-bounds access targets a heap string derived from remote response data rather than a stale pointer, stack buffer, or already-freed allocation.

This root cause can be described more precisely as missing structural validation of an untrusted MMS Named Variable List member identifier before converting it into an IEC 61850 object reference. The parsing stage and the mapping stage do not enforce the same invariants. The parser is willing to accept a very short identifier, while the mapper treats the same identifier as though it were already guaranteed to contain the internal "$FC$" substructure. Because these assumptions are inconsistent, malformed but syntactically decodable network input can cross the trust boundary and reach fixed-offset dereferences that are only safe for well-formed identifiers. The defect therefore belongs to the class of client-side memory-safety issues caused by insufficient validation of attacker-controlled protocol fields before semantic reinterpretation.

The vulnerability can be reproduced in a stable and realistic manner. One working setup is to build the official server example in a normal debug configuration and the official example client with AddressSanitizer and UndefinedBehaviorSanitizer enabled. The server can be started on a local TCP port. A small transparent proxy is then placed between the client and the server. The proxy forwards all MMS/TCP traffic unchanged except for the first real GetNamedVariableListAttributesResponse, where it rewrites the first returned domain-specific itemId to the minimal malformed value "$". After the client connects through the proxy and reaches the data set directory retrieval step, the process aborts with an AddressSanitizer report. The observed stack trace shows the read occurring in MmsMapping_varAccessSpecToObjectReference, called from IedConnection_getDataSetDirectory, which in turn is reached from the main function of the official example client. The allocation backtrace points to the ASN.1 identifier decoding functions used while parsing the response, confirming the data flow from remote network input to the crashing dereference.

From a security perspective, the most defensible impact statement is remote client-side denial of service. An attacker who operates a malicious IEC 61850/MMS server, or who can tamper with traffic in transit where transport protection is absent or bypassed, can cause a libIEC61850-based client application to terminate during normal browsing of remote data set information. The current public evidence supports a reliable crash due to an out-of-bounds heap read. It does not yet prove a controlled write primitive or direct control-flow hijacking. For that reason, the issue should be classified conservatively as a remotely triggerable client-side memory corruption vulnerability leading to process abort and loss of availability, rather than overstated as proven remote code execution.

The issue is also relevant beyond the example program itself. Although the official iec61850_client_example2 application is a convenient proof-of-concept carrier, the vulnerable logic resides in the library code, not merely in the sample. Any application built on the affected client stack that invokes the same data set directory retrieval and object reference conversion path may be exposed if it processes attacker-controlled or tampered MMS responses. The example merely demonstrates that the bug is reachable through a supported, documented, real-world code path provided by the upstream project.

A proper fix should be implemented in the library, not only in the example. The conversion routine should reject malformed itemId strings before performing any fixed-offset dereference. At minimum, it should verify that the first separator exists, that at least two functional constraint characters follow it, that a second separator exists where expected, and that subsequent parsing operates only within the validated string bounds. Returning NULL or an explicit error indicator for malformed identifiers is preferable to attempting best-effort conversion. Defense in depth can also be added earlier in the response parsing path by validating domain-specific itemId values before storing them as accepted variable access specifications, but the critical remediation point is the conversion function that currently assumes trusted structure where none is guaranteed.

In summary, this is a genuine client-side vulnerability in libIEC61850 on the specified development-branch commit.

• Nguồn: ⚠️ https://github.com/mz-automation/libiec61850/issues/599
• Người dùng: SCU_1CP (UID 99172)
• Đệ trình: 22/06/2026 06:57 (cách đây 2 các tháng)
• Kiểm duyệt: 07/08/2026 15:56 (2 months later)
• Trạng thái: được chấp nhận
• Mục VulDB: 387009 [MZ Automation libiec61850 đến 1.6.1 MMS Protocol Workflow iec61850_common.c MmsMapping_varAccessSpecToObjectReference GetNamedVariableListAttributesResponse.itemId tràn bộ đệm]
• điểm: 20