Privileged IPC cleanup as a filesystem primitive

A privileged service can authenticate a client process and still misuse values supplied by that process. Error cleanup is particularly interesting: it often repeats filesystem operations with fewer checks than the successful path.

Research anchor and scope

Quarkslab’s Cato research confirmed the issue on Windows client versions 6.2.0 and 6.4.6; the vendor reported versions before 6.12.6 affected. A signed-process check guarded the pipe, but running a payload inside a trusted client satisfied it. A client-supplied SID influenced a .stp path, and invalid split-tunnel input reached privileged deletion. Filesystem redirection and an additional Windows Installer rollback chain supplied the final escalation.

Model four trust boundaries

First, identify the actual peer from the IPC transport. A PID reported by the operating system is different evidence from a PID placed in the message. Second, ask what the client’s credentials authorize: access to a service is not permission to perform every service action. Third, trace which message fields become filesystem components. Fourth, inspect the final operation after normalization and link resolution.

For a harmless toy service, imagine a worker constructs storage/session_<label>.tmp, writes a conversion result, and removes it on parse failure. If label contains path separators, the lexical prefix does not guarantee confinement. A fixed suffix restricts the primitive, but a link-aware filesystem operation may resolve the path to another object. Record whether the operation follows links, removes the link itself, deletes a file, or recursively deletes a directory.

Investigate cleanup deliberately

Build a state table for readable valid input, readable invalid input, missing input, and partially created output. Observe which paths are used on each edge and which identity performs the operation. Cleanup may delete a path that existed before the request rather than only the artifact created by it. Use a disposable marker file to demonstrate this distinction.

Then state the primitive precisely: attacker-selected path, constrained suffix, service token, required IPC foothold, and any race or redirection dependency. An arbitrary-delete primitive does not grant arbitrary write or immediate execution. Exploit composition requires a separate consumer whose security relies on the deleted object or directory.

Limits and transferable clues

Executable signatures authenticate the image on disk; they do not attest every runtime instruction or message. Injection feasibility depends on process access rights and mitigations and must be established separately. Installer rollback abuse also depends on installer state and filesystem behavior; it cannot be inferred from deletion alone. Look for client-generated identity strings, conversion handlers, fallback paths, and privileged cleanup after validation errors. Preserve patched version boundaries when comparing vendor products.