提交 #844678: MZ Automation GmbH libiec61850 1.6.1; fixed version not confirmed Double Free

A server-side double free vulnerability was identified in libiec61850 version 1.6.1.

Vendor: MZ Automation GmbH
Product: libiec61850
Affected version: 1.6.1
Version link: https://github.com/mz-automation/libiec61850/releases/tag/v1.6.1
Official repository: https://github.com/mz-automation/libiec61850
Vulnerability type: server-side double free / memory corruption / improper resource lifetime management
Primary CWE: CWE-415 Double Free
Additional CWE candidates: CWE-672 Operation on a Resource after Expiration or Release, CWE-664 Improper Control of a Resource Through its Lifetime
Suggested CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Suggested severity: High, 7.5

The vulnerability affects the MMS file service ObtainFile handling in libiec61850 1.6.1. The relevant code is located mainly in src/mms/iso_mms/server/mms_file_service.c and src/mms/iso_mms/server/mms_server_connection.c. The issue is reachable through the official example server examples/server_example_files/server_example_files.c when MMS file service / ObtainFile access is enabled.

Root cause:
The issue is caused by incomplete cleanup of the reusable MmsObtainFileTask object. During a successful ObtainFile operation, the server stores the destination file handle in MmsObtainFileTask::fileHandle. When the file-close response is handled, the server closes this FILE* through FileSystem_closeFile(), but the pointer is not reset to NULL. The task is then marked as MMS_FILE_UPLOAD_STATE_NOT_USED and can be reused by a later ObtainFile request. If a subsequent ObtainFile request reuses the same task and fails to create the destination file, the destination-error cleanup path observes the stale non-NULL task->fileHandle from the previous successful request and calls FileSystem_closeFile() on it again. This causes a second fclose/free of the same underlying glibc FILE object and results in a server-side double free.

Trigger entry:
The vulnerable server used for reproduction is the unmodified official example server:
examples/server_example_files/server_example_files.c

The client-side reproducer is a minimal PoC:
examples/server_example_files/client_obtain_stale_handle_poc.c

The PoC only uses the public API IedConnection_setFile() to send valid MMS ObtainFile requests with controlled source and destination filenames. No server-side code and no library logic were modified. The issue is not a parser-only case and does not require malformed ASN.1 input, local access, user interaction, concurrent race conditions, or abnormal connection teardown.

Attack scenario:
A remote client that can connect to a libiec61850-based IEC 61850/MMS server with MMS file service / ObtainFile enabled can trigger the bug by sending two valid ObtainFile requests. The first request succeeds and causes the server to create, write, close, and complete an ObtainFile task. Because the successful file-close response path closes task->fileHandle without clearing it, the task retains a stale FILE* value after being marked as reusable. The second request uses a destination path that cannot be created. This should only return an MMS/IED service error, but the destination-error cleanup path instead closes the stale FILE* from the previous request again. The confirmed impact is a server process crash and remote denial of service.

Impact:
The demonstrated impact is availability loss. An unauthenticated network client can crash a vulnerable server if the server exposes MMS file service / ObtainFile functionality and allows the relevant file operation. No confidentiality impact, integrity impact, or remote code execution is claimed based on the current evidence.

Reproduction environment:
Target version: libiec61850 1.6.1
Server binary: ./build-asan/examples/server_example_files/server_example_files
Client PoC binary: /tmp/client_obtain_stale_handle_poc_asan
Server source: examples/server_example_files/server_example_files.c
Client PoC source: examples/server_example_files/client_obtain_stale_handle_poc.c

Build commands:
cd /home/weichuan/wc/wc-2/libiec61850-v1.6.1

cmake -S . -B build-asan \
-DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
-DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address,undefined"

cmake --build build-asan --target server_example_files -j4

gcc -g -fsanitize=address,undefined \
-Iconfig -Ihal/inc -Isrc/common/inc -Isrc/mms/inc -Isrc/mms/inc_private -Isrc/mms/asn1 \
-Isrc/iec61850/inc -Isrc/iec61850/inc_private -Isrc/goose -Isrc/sampled_values \
-Isrc/logging -Isrc/tls -Isrc/r_session \
examples/server_example_files/client_obtain_stale_handle_poc.c \
build-asan/src/libiec61850.a build-asan/hal/libhal.a \
-lpthread -lm \
-o /tmp/client_obtain_stale_handle_poc_asan

Preparation:
The official server example uses the relative path ./vmd-filestore/, so the server must be started from the repository root.

cd /home/weichuan/wc/wc-2/libiec61850-v1.6.1

mkdir -p vmd-filestore
rm -f vmd-filestore/ok.bin
rm -rf vmd-filestore/missingdir

mkdir -p /tmp/obtain-client-store
printf 'ABCDEFGH\n' > /tmp/obtain-client-store/source.bin

Start the server:
cd /home/weichuan/wc/wc-2/libiec61850-v1.6.1

ASAN_OPTIONS=abort_on_error=1:print_stacktrace=1 \
./build-asan/examples/server_example_files/server_example_files 11003

Control case:
A failed ObtainFile request alone should not crash the server.

cd /home/weichuan/wc/wc-2/libiec61850-v1.6.1

ASAN_OPTIONS=abort_on_error=1:print_stacktrace=1 \
/tmp/client_obtain_stale_handle_poc_asan 127.0.0.1 11003 /tmp/obtain-client-store/ fail-only

Expected control result:
[2] result IED error = 99

The server remains running. This shows that a destination file creation failure alone is not sufficient to crash the server.

Trigger case:
Restart the server for a clean run, then execute:

cd /home/weichuan/wc/wc-2/libiec61850-v1.6.1

ASAN_OPTIONS=abort_on_error=1:print_stacktrace=1 \
/tmp/client_obtain_stale_handle_poc_asan 127.0.0.1 11003 /tmp/obtain-client-store/

Expected client output:
[1] success
[2] result IED error = 99

Expected server result:
The server crashes with AddressSanitizer reporting an attempting double-free.

Relevant ASan log:
ERROR: AddressSanitizer: attempting double-free on 0x515000000080 in thread T1
#0 __interceptor_free
#1 _IO_deallocate_file
#2 _IO_new_fclose
#3 __interceptor_fclose
#5 FileSystem_closeFile
#6 mmsServer_fileUploadTask /home/weichuan/wc/wc-2/libiec61850-v1.6.1/src/mms/iso_mms/server/mms_file_service.c:569
#7 MmsServer_handleBackgroundTasks /home/weichuan/wc/wc-2/libiec61850-v1.6.1/src/mms/iso_mms/server/mms_server.c:855
#8 processPeriodicTasks /home/weichuan/wc/wc-2/libiec61850-v1.6.1/src/iec61850/server/mms_mapping/mms_mapping.c:4508
#9 IedServer_performPeriodicTasks /home/weichuan/wc/wc-2/libiec61850-v1.6.1/src/iec61850/server/mms_mapping/mms_mapping.c:4514
#10 singleThreadedServerThread /home/weichuan/wc/wc-2/libiec61850-v1.6.1/src/iec61850/server/impl/ied_server.c:862

ASan also reports that the same 472-byte glibc FILE object was previously allocated by fopen and later freed by fclose before being closed again in mmsServer_fileUploadTask.

PoC description:
The PoC performs two ObtainFile operations through IedConnection_setFile(). In normal trigger mode, the first operation uses a valid destination so that the server successfully creates and closes the target file, leaving a stale task->fileHandle because the successful file-close response path does not clear it. The second operation uses a destination path that cannot be created on the server side. This should only return an MMS/IED error, but instead the destination-error cleanup path closes the stale fileHandle again and crashes the server. The PoC also has a fail-only mode that sends only the failed request; this mode does not crash the server and is used as a control case.

• 来源: ⚠️ https://github.com/gff-cw/information/issues/1
• 用户: Carnegie (UID 98671)
• 提交: 2026-06-01 11時03分 (2 月前)
• 管理: 2026-08-02 21時07分 (2 months later)
• 状态: 已接受
• VulDB条目: 385410 [mz-automation libiec61850 直到 1.6.1 MMS ObtainFile Task mms_file_service.c fileHandle 内存损坏]
• 积分: 20