Full Report
Windows Subsystem for Linux Plan 9 Protocol Research Overview This is the final blog in the McAfee research series trilogy... The post Hunting for Blues – the WSL Plan 9 Protocol BSOD appeared first on McAfee Blog.
Analysis Summary
# Research: Windows Subsystem for Linux Plan 9 Protocol Research Overview
## Metadata
- Authors: Not explicitly named in the provided text, but attributed to McAfee research series.
- Institution: McAfee Labs / Advanced Threat Research (ATR)
- Publication: McAfee Blogs (Part of a trilogy series)
- Date: Not explicitly provided (Context suggests a post-dates the beginning of WSL P9 support in Win 10 v1903 and subsequent vulnerability disclosure/patching).
## Abstract
This research investigates the implementation of the Plan 9 File System Protocol (P9) server within the Windows kernel concerning the Windows Subsystem for Linux (WSL). By hijacking the legitimate Microsoft P9 server that facilitates access to Linux files from Windows hosts, the researchers explored the feasibility of triggering kernel-level faults. The primary outcome was the discovery of a local Denial of Service (DoS) vulnerability leading to a Blue Screen of Death (BSOD) in the Windows kernel when triggered by a malicious P9 server reply. Crucially, the findings indicate that this specific vulnerability does not allow for local privilege escalation (EoP).
## Research Objective
The main objective was to explore the P9 protocol implementation within the Windows kernel—specifically utilized by WSL for Linux filesystem access—and determine if code could be executed or vulnerabilities exploited through a malicious P9 server that replaces the legitimate Microsoft P9 server. A secondary goal was to document the vulnerability hunting process within this relatively undocumented communication stack.
## Methodology
### Approach
The core methodology involved creating a malicious P9 server by hijacking the legitimate P9 server socket ("fsserver") connection utilized by WSL. The researchers then crafted malformed P9 response packets (R-messages) to test the kernel's resilience, focusing on memory corruption vulnerabilities like out-of-bounds reads/writes or message type confusion.
### Dataset/Environment
The study was conducted on Windows 10 operating systems (specifically noting support since version 1903 where P9 access to Linux files became standard). The environment included an enabled WSL instance and a local attacker with non-privileged access.
### Tools & Technologies
The research involved deep analysis of the P9 protocol structure (T-messages and R-messages) and tracing the execution flow within the Windows kernel components responsible for handling P9 communications, including functions like `ProcessReadReply` and associated context handlers (e.g., `Lambda_2275`, `SyncContextErrorCallback`).
## Key Findings
### Primary Results
1. **Local DoS/BSOD Achievable:** A non-privileged local attacker who successfully hijacks the P9 server socket can cause a Denial of Service (DoS) condition, resulting in a Blue Screen of Death (BSOD) in the Windows kernel.
2. **No Local Privilege Escalation (EoP):** Despite crashing the kernel, the observed BSOD appears to be a designed fail-safe (legitimate fail flow) by Microsoft when malformed P9 packets are received. The vulnerability does not permit achieving escalation of privilege within the Windows kernel.
3. **Prerequisite for Attack:** The attack requires the attacker to hijack the P9 communication channel, which by default requires WSL to be enabled. If WSL is disabled, an attacker must first possess privileged access to enable the feature before executing the attack.
### Supporting Evidence
- Tracing of the kernel code paths, such as `ProcessReadReply`, revealed checks (e.g., limiting the `count` field size to 0x8000) designed to prevent memory corruption during data movement (`memmove`) into kernel structures (MDLs) from the untrusted packet data. The crash appears to occur when these checks fail to catch an issue or when the resulting failure triggers a controlled system halt.
### Novel Contributions
- This research represents the first documented deep dive into the P9 protocol implementation vulnerability hunting within the Windows 10 WSL communication stack, differentiating it from prior research focused elsewhere in the WSL ecosystem.
## Technical Details
The P9 protocol communication relies on T-messages (requests) and R-messages (replies) with a fixed header structure containing `size`, `type`, and `tag`. Vulnerability hunting focused on the variable-sized fields following this header, such as those in `p9_rwalk`, `p9_rread`, and `p9_rversion` structs. The researchers specifically analyzed how the kernel handles oversized or malformed replies, such as the `count` field in an RREAD message, which is copied into kernel memory buffers (MDLs) via `memmove` after an initial size check ($\le 0x8000$). The kernel fails unexpectedly when processing the malicious R-message replies sent by the hijacked server.
## Practical Implications
### For Security Practitioners
- Understanding that the WSL P9 channel represents a complex, kernel-interacting attack surface that can be leveraged locally for DoS.
### For Defenders
- **Mitigation:** The primary defense strategy is detecting and preventing the hijacking of the P9 server socket, referred to as "fsserver." If this socket cannot be compromised by a local attacker, the DoS vulnerability cannot be triggered.
### For Researchers
- The research suggests that further investigation should target the layers *higher up* the WSL communication stack, as the P9 implementation itself appears to have basic defenses against outright memory corruption leading to execution.
## Limitations
- The exploit is strictly **Local**. It requires the attacker to already have a presence on the workstation.
- The vulnerability found only results in a **Denial of Service (DoS)** (BSOD) and could not be leveraged for Local Privilege Escalation (EoP) or remote code execution.
## Comparison to Prior Work
Previous research focused on other aspects of WSL vulnerabilities, such as general file evasion attacks or privilege escalation through different mechanisms. This work distinguishes itself by being the first known detailed vulnerability analysis specifically targeting the kernel-side handling of the P9 protocol used for filesystem communication between WSL and the Windows host.
## Real-world Applications
- **Attack Scenario:** A non-privileged local user (e.g., malware already running under a standard user context) on a machine with WSL enabled could leverage this to crash the operating system, causing disruption.
- **Implementation Considerations:** Exploitation relies entirely on the attacker's ability to compromise the connection endpoint used by the legitimate P9 server integration.
## Future Work
- Further research is encouraged further up the WSL communication stack, as this area presents increasing complexity due to the virtualized Linux filesystem integration.
- Exploring if the observed BSOD fail flow can be manipulated into achieving actual code execution rather than just a controlled crash.
## References
- Related Research (WSL exploits): Links provided in the original text regarding previous WSL exploits.
- P9 Protocol Documentation: Link to the Plan 9 File System Protocol documentation.
- Related McAfee Blogs: Links to "The Twin Journey" and "Knock, Knock–Who’s There?" discussing related WSL/P9 topics.