## Summary S2OPC 1.7.3 contains a **server-side heap out-of-bounds read** in the handling of two-dimensional OPC UA `NumericRange` / `IndexRange` writes to `String[]` values. When a client writes to a `String[]` node with a two-dimensional range, `set_range_matrix_on_string_array()` derives the number of source elements to process from the **first dimension of the destination range**. The function verifies that this range is valid for the destination array, but it does **not** verify that the source array contains the same number of elements. As a result, a request such as: ```bash Target node: ns=1;s=Array_String_001 IndexRange: 0:2,0 Required source shape: 3 strings, 1 character per string Actual source value: String[1] = {"Z"} ``` causes the server to process three source `SOPC_String` objects even though only one object was decoded from the request. During the second iteration, the server passes a one-past-the-end pointer to `set_range_string()`, which dereferences the nonexistent object's `Length` field and triggers a heap-buffer-overflow read. The issue is reachable through the normal OPC UA network `Write` service path and was reproduced against the official `toolkit_test_server`. --- ## Version - **Version:**`1.7.3` --- ## Impact - **Remote server-side memory-safety violation** - **Heap-based out-of-bounds read** - **Remote denial of service** - The server aborts before returning a `WriteResponse`, causing the client-side synchronous service call to fail with a closed connection and a null response. --- ## Full AddressSanitizer result <details> <summary>Click for Full ASan</summary> ```bash ================================================================= ==2162364==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5020000a78a0 at pc 0x555b3ac87f8f bp 0x7415161f9a90 sp 0x7415161f9a80 READ of size 4 at 0x5020000a78a0 thread T5 #0 0x555b3ac87f8e in set_range_string /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_builtintypes.c:5931 #1 0x555b3ac9ecfc in set_range_matrix_on_string_array /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_builtintypes.c:6065 #2 0x555b3ac9ecfc in set_range_matrix /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_builtintypes.c:6090 #3 0x555b3ac9ecfc in SOPC_Variant_SetRange /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_builtintypes.c:6196 #4 0x555b3ab98cf9 in set_value_indexed_helper /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/address_space_bs.c:1106 #5 0x555b3ab98cf9 in set_value_indexed /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/address_space_bs.c:1131 #6 0x555b3ab98cf9 in address_space_bs__set_Value /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/address_space_bs.c:1222 #7 0x555b3ac4769a in address_space__treat_write_1 /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/address_space.c:281 #8 0x555b3ac47b5b in address_space__treat_write_request_WriteValue /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/address_space.c:139 #9 0x555b3abe8471 in service_write_1__treat_write_request_WriteValues /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_write_1.c:81 #10 0x555b3abe81a2 in service_write__treat_write_request /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_write.c:61 #11 0x555b3abd9d86 in service_mgr__treat_session_nano_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:364 #12 0x555b3abda04b in service_mgr__treat_session_nano_extended_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:429 #13 0x555b3abdae80 in service_mgr__treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:680 #14 0x555b3abdae80 in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:630 #15 0x555b3abddad7 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #16 0x555b3abd514a in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #17 0x555b3ab9fe86 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #18 0x555b3ac7b5ca in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #19 0x74151ba94ac2 in start_thread nptl/pthread_create.c:442 #20 0x74151bb268cf (/lib/x86_64-linux-gnu/libc.so.6+0x1268cf) 0x5020000a78a0 is located 0 bytes to the right of 16-byte region [0x5020000a7890,0x5020000a78a0) allocated by thread T5 here: #0 0x555b3aae96d7 in calloc (/home/weichuan/wc/S2OPC/build-asan/bin/toolkit_test_server+0x4f66d7) #1 0x555b3acb1d4b in SOPC_Read_Array /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3050 #2 0x555b3acb204b in ReadVariantArrayBuiltInType /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:2620 #3 0x555b3acb2e54 in ReadVariantArrayBuiltInType /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:2689 #4 0x555b3acb2e54 in SOPC_Variant_Read_Internal /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:2689 #5 0x555b3acb4a07 in SOPC_DataValue_Read_Internal /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:2939 #6 0x555b3aca30fa in SOPC_EncodeableObject_Decode /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encodeabletype.c:1274 #7 0x555b3acb1df1 in SOPC_Read_Array /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3064 #8 0x555b3aca32c5 in SOPC_EncodeableObject_Decode /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encodeabletype.c:1263 #9 0x555b3acb72ee in SOPC_DecodeMsg_HeaderOrBody /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_encoder.c:3202 #10 0x555b3ac16e08 in message_in_bs__decode_msg /home/weichuan/wc/S2OPC/src/ClientServer/services/b2c/message_in_bs.c:198 #11 0x555b3abda933 in service_mgr__decode_and_treat_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:607 #12 0x555b3abddad7 in service_mgr__server_receive_session_service_req /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/service_mgr.c:1177 #13 0x555b3abd514a in io_dispatch_mgr__receive_msg_buffer /home/weichuan/wc/S2OPC/src/ClientServer/services/bgenc/io_dispatch_mgr.c:227 #14 0x555b3ab9fe86 in onSecureChannelEvent /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:197 #15 0x555b3ac7b5ca in looper_loop /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:108 #16 0x74151ba94ac2 in start_thread nptl/pthread_create.c:442 Thread T5 created by T0 here: #0 0x555b3aa8d325 in pthread_create (/home/weichuan/wc/S2OPC/build-asan/bin/toolkit_test_server+0x49a325) #1 0x555b3ac73511 in create_thread /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:275 #2 0x555b3ac73511 in SOPC_Thread_Create /home/weichuan/wc/S2OPC/src/Common/helpers_platform_dep/linux/p_sopc_threads.c:336 #3 0x555b3ac7be02 in SOPC_Looper_Create /home/weichuan/wc/S2OPC/src/Common/helpers/sopc_event_handler.c:167 #4 0x555b3aba23ab in SOPC_Services_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/services/sopc_services_api.c:904 #5 0x555b3ab7fdc3 in SOPC_Toolkit_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/configuration/sopc_toolkit_config.c:141 #6 0x555b3ab51833 in SOPC_CommonHelper_Initialize /home/weichuan/wc/S2OPC/src/ClientServer/frontend/common_wrapper/libs2opc_common_config.c:145 #7 0x555b3aa55396 in Server_Initialize /home/weichuan/wc/S2OPC/tests/ClientServer/validation_tests/server/toolkit_test_server.c:290 #8 0x555b3aa55396 in main /home/weichuan/wc/S2OPC/tests/ClientServer/validation_tests/server/toolkit_test_server.c:1204 #9 0x74151ba29d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/weichuan/wc/S2OPC/src/Common/opcua_types/sopc_builtintypes.c:5931 in set_range_string Shadow bytes around the buggy address: 0x0a048000cec0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa 0x0a048000ced0: fa fa 00 00 fa fa fd fa fa fa fd fa fa fa 06 fa 0x0a048000cee0: fa fa 06 fa fa fa fd fd fa fa fd fa fa fa fd fd 0x0a048000cef0: fa fa 00 01 fa fa 06 fa fa fa fd fd fa fa fd fa 0x0a048000cf00: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 06 fa =>0x0a048000cf10: fa fa 00 00[fa]fa 02 fa fa fa 00 fa fa fa 00 00 0x0a048000cf20: fa fa fd fa fa fa 00 00 fa fa 00 00 fa fa fa fa 0x0a048000cf30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a048000cf40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a048000cf50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a048000cf60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==2162364==ABORTING ``` </details> --- ## Root cause ### 1. The server correctly decodes a one-element source array The PoC constructs a normal `OpcUa_WriteRequest` with a source Variant configured as: ```c dv.Value.BuiltInTypeId = SOPC_String_Id; dv.Value.ArrayType = SOPC_VariantArrayType_Array; dv.Value.Value.Array.Length = 1; dv.Value.Value.Array.Content.StringArr = SOPC_Calloc(1, sizeof(SOPC_String)); ``` The only source element is initialized to `"Z"`. The server-side AddressSanitizer allocation stack confirms that the vulnerable heap object was allocated while decoding the network request: ```bash calloc -> SOPC_Read_Array -> ReadVariantArrayBuiltInType -> SOPC_Variant_Read_Internal -> SOPC_DataValue_Read_Internal -> SOPC_EncodeableObject_Decode -> SOPC_DecodeMsg_HeaderOrBody -> message_in_bs__decode_msg ``` Therefore, the out-of-bounds source object is the array decoded from the client request. It is not an object manually injected into the server process. ### 2. `SOPC_Variant_HasRange()` validates the destination range, not source cardinality In `set_value_indexed_helper()`, the server checks whether the requested NumericRange exists in the current destination node value: ```bash node BuiltInTypeId = 12 // SOPC_String_Id node ArrayType = 1 // SOPC_VariantArrayType_Array node_len = 29 new_len = 1 dim0 = 0:2 dim1 = 0:0 ``` GDB observed: ```bash status = 0 has_range = 1 ``` This result is expected because the first-dimension destination range `0:2` is valid inside an array of length 29, and the selected target strings contain character index 0. However, this check does not establish the separate write invariant: ```bash source array length == first-dimension range span ``` The following incompatible values therefore coexist after the pre-check: ```bash new_len = 1 dim0 = 0:2 span = 3 ``` This is a classic case of **destination-range validation succeeding while source-shape validation is absent**. ### 3. The special `String[]` two-dimensional range path omits source cardinality validation The vulnerable helper computes its iteration count from the destination range: ```c const uint32_t array_end_index = range->dimensions[0].end; const uint32_t array_length = array_end_index - range->dimensions[0].start + 1; ``` For the reproduced request: ```bash range->dimensions[0].start = 0 range->dimensions[0].end = 2 array_length = 3 ``` It then performs: ```c for (uint32_t i = 0; i < array_length && SOPC_STATUS_OK == status; i++) { status = set_range_string(&strArray[range->dimensions[0].start + i], &src->Value.Array.Content.StringArr[i], &range->dimensions[1]); } ``` The loop combines: ```bash Loop bound: first-dimension destination range span Source access: src->Value.Array.Content.StringArr[i] ``` but never verifies: ```c src->Value.Array.Length == array_length ``` That missing invariant is the root cause. This is also inconsistent with the expected behavior of other range-copy paths, which must reject source data whose dimensions do not match the selected destination range. ### 4. First iteration is valid GDB observed: ```bash src_len = 1 src_base = 0x5020000bd890 src_limit = 0x5020000bd8a0 sizeof(SOPC_String)= 16 i = 0 current_src = 0x5020000bd890 current_dst = 0x515000019300 ``` The first call to `set_range_string()` received: ```bash dst->Length = 22 src->Length = 1 dimension = 0:0 ``` The second-dimension span is one byte/character: ```bash 0 - 0 + 1 = 1 ``` Therefore, the source string `"Z"` legitimately satisfies the per-string length check, and the first partial write succeeds. ### 5. Second iteration produces a one-past-the-end source pointer During the second iteration, GDB observed: ```bash i = 1 array_length= 3 current_src = 0x5020000bd8a0 src_base = 0x5020000bd890 src_limit = 0x5020000bd8a0 ``` Therefore: ```bash current_src == src_limit ``` Pointer calculation: ```bash &src[1] = src_base + 1 * sizeof(SOPC_String) = 0x5020000bd890 + 0x10 = 0x5020000bd8a0 ``` This is the one-past-the-end pointer for a one-element array. Constructing or comparing a one-past-the-end pointer is not by itself the invalid memory access. The security violation occurs when that pointer is passed as a valid object and dereferenced. ### 6. `set_range_string()` performs the first confirmed invalid read The invalid pointer is passed to `set_range_string()`, which evaluates a condition equivalent to: ```c if (((uint32_t) src->Length) != (range->end - range->start + 1)) { return SOPC_STATUS_INVALID_PARAMETERS; } ``` At this point, `src` does not designate a valid `SOPC_String`. GDB displayed synthetic values such as: ```bash src = 0x5020000bd8a0 src->Length = 4354 src->Data = 0x529000009 ``` These values are not valid string metadata. GDB is interpreting bytes outside the allocation according to the `SOPC_String` field layout. The first confirmed invalid access is the four-byte load of the `int32_t Length` field: ```bash READ of size 4 ``` AddressSanitizer reports that the read begins exactly at the end of the 16-byte allocation: ```bash 0x5020000a78a0 is located 0 bytes to the right of 16-byte region [0x5020000a7890, 0x5020000a78a0) ``` This precisely matches a read of `StringArr[1].Length` from a one-element `SOPC_String` array on the tested x86-64 ABI. `set_range_string()` is the **crash location**, but not the root cause. Its caller supplied an invalid source object pointer because `set_range_matrix_on_string_array()` failed to validate source cardinality before iterating. ### Root-cause invariant The implementation must enforce: ```text src->Value.Array.Length == range->dimensions[0].end - range->dimensions[0].start + 1 ``` before the first source-array element is indexed. --- ## Proof-of-concept source [PoC.zip](https://github.com/user-attachments/files/30094495/PoC.zip) --- ## Reproduction ### Build with AddressSanitizer From the repository root: ```bash cmake -S . -B build-asan \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DS2OPC_CLIENTSERVER_ONLY=ON \ -DENABLE_TESTING=ON \ -DENABLE_SAMPLES=ON \ -DWITH_ASAN=ON \ -DWARNINGS_AS_ERRORS=OFF cmake --build build-asan -j 8 \ --target toolkit_test_server poc ``` ### Start the server Open terminal 1: ```bash cd build-asan/bin TEST_PASSWORD_PRIVATE_KEY=password ./toolkit_test_server ``` ### Run the client Open terminal 2: ```bash cd build-asan/bin TEST_CLIENT_XML_CONFIG=./S2OPC_Client_Test_Config.xml \ TEST_PASSWORD_PRIVATE_KEY=password ./poc ``` The client sends: ```bash NodeId: ns=1;s=Array_String_001 Attribute: Value IndexRange: 0:2,0 Source Variant type: String[] Source array length: 1 Source array contents: {"Z"} ``` --- ## Expected behavior The server should reject the request without accessing memory outside the decoded source array. For the request: ```bash IndexRange first-dimension span = 3 Source String[] length = 1 ``` the per-item `WriteResponse` status should be equivalent to: ```bash Bad_IndexRangeDataMismatch ``` No target value should be partially modified, and the server process should remain available. --- ## Actual behavior The destination range passes `SOPC_Variant_HasRange()`. `set_range_matrix_on_string_array()` then performs one valid write using `src[0]`, advances to `src[1]`, and dereferences a one-past-the-end `SOPC_String*`. AddressSanitizer reports a four-byte heap-buffer-overflow read and aborts the server. --- ## Fix suggestion ### Required memory-safety fix Before indexing `src->Value.Array.Content.StringArr[i]`, enforce strict equality between: - The decoded source array length - The first-dimension NumericRange span ### Minimal source patch Apply the following check in `set_range_matrix_on_string_array()` immediately after calculating `array_length` and before entering the loop: ```diff diff --git a/src/Common/opcua_types/sopc_builtintypes.c b/src/Common/opcua_types/sopc_builtintypes.c --- a/src/Common/opcua_types/sopc_builtintypes.c +++ b/src/Common/opcua_types/sopc_builtintypes.c @@ const uint32_t array_end_index = range->dimensions[0].end; const uint32_t array_length = array_end_index - range->dimensions[0].start + 1; + /* + * For a two-dimensional range applied to a String[] / ByteString[], + * the first dimension selects array elements. The source array must + * therefore contain exactly one element for each selected destination + * element. + * + * Without this check, the loop below is bounded by the destination + * range span and can read beyond src->Value.Array.Content.StringArr. + */ + if (src->Value.Array.Length < 0 || + (uint32_t) src->Value.Array.Length != array_length) + { + return SOPC_STATUS_INVALID_PARAMETERS; + } + for (uint32_t i = 0; i < array_length && SOPC_STATUS_OK == status; i++) { status = set_range_string( &strArray[range->dimensions[0].start + i], &src->Value.Array.Content.StringArr[i], &range->dimensions[1]); } ```