제출 #880102: liftoff-sr CIPster master branch (reproduced on 1802525be27d33e19a9a83c163e331a1d13b1892) Out-of-bounds Read

An out-of-bounds read vulnerability exists in liftoff-sr CIPster in the normal ForwardOpen server processing path. The issue was publicly documented in GitHub issue #45 and reproduced on the master branch at commit 1802525 using the official POSIX sample server shipped by the repository (examples/POSIX, target name sample). A remote client can send a crafted ForwardOpen request whose application path is syntactically sufficient and references existing objects, but mixes object classes so that an I/O endpoint is not an Assembly object. The request is accepted far enough to enter the ordinary Connection Manager and I/O connection setup logic, after which the server reaches ConnectionData::CorrectSizes() and uses endpoint attribute 3 as though it were always Assembly data. When the resolved endpoint is a non-Assembly object such as Identity or Ethernet Link, attribute 3 is not compatible with the later ByteBuf usage. This causes invalid memory to be interpreted as a ByteBuf object and leads to an AddressSanitizer-reported out-of-bounds read followed by process termination. Based on the public report and the demonstrated crash behavior, the security impact supported by the available evidence is unauthenticated remote denial of service.

The vulnerable execution path described in the public report is the normal TCP explicit messaging / ForwardOpen path and not a direct parser-only test or an artificial unit-test harness. The reported call chain is CipConnMgrClass::forward_open() -> ConnectionData::ResolveInstances() -> GetCipClass(params.mgmnt_class)->OpenConnection(...) -> CipAssemblyClass::OpenConnection() -> CipConnectionClass::OpenIO() -> ConnectionData::CorrectSizes() -> ByteBuf::size(). The report states that the bug was triggered through the repository’s standard sample server entry point and that the crash occurs before the server can return an error response. This shows that the problem is protocol-reachable within the ordinary connection-establishment workflow.

The root cause is a mismatch between path validation semantics and later object-type assumptions. According to the issue, check_path() verifies that the application path is sufficient, that the referenced class exists, and that the referenced instance exists, but it does not require the resolved endpoint class to be kCipAssemblyClass. Because of that, the resolution stage can accept any existing object instance, including objects that are valid CIP objects but are not valid Assembly data endpoints for class 0 or class 1 I/O usage. ResolveInstances() then binds the resolved objects into config, consuming, and producing roles. The issue explains that for class 0/1 handling the code clears the direction bit by calling trigger.SetServer(false), but unlike the class 3 logic it does not impose an Assembly-only restriction on the resolved consuming and producing endpoints. As a consequence, a mixed-class combination such as Assembly/Identity or Assembly/Ethernet Link can survive validation and be carried into the rest of the connection setup sequence.

Once the request reaches CorrectSizes(), the implementation assumes an invariant that earlier code has not enforced. The issue explains that CorrectSizes() forces attribute 3 on the consuming and producing paths, retrieves attribute 3 from the resolved instance, obtains the backing data pointer, and then treats that pointer as ByteBuf* without validating that the instance class is actually Assembly or that the attribute type is the expected byte-array type. The result is a type confusion condition: a pointer to storage belonging to a different object layout is reinterpreted as a ByteBuf and then dereferenced through ByteBuf::size().

The public report also explains why the mixed-object case is unsafe. For Assembly instances, attribute 3 is registered as the assembly byte array and is therefore compatible with the later ByteBuf-based logic. However, the issue documents that Identity attribute 3 is registered as kCipUint backed by product_code_, and Ethernet Link attribute 3 is registered as kCip6Usint backed by the physical address field. Neither of these underlying objects is a ByteBuf. Reinterpreting those addresses as ByteBuf* is therefore invalid. The AddressSanitizer excerpt included in the issue shows an out-of-bounds read in ByteBuf::size() and indicates that the invalid read was located to the right of the global variable product_code_ defined in source/src/cip/cipidentity.cc. That crash signature is consistent with the reported type confusion mechanism.

From a security classification perspective, the currently supported impact is a remote denial-of-service condition caused by memory-unsafe handling of crafted ForwardOpen data. The available public material shows an out-of-bounds read and process abort. It does not by itself establish reliable code execution, stable data exfiltration, or a broader integrity impact, so the most accurate description should remain constrained to a remote crash / service interruption scenario. The attack does not require prior authentication in the reproduction narrative. A network client capable of reaching the CIP service can send a malformed but structurally accepted ForwardOpen request and cause the process to terminate. In deployments where the CIPster-based component provides industrial communication services, a crash at this stage can interrupt normal controller or device communication and reduce availability until the service is restarted.

The issue also contains concrete reproduction context. The reporter states that the problem was reproduced on the then-current public master commit 1802525 using the official POSIX example shipped by the project. The sample binary is built from the repository’s examples/POSIX directory and then exercised with a crafted request under ASan/UBSan instrumentation. The use of an official example strengthens the report because it shows the flaw through a standard product entry point rather than through a custom harness.

Public upstream activity further supports that this is a genuine defect. A later upstream commit, ea870a2, is explicitly titled “Fix a contant name typo, Address issue #45”. In that commit, the project adds class validation checks in ConnectionData::ResolveInstances() so that when config_instance is present, ConfigPath().GetClass() must be kCipAssemblyClass; when consuming_instance is present, ConsumingPath().GetClass() must be kCipAssemblyClass; and when producing_instance is present, ProducingPath().GetClass() must be kCipAssemblyClass. If those conditions are not met, the code now returns the corresponding Connection Manager extended status and exits the path instead of continuing into OpenIO() / CorrectSizes(). This change aligns directly with the reported root cause: the bug existed because non-Assembly objects could be accepted into roles later handled as Assembly data endpoints.

The most defensible affected-version statement, based on the public materials, is that CIPster master before commit ea870a2 is affected, with the issue explicitly reproduced on commit 1802525. If a versioned release boundary is required, the safest phrasing is to reference the affected development branch and the reproduced commit rather than inventing unsupported release numbers. Likewise, the safest affected component description is the ForwardOpen / Connection Manager / I/O endpoint resolution logic centered on ConnectionData::ResolveInstances() and ConnectionData::CorrectSizes() in source/src/cip/cipconnection.cc, with the crash surfacing in ByteBuf::size() when non-Assembly endpoint data is reinterpreted as ByteBuf state.

In summary, this vulnerability is a remotely reachable memory-safety flaw in CIPster’s ForwardOpen handling. The implementation accepts mixed-class application paths whose referenced objects exist but are not valid Assembly endpoints for subsequent I/O size correction. Later code assumes Assembly semantics, force-selects attribute 3, and dereferences the underlying storage as ByteBuf*. When the endpoint object is actually Identity or Ethernet Link, that assumption is false, producing an out-of-bounds read and terminating the server. The issue was publicly disclosed, reproduced against the official POSIX sample on commit 1802525, and later addressed upstream by commit ea870a2 through the addition of explicit Assembly-class validation for configuration, consuming, and producing paths. This makes the vulnerability suitable for treatment as an independently reportable product security issue with unauthenticated remote denial-of-service impact.

• 원천: ⚠️ https://github.com/liftoff-sr/CIPster/issues/45
• 사용자: Carnegie (UID 98671)
• 제출: 2026. 07. 04. PM 03:06 (2 개월 ago)
• 모더레이션: 2026. 08. 20. AM 08:52 (2 months later)
• 상태: 수락
• VulDB 항목: 393611 [liftoff-sr CIPster 1802525be27d33e19a9a83c163e331a1d13b1892 ForwardOpen cipconnectionmanager.cc forward_open product_code_ 정보 공개]
• 포인트들: 20