Robustifying ML-powered Network Classifiers with PANTS

Pig in a Poke: Automatically Detecting and Exploiting Link Following Vulnerabilities in Windows File Operations

Authors: Bocheng Xiang, Yuan Zhang, Fengyu Liu, Hao Huang, Zihan Lin, Min Yang (Fudan University)

Conference: USENIX Security

YouTube: This article is based on a peer-reviewed paper, not a recorded talk. No video is available.

Overview

This article delves into the critical security research presented in "Pig in a Poke: Automatically Detecting and Exploiting Link Following Vulnerabilities in Windows File Operations." The paper introduces Link Following Vulnerabilities (LFVulns), a significant class of security flaws in Windows systems stemming from the improper handling of symbolic links by privileged programs. These vulnerabilities allow low-privileged attackers to manipulate sensitive system files, leading to severe consequences such as Local Privilege Escalation (LPE) and Denial of Service (DoS). The research highlights that despite the widespread use of symbolic links, developers often overlook the necessary validation, creating a fertile ground for exploitation.

The core contribution of this work is LinkZard, a novel, automated prototype designed to detect and exploit LFVulns in Windows. LinkZard addresses the complex challenges of identifying these vulnerabilities by employing a two-phase approach: an exploration phase that utilizes efficient file state fuzzing to uncover potential flaws, and an exploitation phase that automatically locates vulnerable code segments ("sinks") and crafts exploitation code. The tool’s effectiveness was rigorously demonstrated through an empirical study of existing LFVulns and its application to 120 commercial programs from major vendors.

LinkZard's impact is substantial, having successfully detected and exploited 55 zero-day vulnerabilities across 49 programs from vendors like Microsoft, Apple, Intel, and Tencent. These findings led to 15 CVE assignments and numerous bug bounty rewards, underscoring the prevalence and severity of LFVulns in real-world software. This research not only provides a deeper understanding of the root causes and exploitation mechanisms of LFVulns but also offers a robust, automated solution for their identification and remediation, significantly enhancing the security posture of Windows systems.

Background

Symbolic links are a fundamental feature in Windows, enabling flexible file system interactions, such as desktop shortcuts and directory junctions. While convenient, their inherent behavior of transparently redirecting operations to a target file can be weaponized if not properly validated by applications, particularly those running with elevated privileges. This lack of validation creates Link Following Vulnerabilities (LFVulns). An attacker can craft a symbolic link pointing to a protected system file, and if a privileged program then operates on this attacker-controlled link without proper checks, it inadvertently manipulates the sensitive target file with elevated permissions. This can lead to arbitrary file manipulation, resulting in Local Privilege Escalation (LPE) or Denial of Service (DoS).

The threat model for LFVulns assumes an attacker has a standard, low-privileged user account on the target system (e.g., via weak passwords or malware). From this vantage point, they can interact with privileged applications, often through Inter-Process Communication (IPC) mechanisms, to trigger file operations. The security risks are categorized into:

• Denial of Service (DoS): Attackers can create or modify critical system files, like C:\Windows\System32\cng.sys, leading to boot failures and rendering the system unusable.
• Local Privilege Escalation (LPE): Attackers can delete sensitive files or directories, or move malicious files (e.g., a DLL) into system paths like C:\Windows\System32, enabling DLL side-loading for privilege escalation. A common LPE technique involves abusing Windows' automatic rollback mechanism during installer failures, where deleting the C:\Config.msi directory allows an attacker to recreate it, inject malicious rollback scripts (.rbs, .rbf), and achieve elevated execution when the rollback is triggered.

A crucial aspect of exploiting LFVulns in Windows is the ability to create pseudo-symbolic links without administrative privileges, as traditional symbolic link creation requires them. Attackers leverage two primary mechanisms:

1. Directory Junctions (Mount Points): These link one directory to another and do not require administrator privileges. An attacker can use mklink /j <source> <target> to make a source directory act as a mount point to a target directory.
2. Object Manager Symbolic Links (ObjSymlinks): These exist within the Windows Object Manager's namespaces and can reference various system objects. Some namespaces, such as \RPC Control\, are writable by low-privileged users. Attackers can mount a directory path into such a writable namespace using a directory junction, and then create an ObjSymlink within that namespace pointing to an arbitrary target file.

Another key exploitation mechanism is Opportunistic Locks (OpLocks). File operations in privileged programs often occur sequentially. If an LFVuln requires specific conditions to be met before exploitation, an attacker might need to pause the program's operations to configure the pseudo-symbolic link at the opportune moment. OpLocks provide this stable time window by temporarily blocking access to a file, granting exclusive control to the attacker until the lock is released, allowing the pseudo-symbolic link to be set up before the vulnerable operation proceeds.

For instance, the paper illustrates a real-world LFVuln (CVE-2024-491) in a Windows service. A privileged function IPC_CleanTempFile iterates through and deletes .tmp files in an attacker-controlled temporary directory. An attacker can create a .tmp file, set an OpLock on it, and then, in the OpLock callback, create a directory junction to \RPC Control and an ObjSymlink** linking the .tmp file path to a victim_file. Releasing the OpLock then causes the privileged service to follow the pseudo-symbolic link and delete the victim_file with elevated privileges. This example highlights the complexity and prevalence of such vulnerabilities.

Prior work, such as Jerry [6], focused on identifying file-hijacking vulnerabilities caused by weak file permission controls. While Jerry could detect a limited set of LFVulns due to some overlap, it suffered from several limitations: it didn't comprehensively explore file operations, leading to a low recall rate (57.14% in the authors' dataset); its detection strategy was coarse-grained, often flagging single file operations as vulnerabilities, resulting in many false positives and requiring significant manual effort; and crucially, it lacked automated exploitation capabilities. These shortcomings motivated the development of LinkZard.

Key Findings

The empirical study conducted by the authors on 145 LFVulns, including the reproduction of 42 for ground truth, yielded three critical findings that underpin the design of LinkZard:

Finding 1: The root cause of LFVulns originates from the inadequate validation of symbolic links during the process of file operations.

Windows systems enable symbolic link following by default, a behavior often overlooked by developers. This oversight means programs frequently lack proper validation for symbolic links when performing file operations, especially on attacker-controlled files (e.g., in C:\Windows\temp). The diverse nature of file operations in Windows further complicates developers' ability to ensure consistent validation across all functionalities. This creates a "weakest link" scenario, where the absence of proper checks in any single file operation can introduce an LFVuln, enabling arbitrary manipulation of system files.

Finding 2: There are four distinct types of dangerous file operations (sinks) leading to LFVulns, each represented by specific sequences of file operation APIs.

The study formalized "sinks" as manually defined sequences of high-risk file API operations that target the same file and collectively indicate an exploitable condition. These sinks are composed of fundamental Windows APIs [29]. The four identified sink types, along with their prevalence in the dataset, are:

1. Unsafe Creation, Write, and Overwriting (49 cases, 33.8%): Most prevalent due to frequent file creation and write operations. Exploited for arbitrary file creation and writing.
2. Unsafe Copying and Moving (14 cases, 9.7%): Occurs when both source and destination files in copy/move operations are attacker-controlled. Exploited for arbitrary file movements, including deletion and creation.
3. Unsafe Access Control Configuration (14 cases, 9.7%): Arises when privileged programs assign permissive Access Control Lists (ACLs) [30] to files without verifying if they are symbolic links. Allows attackers to redirect permissions to arbitrary files.
4. Unsafe Deletion (68 cases, 46.8%): The most prevalent sink, often seen in routines that create and delete temporary files. The inherent design of deletion processes in Windows, which often involves following directory junctions, significantly increases the likelihood of LFVulns. An example sequence for this sink is QueryDirectory → CreateFile → DeleteFile.

Finding 3: File state constraints are the most critical factor hindering both the automated detection and exploitation of LFVulns.

These constraints were found in 46% (66/145) of the analyzed vulnerabilities. File states encompass attributes like file name, size, content, and timestamps, influencing how programs interact with files. File state constraints are prerequisite conditions where specific file states must be satisfied for a privileged program to proceed with deeper or more critical file operations; otherwise, the program may terminate or skip subsequent actions.

• Approximately 41% of these constraints relate to file name constraints (e.g., specific formats like UUIDs or extensions like .log, .tmp).
• Around 21% are linked to file content constraints (e.g., Magic Numbers [34]).

File state constraints are further categorized based on their position relative to the "sink":

• Pre-sink constraints (12/66, 18.2%): These exist before a privileged program's file operation triggers the sink. Unsolved pre-sink constraints prevent the exploration of deeper file operations and the triggering of potential sinks, leading to missed vulnerabilities. Once solved, an attacker can create a pseudo-symbolic link at any point before the sink is triggered.
• On-sink constraints (54/66, 81.8%): These are present within the dangerous API sequences (sinks) themselves. Solving these prompts the program to proceed, requiring the attacker to race against the program to create the pseudo-symbolic link in a narrow time window. OpLocks are consistently used to stabilize exploitation for on-sink constraints.

These findings highlight the necessity for an automated approach that can effectively address file state constraints, accurately locate sinks within complex file operation sequences, and implement flexible exploitation strategies.

Technical Deep Dive

LinkZard is designed as the first prototype for automated detection and exploitation of LFVulns in Windows systems. Its architecture comprises two main phases: the exploration phase and the exploitation phase, guided by specific insights into the nature of file operations and vulnerability sinks.

Challenges and Insights

The researchers identified two primary challenges:

1. Solving file state constraints for effective detection: As 46% of LFVulns involve file state constraints, efficiently detecting them requires addressing these conditions. Traditional static analysis (prone to path explosion and obfuscation) and dynamic fuzzing (lacking file-state-specific feedback and mutation strategies) are insufficient.
2. Automating LFVuln exploitation: Pinpointing the exact position for attacker actions within complex file operation sequences and devising strategies for both pre-sink and on-sink constraints (especially using OpLocks) are significant hurdles.

LinkZard's design is inspired by two key insights:

• File operations often involve specific state queries, and these state constraints are highly concentrated on attributes like file name, content, size, and time. This allows for targeted mutation operators guided by query information as feedback.
• LFVuln sinks are shorter invocation sequences of file operation APIs that form a method call graph, which is a subgraph of the program's entire file operation graph. This insight enables the use of subgraph isomorphism techniques to locate sinks efficiently.

Exploration Phase: Feedback-Driven File State Fuzzing

The exploration phase aims to dynamically solve file state constraints to uncover potential vulnerabilities. It involves three main components: IPC Call, File State Fuzz, and Constraint Inference.

IPC Call

To interact directly and efficiently with privileged programs, LinkZard leverages Inter-Process Communication (IPC). It analyzes typical Windows communication mechanisms:

• Service Management [39]: For programs registered as services, LinkZard issues control commands (start, stop, restart) via the Service Manager, which often triggers extensive file operations.
• Remote Procedure Call (RPC) [40]: For RPC-exposed interfaces, LinkZard synthesizes RPC stubs by inferring parameter types from IDL (Interface Definition Language) metadata [41]. It uses a bottom-up approach to construct complex nested interface parameters, generating random values for primitive types and using NULL for unknown types. This combined strategy ensures direct interaction and triggers diverse file operations.

File State Fuzz

This is a feedback-driven fuzzing strategy (outlined in Algorithm 1 in the paper) designed to solve file state constraints.

• Feedback Mechanism: Instead of extensive user-level API modeling, LinkZard uses kernel-level hook techniques to monitor two primary state queries: File State Queries [42] and Directory State Queries [43]. These cover 28 distinct file states (e.g., file names, sizes, time attributes, permissions, directory enumeration). When a program issues a query related to a file state constraint, LinkZard intercepts it, observing the specific state requested. This observed information serves as feedback to guide targeted mutations, significantly reducing the mutation state space.
• Mutation Operators: Three distinct and efficient mutation operators are employed:

1. Z3-based Constant Value Injection: For state information involving pattern matching or fuzzy queries (e.g., wildcard file names), LinkZard uses the Z3 SMT solver [44] to generate specific constant values that satisfy the patterns, injecting them into corresponding file states.
2. Similarity-based Mutation: When state information shows similarities (e.g., .log.1, .log.2), LinkZard calculates edit distance [45] and iteratively alters components to generate new, similar states (e.g., .log.3).
3. Flip-based Mutation: Inspired by traditional fuzzing, this operator randomly flips file attributes (e.g., changing a file to a directory, or a non-compressed file to a compressed one) to generate new file states.

• Constraint Inference: Given the black-box nature of programs, LinkZard infers whether constraints have been solved by analyzing two dimensions of file operations after mutation:

1. Operation count: Checking if the number of operations on the mutated file increases.
2. Operation types: Verifying if the types of operations increase.

An increase in both dimensions indicates that state constraints have likely been successfully resolved. Files that resolve constraints are marked, and the process transitions to the exploitation phase, yielding a comprehensive set of file operations performed by the privileged program.

Exploitation Phase: Sink Location and Code Wrapping

The exploitation phase formalizes file operations, locates sinks, identifies constraint types, and generates state-specific exploitation code.

File Operation Primitive Graph (FOPG) Build

LinkZard constructs a File Operation Primitive Graph (FOPG), a directed graph that systematically represents file operations and their sequential relationships.

• Nodes: Each node N = ⟨Os, Od, Op, R⟩ represents a distinct file operation, where Os is the operation subject (user context), Od is the target file, Op is the operation type (e.g., write, rename), and R is the return value.
• Edges: Directed edges e ∈ E capture the sequential execution of operations. Importantly, operations targeting parent and sibling directories are included as predecessors due to their technical necessity for pseudo-symbolic link creation. Pruning strategies are applied to exclude operations on strictly protected paths and remove redundant operations on the same file, focusing on critical paths.

Sink and Constraint Location

This process involves identifying the sink within the FOPG, indicating an LFVuln, and then classifying associated constraints.

• Sink Location: Leveraging subgraph isomorphism [7], LinkZard attempts to map the formalized API sequence of a known sink (from Finding 2) to a subgraph within the FOPG. A depth-first traversal explores operation sequences. To mitigate false negatives caused by extraneous interleaved operations, the mapping strategy is relaxed: successor nodes of a matched sink node are flexibly matched against multiple successor nodes in the FOPG. A successful match indicates the detection of an LFVuln.
• Constraint Location: After locating the sink, LinkZard traverses the FOPG to identify associated constraints. It recursively explores incoming edges to the sink to find predecessor nodes (N) whose operation target (Od) corresponds to a file previously marked as having an existing state constraint (from the exploration phase). Such nodes indicate pre-sink constraints. For on-sink constraints, LinkZard checks each node N within the sink itself; if its Od corresponds to a file with an existing state constraint, it's an on-sink constraint.

State-Specific Code Wrapping

This final process generates the exploitation code based on the identified sink and constraint types. The approach focuses on constraint types rather than specific operations, enhancing adaptability.

1. Information Extraction: File state information (file name, path) is extracted from the located sink and constrained files. Sink operation target states are used for OpLock code, while constrained file states are used for pseudo-symbolic link code.
2. Wrapping Strategies:

• Pre-sink constraints: The wrapping strategy first generates a file satisfying the state constraints (replicating the marked file from exploration). Then, it assembles the pseudo-symbolic link exploitation code using the target file's name and path from the sink operation. This involves creating a directory junction to a writable namespace (e.g., \RPC Control) using the extracted path, and then creating an ObjSymlink within that namespace using the extracted file name, pointing to the victim_file. Figure 5a in the paper illustrates this for FoxitPDF.
• On-sink constraints: This strategy also starts by generating a file satisfying the state constraints. Crucially, it then combines this file name and path to set an OpLock on the constrained file. This OpLock ensures the privileged program temporarily halts, providing a stable window for the attacker to create the pseudo-symbolic link (similar to the pre-sink strategy) using the state of the sink operation’s target file. Once the OpLock is released, the program resumes and completes the vulnerable operations. Figure 5b in the paper illustrates this for the W** service.

The assembled code is then compiled and executed to achieve LFVuln exploitation. If exploitation fails, LinkZard updates file states and returns to the exploration phase.

Demo / Proof of Concept

While the paper does not describe a live demonstration, LinkZard’s effectiveness in demonstrating and exploiting LFVulns is thoroughly detailed through its evaluation against known vulnerabilities and the discovery of numerous zero-day flaws. The "Demo / Proof of Concept" aspect is covered by the automated exploitation capabilities and the two specific case studies provided.

LinkZard's State-Specific Code Wrapping process serves as its automated proof-of-concept generator. As described in Section 4.3.3, LinkZard extracts critical state information from identified sinks and constraints, then intelligently assembles exploit code. For example, in the case of pre-sink constraints, it first generates a file that meets the necessary state conditions. Subsequently, it constructs a directory junction from the target file's path to a writable Object Manager namespace like \RPC Control, and within that namespace, creates an ObjSymlink pointing to an arbitrary victim_file. This entire sequence is then compiled and executed.

For on-sink constraints, LinkZard's generated exploit code is more intricate. It still begins by satisfying the file state constraints. However, it then integrates an Opportunistic Lock (OpLock) on the constrained file. This OpLock momentarily pauses the privileged program, creating a stable time window during which LinkZard rapidly sets up the pseudo-symbolic link (directory junction and ObjSymlink) to redirect the vulnerable operation to the victim_file. Once the OpLock is released, the privileged program proceeds to operate on the now-redirected path, achieving the desired arbitrary file manipulation. This dynamic, race-condition-aware exploitation highlights LinkZard's advanced capabilities.

Two specific case studies exemplify LinkZard's ability to demonstrate LFVulns:

• Case A: Microsoft OfficePlus (CVE-2024-38*): LinkZard identified an LFVuln in the OfficePlusService. This service queries the size of MSOfficePLUSService.log and, if it exceeds a threshold, rotates log files (e.g., MSOfficePLUSService1.log to MSOfficePLUSService10.log) before deleting the original MSOfficePLUSService.log. The deletion operation contained a sink. LinkZard's file state mutators (targeting file size and name similarity) successfully triggered the vulnerability. Through automated code wrapping, LinkZard exploited this to achieve arbitrary file deletion, leading to Local Privilege Escalation (LPE)**. This vulnerability was reported to MSRC and received a CVE and bounty.

• Case B: Commercial Software Infrastructure M (CVE-2024-9): LinkZard uncovered a vulnerability in a WAF-related infrastructure component used across multiple commercial applications from a leading IT operations management software provider. This component periodically checks C:\Windows\Temp\waf_fileupload for malicious JSP files and performs insecure deletion if found. LinkZard used directory query feedback to perform file state fuzzing, successfully triggering the vulnerability and enabling Local Privilege Escalation (LPE). The vendor confirmed that over 10 internal commercial applications reused this vulnerable component, amplifying its severity.

These cases demonstrate LinkZard's practical utility in not only detecting but also automatically generating working exploits for complex LFVulns in real-world, widely deployed software.

Defensive Implications

The findings from this research provide crucial insights for developers and security teams to defend against Link Following Vulnerabilities (LFVulns). The paper highlights two main mitigation approaches, along with lessons learned from LinkZard's false positive analysis:

1. Redirection Guard [53]: Introduced by Microsoft in Windows, this process-level mitigation aims to prevent privileged programs from following insecure symbolic links. When enabled, it acts as a protective barrier, stopping unauthorized redirections during file operations. However, its adoption is limited as it is only applicable to Windows 11 22H2 and later versions, making it incompatible with applications that need to maintain broader version compatibility with older Windows installations. Defenders should evaluate if their critical applications can leverage this feature, especially for new deployments or updates targeting modern Windows environments.

1. Strict Access Control [58]: This is the most commonly recommended and widely applicable mitigation. Developers must enforce stringent access control policies (ACLs) on all directories and files involved in file operations, particularly those that might be created or modified by privileged programs. By ensuring that low-privileged users cannot create or modify files in sensitive locations, or cannot control the targets of symbolic links, attackers are prevented from manipulating system files arbitrarily. This involves careful permission reviews for temporary directories, log file locations, and any paths where privileged operations occur.

Beyond these primary mitigations, LinkZard's false positive analysis in Section 5.3 offers additional defensive guidance:

• Custom Defenses for Symbolic Links: Some applications implement their own checks to determine if a file is a symbolic link before performing sensitive operations. This proactive validation, if implemented correctly, can effectively mitigate LFVulns. Developers should consider integrating explicit symbolic link validation into their code, particularly for operations involving file deletion, creation, copying, or access control modification on paths that could be influenced by a low-privileged user.
• Secure Coding Practices: The root cause of LFVulns is inadequate validation. This underscores the importance of secure coding practices, where every file operation in a privileged context should assume input (including file paths) could be malicious. Developers should adopt a "never trust user input" mindset, extending it to file system objects.
• Regular Security Audits and Fuzzing: The discovery of 55 zero-day vulnerabilities in widely used software by LinkZard demonstrates that LFVulns are prevalent. Organizations should incorporate automated tools like LinkZard, or at least the principles behind its file state fuzzing and sink detection, into their security development lifecycle (SDL) and regular penetration testing. This proactive approach can identify and remediate vulnerabilities before they are exploited in the wild.

In summary, a multi-layered defense strategy combining OS-level mitigations where applicable, robust access control, explicit symbolic link validation in code, and continuous security testing is essential to protect against the pervasive threat of LFVulns.

Key Takeaways

• Pervasive Threat: Link Following Vulnerabilities (LFVulns) are widespread in Windows systems, impacting critical applications and foundational services from major vendors due to inadequate symbolic link validation.
• Automated Detection & Exploitation: LinkZard is the first automated tool capable of both detecting and exploiting LFVulns by systematically addressing complex file state constraints and identifying high-risk file operation sequences (sinks).
• Novel Fuzzing & Graph Analysis: LinkZard's innovation lies in its feedback-driven file state fuzzing (using kernel-level hooks and Z3-based mutations) and its use of File Operation Primitive Graphs (FOPGs) with subgraph isomorphism for precise sink location.
• Significant Real-World Impact: LinkZard successfully identified and exploited 55 zero-day LFVulns across 120 commercial programs, leading to 15 CVE assignments and numerous bug bounties, confirming the practical severity and prevalence of these flaws.
• Constraint-Aware Exploitation: The tool's state-specific code wrapping, which dynamically handles both pre-sink and on-sink constraints (including the use of Opportunistic Locks for race conditions), demonstrates a sophisticated approach to automated exploit generation.
• Defensive Imperatives: Mitigations include leveraging Microsoft's Redirection Guard (for newer Windows versions), enforcing strict access control policies on sensitive directories, and implementing custom symbolic link validation checks within applications.

About the Speaker(s)

The research presented in this paper, "Pig in a Poke: Automatically Detecting and Exploiting Link Following Vulnerabilities in Windows File Operations," was conducted by a team of researchers from Fudan University. The authors, Bocheng Xiang, Yuan Zhang, Fengyu Liu, Hao Huang, Zihan Lin, and Min Yang, are affiliated with this institution, indicating their expertise and contributions to the field of software security.