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

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

Speakers: Bocheng Xiang (Bin), FA University

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=IvePAyTRtLA

Overview

This talk, "Pig in a Poke," presented by Bocheng Xiang (Bin) from FA University, delves into the critical and pervasive issue of link following (LF) vulnerabilities in Windows file operations. These vulnerabilities arise when privileged applications interact with symbolic links without proper validation, inadvertently redirecting sensitive operations to protected files or system resources under elevated privileges. The research introduces Linkard, an innovative automated system designed to detect and exploit these elusive flaws, which have historically been challenging to identify due to complex file state dependencies and the precise timing required for exploitation.

The significance of this work lies in its comprehensive empirical study of past LF vulnerabilities, revealing key patterns and obstacles to automation. Linkard addresses these challenges by employing a two-phase approach encompassing intelligent exploration of file operations and sophisticated exploitation techniques. By automating the discovery and exploitation of these vulnerabilities, Linkard demonstrates a powerful capability to uncover critical security flaws, leading to numerous zero-day discoveries, CVE assignments, and significant bug bounty rewards across a wide array of popular commercial and system-level software.

The presentation highlights that LF vulnerabilities are not merely theoretical concerns but represent a widespread and often overlooked class of security risks capable of leading to denial of service (DoS) and local privilege escalation (LPE). Through its systematic methodology, Linkard provides a much-needed tool for enhancing the security posture of Windows systems and applications, offering a blueprint for both researchers and developers to better understand, detect, and mitigate these complex attack vectors.

Background

▶ Watch: Introduction to symbolic links and OpLocks (0:00)

The foundation of link following (LF) vulnerabilities in Windows systems stems from the operating system's extensive use of symbolic links and the powerful, yet often misused, opportunistic lock (oplock) mechanism. Windows supports several types of symbolic links, even for low-privileged users, which are crucial for understanding this attack surface. Two primary types are particularly relevant:

1. Directory Junctions: These symbolic links map one directory path to another. A low-privileged user can create a directory junction that, for example, points a temporary directory to a system-critical directory like C:\Windows\System32.
2. Object Manager Symbolic Links: These links operate within the Windows Object Manager namespace and can reference not only files and directories but also devices. By combining directory junctions with object manager symbolic links, an attacker can construct a link that ultimately points to virtually any arbitrary file on the system, even those typically inaccessible to a low-privileged user.

The second critical component enabling these attacks is the opportunistic lock (oplock). Oplocks are a client-side caching mechanism primarily used by network file systems to improve performance. However, a local user can also request an oplock on a file. When a process attempts to access a file protected by an oplock, the oplock holder receives a callback and can delay the operation, creating a brief but crucial window of opportunity. An attacker can leverage this delay to atomically replace a legitimate file or symbolic link with a malicious one, redirecting subsequent privileged operations.

The standard link following attack unfolds in three distinct steps:

1. An attacker creates malicious symbolic links designed to point to protected files or resources.
2. A privileged application performs a file operation on what it believes to be a benign file, but it's actually the attacker-controlled symbolic link, without proper validation.
3. The operation is transparently redirected to the protected file, executing under the elevated privileges of the vulnerable application. This can result in unauthorized access, modification, or deletion of sensitive system components.

These vulnerabilities primarily lead to two categories of security risks:

• Denial of Service (DoS): An attacker might cause a privileged application to delete or corrupt critical system files, rendering the system unstable or inoperable.
• Local Privilege Escalation (LPE): By tricking a privileged process into writing to a protected location (e.g., an executable in Program Files or a configuration file in System32), an attacker can introduce malicious code or alter system behavior to gain elevated privileges.

The talk illustrates this with a real-world example of an arbitrary file delete vulnerability. Imagine an application that exposes an Inter-Process Communication (IPC) method, cleanTempFile, callable by any user. Internally, this method scans the system's temporary directory for files ending in .tmp and deletes them.

An attacker can exploit this as follows:

1. The attacker creates a file named attack.tmp in the temporary folder and places an oplock on it.
2. When cleanTempFile is invoked and attempts to open attack.tmp, the oplock triggers, delaying the deletion operation.
3. During this brief delay, the attacker replaces attack.tmp with a symbolic link pointing to an arbitrary, protected file (e.g., C:\Windows\System32\some_critical_file.dll).
4. The attacker then releases the oplock.
5. As soon as the oplock is lifted, the privileged process resumes, follows the newly installed symbolic link without validation, and deletes the protected file under its elevated privileges. This precise timing, facilitated by oplocks, is often the lynchpin of successful LF exploits.

Key Findings

▶ Watch: Analysis of 145 link following vulnerabilities (3:20)

The research embarked on a comprehensive empirical study of 145 link following (LF) vulnerabilities reported over five years, yielding crucial insights into their prevalence, root causes, and the challenges associated with their automated detection and exploitation. This study formed the bedrock for designing the Linkard system.

One of the most striking findings concerned the root cause of these vulnerabilities. The analysis revealed that the vast majority of LF vulnerabilities stemmed from a fundamental failure to properly validate symbolic links during file operations. Privileged applications often assume they are operating on concrete files or directories specified by a user, neglecting to check if an intermediate path component or the final target is a symbolic link that could redirect the operation.

The study also classified the types of dangerous operations that commonly lead to LF vulnerabilities:

• Unsafe Deletion: This emerged as the most prevalent vulnerability type, accounting for a staggering 46.8% of all cases. This aligns with the arbitrary file delete example, where a privileged process is tricked into deleting a critical system file.
• Unsafe Creation, Writing, and Overwriting: Collectively, these operations represented approximately one-third (around 33%) of the vulnerabilities. These scenarios allow an attacker to create files in arbitrary locations, inject malicious content into existing protected files, or overwrite them entirely.
• Unsafe Copying, Moving, and Access Control Misconfigurations: Each of these categories contributed about 9.7% of the total. Unsafe copying/moving can lead to sensitive files being moved to attacker-controlled locations or attacker-controlled files being moved into privileged locations. Access control misconfigurations, while slightly different, can sometimes be leveraged in conjunction with link following to achieve broader impact.

Beyond classification, the researchers probed the obstacles to automating detection and exploitation. They identified two major challenges:

1. Complex File State Constraints: Nearly half (approximately 46%) of all observed vulnerabilities were guarded by intricate file state constraints. This means that for an operation to become vulnerable, specific conditions regarding file names, attributes (e.g., hidden, read-only), sizes, or timestamps must be met. Existing automated tools, such as peach-fuzz or static analysis frameworks, struggle to dynamically infer and satisfy these evolving file state requirements, limiting their effectiveness in detecting LF vulnerabilities.
2. Identifying Process Insertion Points: For automated exploitation, it is critical to precisely identify the moments within a sequence of file operations where an attacker can interject malicious actions (e.g., replacing a file with a symbolic link using an oplock). Given M operations, the number of possible insertion points can be on the order of M^4, leading to exponential complexity if explored exhaustively. This makes brute-force approaches impractical for automated exploitation.

These empirical findings directly informed the design principles of Linkard, emphasizing the need for dynamic file state inference and a targeted approach to identify exploitable operation sequences rather than exhaustive exploration.

Technical Deep Dive

▶ Watch: Challenges in automating detection and exploitation (4:00)

The Linkard system is engineered to surmount the challenges of detecting and exploiting link following (LF) vulnerabilities by systematically separating the process into two distinct phases: exploration and exploitation. This modular design allows Linkard to efficiently uncover hidden file state constraints and precisely locate exploitable points within complex file operation sequences.

At a high level, Linkard operates as follows:

1. Exploration Phase: Linkard interacts with privileged processes, simulating low-privileged user behavior. It uses file state fuzzing to uncover and satisfy as many hidden file state constraints as possible, which are often prerequisites for triggering vulnerable operations.
2. Exploitation Phase: Based on the data collected during exploration, Linkard constructs a File Operation Primitive Graph (FOPG). It then performs subgraph matching to identify vulnerable "sinks" within this graph and determine the precise timing and conditions for exploitation. Finally, Linkard generates the necessary exploitation code.

Exploration Phase

The exploration phase is critical for understanding the target application's behavior and identifying the conditions under which it performs sensitive file operations.

1. IPC Call Generation and Input Mutation:

Linkard begins by understanding how a low-privileged user can interact with a privileged process. It achieves this by:

• Extracting RPC Interface and Definition from IDL Metadata: Windows applications often expose privileged functionality through Remote Procedure Call (RPC) interfaces, defined using Interface Definition Language (IDL). Linkard parses this IDL metadata to obtain detailed information about available methods (functions) and their parameter types. This provides a map of all potential entry points for a low-privileged attacker.
• Generating Necessary Parameters for IPC Calls: Based on the IDL definitions, Linkard intelligently generates parameters for these RPC calls. This includes recursively constructing nested structures for complex arguments, ensuring that the generated inputs are syntactically correct and can invoke the target interfaces.
• Invoking Privileged Interfaces: These generated inputs are then used to programmatically invoke the privileged interfaces, triggering various file operations and exploring different execution paths within the target application. This systematic invocation helps Linkard observe how the application processes different inputs and what file system interactions result.

2. File State Fuzzing:

The second key component of the exploration phase is file state fuzzing, designed to infer and solve the often-complex file state constraints that guard LF vulnerabilities.

• Instrumenting Key File State Query APIs: Linkard instruments critical Windows API calls that applications use to query the file system. These include functions that check file names, extensions, attributes (e.g., GetFileAttributes, FindFirstFile), or sizes. By monitoring these calls, Linkard captures the specific conditions (constraints) that the target application expects a file or directory to satisfy before performing a sensitive operation. For example, an application might only process files ending with .log or files with specific attributes.
• Applying Mutation Strategies: To infer these constraints and trigger different execution paths, Linkard applies a variety of mutation strategies to the file system state before invoking the privileged IPC calls. These strategies include:
• Varying file extensions (e.g., .tmp, .log, .dat).
• Renaming files.
• Altering file sizes.
• Manually manipulating file timestamps (creation, modification, access times).
• Changing file attributes (e.g., setting read-only, hidden, system flags).

Linkard records all resulting file operations after each mutation, tracking how the system reacts and which paths are taken.

• Validating Inferred Constraints: Linkard validates whether the inferred constraints have been successfully solved by observing changes in the target application's behavior. If a mutation leads to an increase in the number or types of file operations (especially those indicating sensitive actions like deletion or writing), it suggests that a previously unmet constraint has been satisfied, opening a new execution path for further analysis.

Exploitation Phase

Once the exploration phase has identified potential vulnerable paths and relevant file state constraints, the exploitation phase focuses on constructing the actual exploit.

1. Constructing the File Operation Primitive Graph (FOPG):

• From the sequences of file operations collected during exploration, Linkard builds a File Operation Primitive Graph (FOPG). This graph models the sequence and dependencies of individual file system primitives (e.g., CreateFile, ReadFile, WriteFile, DeleteFile, SetFileAttributes). The FOPG captures the flow of operations and how they interact with different files, providing a structured representation of the application's file system behavior.

2. Identifying Vulnerable Sinks via Subgraph Matching:

• Linkard identifies "vulnerable syncs" by performing subgraph matching on the FOPG. Vulnerable syncs are specific patterns of file operations known to be indicative of LF vulnerabilities. These patterns might involve a check for a file's existence followed by an operation on the same file, or a read operation followed by a write operation, where an attacker could interject a symbolic link. By focusing on these compact, high-impact subgraphs, Linkard avoids the exponential overhead of brute-force exploration for insertion points.

3. Analyzing Constraint Location:

• After locating a potential sync, Linkard analyzes whether the associated file state constraints are "pre-satisfied" or "on-sync."
• Pre-satisfied constraints are conditions that must hold before the vulnerable operation (sync) is reached. For example, a file must exist with a specific name before the application attempts to open it.
• On-sync constraints are conditions that must hold at the moment the sync operation is executed. This is where oplocks become crucial, allowing an attacker to enforce an on-sync constraint (e.g., replacing a file with a symlink) precisely when the privileged operation is about to execute.

4. Assembling Tailored Exploitation Code:

• Finally, Linkard assembles tailored exploitation code based on the type of identified vulnerability and the inferred constraints. This code typically involves:
• Setting up the initial file system state to satisfy pre-satisfied constraints.
• Creating an attacker-controlled file or directory.
• Setting an oplock on the attacker-controlled resource.
• Invoking the privileged IPC method that triggers the vulnerable operation.
• In the oplock callback, replacing the attacker-controlled resource with a malicious symbolic link pointing to the target protected file.
• Releasing the oplock to allow the privileged operation to proceed on the symbolic link.

This automated generation of exploit code significantly reduces the manual effort required for vulnerability validation and proof-of-concept creation.

Demo / Proof of Concept

▶ Watch: Linkard's exploration phase: IPC and file state fuzzing (8:00)

While the talk did not feature a live, real-time demonstration of Linkard actively discovering a new vulnerability, the researchers presented compelling evidence of the system's efficacy through its application to real-world software. This extensive validation serves as a robust proof of concept for Linkard's automated detection and exploitation capabilities.

Linkard was applied to a challenging dataset comprising 42 known link following (LF) vulnerabilities within 120 commercial closed-source programs, many with over 15,000 downloads. In this evaluation, Linkard achieved a 19.48% detection recall for known vulnerabilities and an impressive 84% exploitation success rate for those it identified. This indicates that while it may not catch every known variant, it is highly effective at creating working exploits for the vulnerabilities it does identify.

More significantly, Linkard demonstrated its ability to uncover previously unknown security flaws. The system identified 55 zero-day vulnerabilities across 49 different programs. Out of these, 15 have been assigned CVE identifiers, formally acknowledging them as real and impactful security issues by the security community. The financial recognition further underscores their severity, with 25 of these vulnerabilities being acknowledged with over $13,000 in bug bounty rewards.

These discoveries span a wide range of high-impact software ecosystems, illustrating the pervasive nature of LF vulnerabilities:

• Popular Commercial Applications: Linkard found flaws in software with over 5 million downloads, including Tencent Meeting, Enterprise WeChat, and Foxit PDF. These are widely used applications where a privilege escalation could have significant consequences for millions of users.
• Critical System Components: The system also uncovered vulnerabilities in fundamental Windows components, such as the Floating Default Window Service and Intel driver-level middleware. Exploits in these areas could grant attackers deep system control.
• Major Vendors: Linkard identified previously unknown LF vulnerabilities in products from leading technology vendors, including Microsoft, Apple, Intel, JetBrains, and VMware. This highlights that even products from companies with sophisticated security teams are susceptible to these complex, often overlooked, issues.

The sheer volume and impact of these discoveries—ranging from consumer software to enterprise platforms and critical system components—provide a powerful proof of concept for Linkard. It demonstrates that the system is not merely a theoretical construct but a practical, effective tool capable of automatically finding and exploiting a class of vulnerabilities that has historically been difficult to tackle manually.

Defensive Implications

▶ Watch: Linkard's exploitation phase: FOPG construction (10:00)

The insights and capabilities demonstrated by Linkard offer crucial guidance for both software developers and system administrators seeking to defend against link following (LF) vulnerabilities. The core message is clear: applications performing file operations under elevated privileges must adopt a "trust nothing" approach, especially when dealing with paths influenced by unprivileged users.

For developers, the primary defensive implication revolves around rigorous symbolic link validation:

• Validate All Path Components: Before performing any sensitive file operation (creation, deletion, writing, copying, moving, or even just opening for access), privileged applications must not only validate the final target path but also every intermediate component of the path. Each component should be checked to ensure it is not a symbolic link, directory junction, or mount point that could redirect the operation.
• Use Secure File Operation APIs: Where possible, developers should leverage Windows APIs designed with security in mind, which implicitly handle some of these validations or offer flags to prevent link following. However, relying solely on these might not be sufficient, as custom logic often introduces new vulnerabilities.
• Principle of Least Privilege: Applications should always operate with the absolute minimum privileges required for their function. If a component does not need elevated privileges to interact with certain files, it should not have them.
• Avoid OpLock Triggers: Developers should be acutely aware of how their applications interact with files and how those interactions might trigger opportunistic locks (oplocks). Operations that open files in ways that grant oplock control should be carefully reviewed, especially when user-controlled paths are involved.
• Input Sanitization: While not directly preventing link following, robust input sanitization for all user-supplied paths and file names can help reduce the attack surface by preventing path traversal or other related issues.
• Secure Temporary File Handling: Given the prevalence of temporary file-related LF vulnerabilities (as highlighted by the cleanTempFile example), developers must implement secure practices for handling temporary files. This includes creating temporary files in secure, isolated directories with strict permissions and ensuring unique, unpredictable names.

For system administrators and security teams, the implications include:

• Patch Management: Regularly applying security patches and updates from vendors (including those for vulnerabilities found by Linkard, like the 15 CVEs) is paramount. Many LF vulnerabilities are patched discreetly, and keeping systems up-to-date is the first line of defense.
• Endpoint Detection and Response (EDR) Systems: EDR solutions can be configured to monitor for suspicious file system activities, such as rapid creation and deletion of symbolic links followed by privileged operations on unusual file paths. While challenging to distinguish from legitimate activity, behavioral analysis can help.
• Application Whitelisting: Implementing application whitelisting can prevent unauthorized executables from running, even if an attacker manages to achieve arbitrary file write through an LF vulnerability.
• User Education: Educating users about the risks of running untrusted software or opening suspicious files can reduce the initial infection vector that might lead to local privilege escalation attempts.
• Hardening Configurations: Reviewing and hardening default Windows configurations, especially around temporary directories and service accounts, can reduce the attack surface.

In essence, the detection of numerous zero-day LF vulnerabilities in widely used software underscores that this is an ongoing battle. Developers must integrate security-by-design principles, specifically focusing on the intricate dance between privileged operations and user-controlled file paths, while security teams must remain vigilant with patching and monitoring.

Key Takeaways

• Pervasive and Underestimated Threat: Link following (LF) vulnerabilities are widespread in Windows applications, impacting popular commercial software, system components, and products from major vendors, often leading to denial of service (DoS) or local privilege escalation (LPE).
• Root Cause: Insufficient Validation: The majority of LF vulnerabilities stem from privileged applications failing to properly validate symbolic links or their path components when performing file operations on user-controlled inputs.
• Oplocks are Key Enablers: Opportunistic locks (oplocks) are frequently leveraged by attackers to create precise timing windows, allowing for the atomic replacement of legitimate files with malicious symbolic links during privileged operations.
• Automated Detection is Challenging but Achievable: Overcoming complex file state constraints and precisely identifying attacker insertion points are the main obstacles to automated LF vulnerability detection and exploitation. Linkard successfully addresses these through file state fuzzing and subgraph matching on File Operation Primitive Graphs (FOPG).
• Linkard's Proven Efficacy: The Linkard system demonstrated significant real-world impact by discovering 55 zero-day vulnerabilities across 49 programs, leading to multiple CVEs and over $13,000 in bug bounty rewards.
• Defensive Imperatives: Developers must implement rigorous symbolic link validation, use secure file operation APIs, and adhere to the principle of least privilege. System administrators should prioritize patch management and implement advanced monitoring for suspicious file system activity.

About the Speaker(s)

The research presented in "Pig in a Poke" was given by Bocheng Xiang, also known as Bin, from FA University. The talk highlights his expertise in system security and automated vulnerability discovery, particularly within the complex landscape of Windows operating systems. His work focuses on developing innovative techniques and tools to identify and exploit challenging classes of vulnerabilities, contributing significantly to the understanding and mitigation of security risks in widely used software.