Auspex: Unveiling Inconsistency Bugs of Transaction Fee Mechanism in Blockchain

Exploring and Exploiting the Resource Isolation Attack Surface of WebAssembly Containers

Speakers: Zhaofeng Yu, Dongyang Zhan, Lin Ye, Haining Yu, Hongli Zhang (Harbin Institute of Technology); Zhihong Tian (Guangzhou University)

Conference: USENIX Security

YouTube: https://www.usenix.org/conference/usenixsecurity25/presentation/yu-zhaofeng

Overview

This article delves into the critical security vulnerabilities present in WebAssembly (Wasm) runtimes, specifically focusing on their resource isolation attack surface. Authored by Zhaofeng Yu and a team of researchers from Harbin Institute of Technology and Guangzhou University, the paper highlights that despite Wasm's design for secure sandboxing and its reputation as a more secure container technology than Docker, its current implementations in widely used runtimes like Wasmtime and Wasmer are susceptible to resource exhaustion attacks. These attacks, leveraging the WebAssembly System Interfaces (WASI) and WASIX extensions, can severely degrade host system performance and disrupt other Wasm instances.

The research systematically explores how malicious Wasm modules can exploit these interfaces to consume vast amounts of system resources, not only directly but also by injecting workloads into underlying operating system components. The authors propose novel static analysis techniques tailored for Rust-based Wasm runtimes to identify these vulnerabilities and develop practical exploitation strategies. This work is significant because it uncovers a previously under-explored attack surface in a rapidly evolving technology, demonstrating that Wasm's promise of robust isolation is not fully realized in practice.

The findings underscore the urgent need for enhanced resource management and fine-grained security mechanisms within Wasm ecosystems. As Wasm expands its footprint from web browsers to critical server-side, IoT, and cloud-edge computing environments, understanding and mitigating these resource isolation vulnerabilities becomes paramount to maintaining the integrity and availability of systems relying on Wasm containerization.

Background

The landscape of virtualization technologies has seen continuous evolution, from traditional virtual machines (VMs) offering strong isolation at the expense of overhead, to Linux containers (e.g., Docker) providing lightweight and flexible deployment by sharing the host kernel. WebAssembly (Wasm) represents the next generation, promising platform-independent execution with near-native speeds across diverse environments, from browsers to servers. Wasm achieves this through a portable binary instruction format that serves as a compilation target for various programming languages. Unlike Docker, which relies on Linux kernel features like Namespaces and Cgroups for isolation, Wasm modules execute within a Wasm runtime, which is responsible for enforcing security mechanisms such as linear memory, type checking, and protected call stacks.

Initially designed for web applications, Wasm's versatility has led to its adoption in critical server-side and edge computing scenarios, where its lightweight nature and cross-platform capabilities are highly valued. However, Wasm instructions themselves lack direct access to operating system functionalities. To bridge this gap, the WebAssembly System Interfaces (WASI) provide a standardized set of APIs, enabling Wasm modules to interact with underlying system resources like the file system. WASIX is an extension of WASI, offering richer functionality. Wasm runtimes like Wasmtime and Wasmer implement these interfaces, embedding strict validation logic to enforce isolation—for instance, by restricting file system access to specified directories.

Despite these security-conscious designs, the authors observed that resource isolation in widely used Wasm runtimes is often insufficient, sometimes even weaker than Docker's. The WASI/WASIX interfaces, while intended to be a controlled gateway to system resources, inadvertently expose an attack surface that can be exploited for resource exhaustion. Prior research has explored resource availability issues in traditional container and VM environments, demonstrating how attackers can bypass isolation to exhaust host resources and launch denial-of-service (DoS) attacks. However, a systematic exploration and measurement of this attack surface within the Wasm context, particularly concerning how attackers can leverage WASI/WASIX to break resource isolation, had not been thoroughly investigated before this work. The inherent difficulty in analyzing Rust projects, which form the basis of many Wasm runtimes, due to challenges in Intermediate Representation (IR) extraction, assembly code handling, and extensive indirect calls, further complicated prior research efforts.

Key Findings

The research yielded several significant findings regarding the resource isolation vulnerabilities in WebAssembly runtimes:

1. Systematic Attack Surface Measurement: The paper introduces a novel, systematic approach to explore the resource isolation attack surface of Wasm runtimes. This involved developing a specialized static analysis framework designed to overcome the challenges posed by Rust-specific features in Wasmtime and Wasmer, such as complex IR extraction, embedded assembly code, and extensive indirect calls (Section 3). This is presented as the first static analysis approach tailored for Rust-specific features, and its prototype has been open-sourced.

1. Identification of Vulnerable WASI/WASIX Interfaces: Through their static analysis, the researchers identified specific WASI/WASIX interfaces in Wasmtime and Wasmer that, when invoked by a malicious Wasm instance, can lead to significant resource consumption and performance degradation. These interfaces are related to file systems, I/O operations, and networking (Table 1).

1. Novel Exploitation Strategies: The study proposes several exploitation strategies categorized into two main types (Section 4):

• Direct Resource Consumption: Malicious Wasm instances can directly exhaust host resources like CPU cycles, disk space, I/O bandwidth, and network bandwidth.
• Indirect Workload Injection: Critically, attackers can exploit Wasm runtime or system mechanisms to inject workloads into other components of the underlying operating system. This makes the resource consumption difficult to attribute directly to the malicious Wasm instance, thereby bypassing traditional resource control mechanisms like Cgroups.

1. Demonstrated Impact on Host Systems: Extensive experiments on Wasmtime 24.0.0 and Wasmer 4.3.2 confirmed the effectiveness of these strategies (Section 5). Attacks led to:

• Severe I/O Degradation: File synchronization operations (fsync, fdatasync, statx with AT_STATX_SYNC_AS_STAT) reduced file read/write performance by over 93% and 99% respectively in Wasmtime, with similar impacts in Wasmer. File creation/deletion also caused over 98% I/O degradation.
• CPU Overhead to OS Components: Many attacks, especially those involving frequent small I/O operations or data synchronization, induced significant CPU load (e.g., 10-40%) on the underlying operating system components, which was not accounted for by the Wasm instance's process.
• Resource Exhaustion of Critical Kernel Resources: Malicious Wasm instances could deplete the system's entropy pool via /dev/random (91.93% decrease in generation rate in Wasmtime) and exhaust the limited number of file descriptors for pseudo-terminals (/dev/ptmx), leading to DoS attacks on SSH connections and new shell creations.
• Network Bandwidth Monopolization: Wasmer's network interfaces allowed malicious instances to monopolize network bandwidth or introduce significant kernel processing overhead through frequent small packet transmissions (up to 12% extra CPU overhead for UDP).

1. Limitations of Existing Defenses: The research clearly demonstrated that current resource limitation mechanisms, such as Wasmtime's "fuel" or Linux Cgroups, are often insufficient to mitigate these attacks, particularly those that inject workloads into other system components (Section 4, Section 6).

1. Discussion of Mitigation Strategies: The paper discusses potential defense mechanisms, including XFS for disk/inode limits, Cgroups (with caveats), syscall interposition (frequency or learning-based), and eBPF for fine-grained kernel resource monitoring, while acknowledging their respective challenges and limitations (Section 6).

Technical Deep Dive

The core of this research lies in its systematic approach to identifying and exploiting resource isolation vulnerabilities in Wasm runtimes. This involved a sophisticated static analysis framework designed specifically for Rust projects, followed by the development of targeted exploitation strategies.

Static Analysis Framework

The authors developed a three-stage static analysis framework to explore the attack surface: IR extraction, CFG construction, and critical interface identification (Figure 2).

1. IR Extraction Stage:

• Rust IR Generation: A custom tool was developed to extract complete project-level Intermediate Representation (IR) from Rust projects. This involved customizing the build process to apply link-time optimization (LTO), forcing the rustc and clang compilers to output bytecode instead of machine instructions. All bytecode is then merged into the final binary, and the tool extracts this merged bytecode as a complete IR file. Optimization is disabled during this process to maintain semantic consistency. This approach works without modifying source code, avoiding symbol conflicts and inter-module dependency issues.
• Assembly Transformer: Embedded assembly code blocks, which are unstructured in IR and disrupt control flow analysis, are transformed. The framework compiles assembly blocks into binary object files, uses decompilation tools to convert them into high-level language representations, adjusts the generated code for compatibility, and then recompiles it into standardized LLVM IR, which is integrated into the global IR.

1. CFG Construction Stage:

• Precise Control Flow Graph (CFG) Construction: The complete IR is used to construct accurate CFGs.
• Rust-specific Indirect Call Resolution: A major challenge in Rust projects is the prevalence of indirect calls due to features like dynamic dispatch (trait objects) and asynchronous mechanisms (async/await, .await calls generating poll methods). Traditional type-based analysis often yields imprecise results due to highly similar function signatures in Rust.
• The proposed two-step approach first identifies and records vtables by analyzing global object properties in the IR.
• Second, at each indirect call site, data flow analysis identifies the source of the call. If it's dynamic dispatch, the source's type information is matched with recorded vtables. If it's an asynchronous mechanism, backward data-flow analysis traces the pointer source. For other types, type-based analysis is used. This process is iterative, resolving dependencies between indirect calls.
• For generic functions, which are not Rust-specific, state-of-the-art type-based methods like MLTA [29, 28] are used, acknowledging the inherent challenge of over-approximation in static analysis for such cases.

1. Critical Interface Identification Stage:

• Accessible Syscalls/APIs Analysis: WASI/WASIX interfaces are used as entry points. The framework traverses all possible call chains from these entry points to identify all potential syscalls or external APIs.
• Program Slicing and Taint Analysis: For each identified syscall or API, a program slice describes the execution path. Static taint analysis determines if interface parameters directly or indirectly influence syscall/API parameters. Backward data-flow analysis traces argument origins. Specific syscall numbers (e.g., for syscall()) and sensitive argument values are identified.

This systematic analysis enabled the researchers to determine, for each WASI/WASIX interface, the possible syscalls and external APIs it invokes, along with parameter relationships. The analysis of Wasmtime and Wasmer completed in 47 minutes and 33 seconds, demonstrating its efficiency.

Exploitation Strategies

Based on the analysis, two categories of exploitation strategies were developed (Section 4):

1. Direct Resource Consumption:

• CPU Exhaustion: Malicious Wasm instances execute compute-intensive tasks. While Wasmtime has a "fuel" mechanism, it's not suitable for long-running server applications.
• Disk I/O Exhaustion: Creating large files, continuously writing data, or creating a massive number of small files to consume inode resources. This can lead to system instability and DoS.
• Memory Consumption: While Wasm's linear memory limits single instance memory (typically 4GB), multiple malicious instances can collectively exhaust host memory.
• Network Bandwidth Monopolization: Continuously transmitting large volumes of data via network interfaces (e.g., sock_send, sock_sendto in Wasmer).

1. Injecting Workloads into System/Runtime Components: These attacks are covert and bypass typical Wasm instance resource limits.

• Kernel Resource Exhaustion:
• Depleting the system entropy pool by continuously reading from /dev/random.
• Exhausting pseudo-terminal file descriptors by opening many /dev/ptmx files, preventing new shells or SSH connections.
• I/O Synchronization Overheads: Invoking fsync and fdatasync (Wasmtime) or statx with AT_STATX_SYNC_AS_STAT (Wasmer) to force metadata and content synchronization from cache to disk. These operations generate significant disk I/O overhead without necessarily high CPU usage by the Wasm instance itself.
• Frequent I/O/Network Operations: Even small data operations, when performed at high frequency, can trigger excessive context switching and interrupts, imposing significant CPU load on the kernel and degrading overall system performance.
• Wasm Runtime Workload Injection: Invoking WASI/WASIX interfaces with logging capabilities to make the Wasm runtime consume host I/O resources by generating excessive log entries.
• Multithreading Amplification: Using multithreading interfaces (e.g., pthread_create) to accelerate resource consumption, gain resource-grabbing advantages, and impose additional pressure on the underlying operating system kernel.

Table 1 summarizes the key syscalls and APIs identified in Wasmtime and Wasmer, revealing their dependencies:

• Wasmtime: openat, unlinkat, fsync, fdatasync, readv, writev, preadv, pwrite64, pthread_create.
• Wasmer: open64, unlink, read, write, sendto, send, statx, pthread_create.

The paper highlights that the statx syscall, specifically with the AT_STATX_SYNC_AS_STAT flag, identified in Wasmer's implementation, can trigger data synchronization and negatively impact host I/O performance—a new attack surface not previously analyzed.

Demo / Proof of Concept

The effectiveness of the proposed exploitation strategies was rigorously evaluated through experiments conducted in a controlled local environment (Section 5).

Experimental Setup:

• Hardware: Intel Core i7-10700 CPU, 16 GB RAM, 1 TB HDD, Gigabit Ethernet NIC.
• Operating System: Ubuntu 24 with kernel version 6.8.0-51-generic.
• Wasm Runtimes: Wasmtime 24.0.0 and Wasmer 4.3.2.
• Metrics: CPU usage (measured by pidstat for Wasm instance, dstat for system idle time), file I/O bandwidth (fio), network bandwidth (iperf3), and entropy pool depletion (ent).
• Baselines: Idle CPU usage 99.66%, file read 456.36 MB/s, write 237.50 MB/s, network upload 874.90 Mbits/s, download 872.54 Mbits/s, /dev/random generation rate 94.20 MB/s.

Wasmtime Exploitation Results (Table 2):

• Exploiting File Operation Interfaces (Data Synchronization):
• Continuously invoking fsync and fdatasync (via cap_std crate, invoking libc functions) reduced file read performance by over 93% (to 28.09 MB/s for sync data) and write performance by over 99% (to 0.10 MB/s).
• Wasm instance CPU usage was ~10%, but overall system CPU usage was ~25%, indicating an additional 15% computational overhead unaccounted for, bypassing Cgroups.
• Exploiting File Handling Interfaces (Creation/Deletion):
• Frequent openat2 and unlinkat syscalls (triggered via inline assembly) degraded I/O performance by over 99% (read to 6.48 MB/s, write to 4.08 MB/s).
• Wasm instance CPU was 4.45%, but system idle CPU was 84.54%, showing ~10% unaccounted overhead.
• Exploiting File R/W Interfaces (readv/writev, preadv/pwritev):
• Large chunk read/write operations caused over 99% degradation in I/O performance with minimal Wasm CPU usage (<1%).
• Writing small chunks also severely degraded performance with 2.31% Wasm CPU.
• Reading small chunks showed high Wasm CPU (99.89%) but "only" ~77% I/O impact, indicating significant CPU overhead transferred to other OS components.
• Exploiting Device Files (e.g., /dev/random, /dev/ptmx):
• Writing to /dev/null or reading from /dev/zero showed excessive Wasm CPU usage and >87% I/O degradation.
• Continuously reading from /dev/random reduced the random number generation rate from 94.20 MB/s to 7.60 MB/s (a 91.93% decrease), enabling DoS attacks.
• Exhausting /dev/ptmx file descriptors (max 4096) prevented new shell openings and SSH connections, a severe DoS.

Wasmer Exploitation Results (Table 3 & 4):

• Exploiting File Operation Interfaces (Data Synchronization):
• Wasmer uses Tokio's poll_flush instead of fdatasync/fsync. sync data consumed high Wasm CPU (99.96%), degrading system I/O.
• sync all operation, which updates file metadata and frequently invokes statx with AT_STATX_SYNC_AS_STAT, caused lower Wasm CPU (5.75%) but introduced ~8% CPU load to other system components, severely impacting I/O (read to 7.73 MB/s, write to 3.82 MB/s).
• Exploiting File Handling Interfaces (Creation/Deletion):
• Similar to Wasmtime, frequent open and unlink (libc functions) invocations led to >98% I/O bandwidth reduction, with 5% Wasm CPU and ~11% extra CPU load on the OS.
• Exploiting File R/W Interfaces (read, write from libc):
• Large chunk R/W operations caused >99% I/O degradation with <1% Wasm CPU.
• Small chunk R/W operations caused significant I/O drops due to frequent context switches and interrupts, injecting additional CPU load (e.g., large read operations generated ~40% extra CPU overhead).
• Exploiting Device Files (via mapped /dev1):
• Wasmer prohibits direct /dev access but allows mapping, enabling access to real device files. Most operations significantly degraded system I/O performance and incurred substantial CPU overhead.
• Reading from /dev1/random reduced the random number generation rate by 7.75% (to 86.90 MB/s).
• Exploiting Network Interfaces (sock_send, sock_sendto -> send, sendto from libc) (Table 4):
• Sending large TCP/UDP packets consumed significant network bandwidth (e.g., TCP large packets reduced upload to 61.79 Mbits/s from 874.90 Mbits/s).
• Sending small packets, while not consuming as much bandwidth, introduced excessive kernel load from frequent context switches and interrupts, degrading overall system network performance.
• UDP protocol attacks introduced ~12% extra CPU overhead to the underlying system.

These experimental results conclusively demonstrate that Wasm runtimes, despite their security claims, are vulnerable to resource exhaustion attacks via their WASI/WASIX interfaces, often by surreptitiously burdening the underlying operating system components.

Defensive Implications

The research unequivocally demonstrates that current Wasm runtimes exhibit significant weaknesses in resource isolation, allowing malicious Wasm instances to not only directly consume resources but also to inject workloads into other components of the underlying operating system. These attacks are particularly insidious because they are covert and challenging to defend against using existing mechanisms.

The authors discuss several potential defense mechanisms (Section 6), each with its own advantages and limitations:

1. XFS Filesystem:

• Mechanism: The XFS file system offers features to limit disk space and inode numbers.
• Application: Wasm runtimes can be configured to allow Wasm instances access only to specific directories within an XFS filesystem that has storage space and inode count restrictions. If a Wasm instance exceeds these limits, XFS can block the operations, preventing resource exhaustion.
• Limitation: Current Wasm runtimes do not natively support XFS integration, requiring additional configuration.

1. Cgroups (Control Groups):

• Mechanism: Cgroups can limit CPU, PIDs (processes/threads), disk I/O, and network bandwidth for a process or group of processes.
• Application: A Wasm runtime process can be assigned to a Cgroup with defined resource constraints (e.g., cpuset, CPU time quotas, I/O bandwidth limits).
• Limitation: While effective against direct resource exhaustion, Cgroups are often insufficient against attacks that inject workloads into other components of the operating system. For example, abusing file interfaces can still degrade I/O performance without high CPU or bandwidth usage by the Wasm instance itself, as the workload shifts to the kernel. This is a fundamental challenge because Wasm instances share the same OS kernel.

1. Fine-Grained Restriction Mechanisms:

• Necessity: Due to the limitations of Cgroups, more granular control is required.
• Syscall Interposition:
• Mechanism: Intercepting or filtering syscalls in user or kernel space.
• Challenge: Simply disabling common syscalls used by WASI/WASIX is not practical, as legitimate applications require them.
• Proposed Solution: Combine syscall interposition with frequency-based or learning-based defenses. System administrators could define acceptable usage frequencies for sensitive syscalls (e.g., fsync, fdatasync, statx with AT_STATX_SYNC_AS_STAT) or use deep learning to learn normal usage patterns. Deviations would trigger alerts or terminate the instance.
• Limitation: This approach requires expert knowledge, is highly application-specific, and lacks generality, though it might be suitable for specific use cases.
• eBPF (extended Berkeley Packet Filter):
• Mechanism: eBPF allows efficient monitoring and fine-grained control over kernel abstract resources without modifying kernel code.
• Application: eBPF could be used to monitor and limit a process's consumption of specific kernel resources (e.g., inode creation rate, entropy pool reads, ptmx file descriptor usage).
• Challenge: Requires precise analysis and identification of the actual resource consumers, potentially necessitating extensive kernel modifications to implement robust protections. Monitoring too many resources could also introduce performance overhead.
• Practical Compromise: Focus on monitoring and analyzing only sensitive resources to balance protection and performance impact.

Beyond DoS, the paper also briefly mentions that WASI/WASIX interfaces, particularly data synchronization mechanisms, could potentially be abused to build covert channels [18, 7], further expanding the security implications beyond just resource exhaustion. The overarching message is that while Wasm offers attractive security features, its current implementations lack the robust resource isolation needed for multi-tenant or untrusted environments, necessitating significant enhancements at the runtime and operating system interface levels.

Key Takeaways

• Wasm Runtimes Vulnerable to Resource Exhaustion: Despite Wasm's design for secure sandboxing, widely used runtimes like Wasmtime and Wasmer exhibit significant resource isolation vulnerabilities through their WASI/WASIX interfaces.
• Novel Static Analysis for Rust: A new static analysis framework was developed, specifically tailored for Rust projects, to systematically identify attack surfaces by addressing challenges in IR extraction, assembly code handling, and precise indirect call resolution.
• Covert Attacks Bypass Current Defenses: Malicious Wasm instances can not only directly consume host resources (CPU, disk, network) but, more insidiously, can inject workloads into underlying operating system components (e.g., kernel, I/O synchronization), making these attacks difficult to detect and mitigate with standard resource controls like Cgroups.
• Critical Kernel Resources at Risk: Specific attacks demonstrated the ability to exhaust vital kernel resources, such as the system entropy pool (via /dev/random) and pseudo-terminal file descriptors (via /dev/ptmx), leading to severe Denial-of-Service scenarios.
• I/O Synchronization and Frequent Operations are Potent Attack Vectors: Operations like fsync, fdatasync, and statx with AT_STATX_SYNC_AS_STAT can drastically degrade I/O performance. Similarly, frequent small I/O or network packet transmissions impose significant CPU overhead on the kernel due to context switches and interrupts.
• Enhanced Mitigation Strategies Are Crucial: Current defenses (e.g., Wasmtime's "fuel," Linux Cgroups) are often insufficient. More fine-grained mechanisms like frequency-based or learning-based syscall interposition, or eBPF-based kernel resource monitoring, are needed, though they present their own implementation and generality challenges.

About the Speaker(s)

The research was conducted by a collaborative team of academics. Zhaofeng Yu, Dongyang Zhan, Lin Ye, Haining Yu, and Hongli Zhang are affiliated with the Harbin Institute of Technology. Zhihong Tian is associated with Guangzhou University. The corresponding author, Dongyang Zhan, can be reached at [email protected]. Their collective work focuses on critical areas of system security, particularly exploring the emerging security challenges and attack surfaces within rapidly evolving technologies like WebAssembly and containerization. This paper highlights their expertise in static analysis, systems exploitation, and proposing practical security enhancements for modern computing environments.