Walma: Learning to See Memory Corruption in WebAssembly

1. Problem Statement

WebAssembly (Wasm) has become a ubiquitous binary format for edge computing, serverless functions, and browser applications. However, its security model faces two critical, unaddressed threats:

• Internal Memory Corruption: Wasm uses a monolithic linear memory model where the stack, heap, and global data reside in a single contiguous array. Unlike native architectures with separated memory regions, a buffer overflow in Wasm can corrupt adjacent data structures, enabling data-only attacks (e.g., overwriting trusted variables without violating Control-Flow Integrity).
• External Tampering by Untrusted Hosts: In cloud and edge deployments, the host infrastructure (OS, hypervisor, or administrator) is often untrusted. A privileged adversary can directly tamper with the Wasm module's linear memory (via DMA, ptrace, or system calls) to subvert logic (e.g., bypassing authorization) without crashing the application.

Limitations of Existing Defenses:

• Traditional defenses (ASLR, CFI) are incompatible with Wasm's linear memory or do not cover data-only attacks.
• Existing solutions require invasive binary instrumentation, custom compilers, or dedicated hardware.
• Remote Attestation (RA) and Control-Flow Attestation (CFA) verify code identity or execution paths but fail to detect state manipulation where the control flow remains valid but the data is corrupted.

2. Methodology: Walma Framework

Walma (WebAssembly Linear Memory Attestation) is a framework that shifts verification from static code properties to dynamic memory state. It leverages Machine Learning (ML) to detect anomalies in memory snapshots.

Core Concept

The system treats Wasm's linear memory as a grayscale image, where byte values correspond to pixel intensities. The authors hypothesize that memory corruption and external tampering create distinct structural artifacts (visual noise) in these "images" that differ from benign execution patterns.

System Architecture

Walma operates in two phases:

1. Offline Training Phase:

   • Data Generation: Uses binary instrumentation (via Walrus) to inject snapshot hooks at deterministic points.
   • Labeling: Employs coverage-guided fuzzing combined with sanitizers (e.g., AddressSanitizer) as a ground-truth oracle. Executions triggering sanitizer violations are labeled "corrupted"; valid runs are "benign."
   • Model Training: Converts memory snapshots into images and trains Convolutional Neural Networks (CNNs). Two architectures are used:
     • VGG-16: High capacity (134M parameters) for baseline accuracy.
     • Custom ResNet: Lightweight (1.9M parameters) optimized for constrained environments (e.g., Trusted Execution Environments).

2. Online Runtime Attestation Phase:

   • Attester: Runs on the untrusted host (Wasm module). It captures linear memory at instrumentation points, applies Run-Length Encoding (RLE) compression to reduce bandwidth (stripping zero-byte runs), and transmits the snapshot.
   • Verifier: The root of trust that reconstructs the image, runs inference, and issues a verdict.
   • Deployment Scenarios:
     • Scenario A (Untrusted Cloud): The verifier runs inside a Trusted Execution Environment (TEE) (e.g., Intel SGX) to protect against a malicious host.
     • Scenario B (Compromised Web Module): The verifier runs in the browser (trusted host) to monitor a potentially vulnerable module before it exploits the host.
   • Verdict Aggregation: To mitigate false positives from transient valid states, Walma uses a sliding window mechanism. An execution is flagged as malicious only if a threshold of consecutive snapshots is classified as corrupted.

Verification Backends

The paper evaluates three backend configurations:

• cpu-wasm (In-Runtime): Verifier runs inside the Wasm runtime (WASI-NN/OpenVINO). Minimizes data transfer; ideal for TEEs.
• cpu-tch (Native Host): Verifier runs as a native process (LibTorch). Trusts the OS; ideal for browser monitoring.
• GPU: Offloads inference to hardware accelerators (CUDA). High throughput but introduces PCIe transfer latency and potential side-channel risks.

3. Key Contributions

1. Novel Threat Model: Addresses the "malicious host" threat in Wasm, where the infrastructure provider can tamper with memory without detection by current CFA schemes.
2. ML-Based Memory Attestation: First framework to use CNNs to classify Wasm linear memory snapshots as images to detect both internal corruption and external tampering.
3. Decoupled Architecture: Separates execution from verification, allowing flexible deployment in TEEs or browsers without modifying the source code of the Wasm module.
4. Open Source: The authors open-sourced the Walma framework to foster further research.

4. Experimental Results

The evaluation was conducted on six real-world applications with known CVEs (e.g., flac, jbig2dec, pdfresurrect) and the PolyBenchC suite.

Security Effectiveness

• Structured Workloads: Applications with highly structured memory layouts (e.g., audio frames in flac, pixel buffers in pal2rgb) achieved 100% verdict accuracy with program-specific models.
• Generalization: A single generalized model trained on a pooled corpus could detect corruption across different applications, achieving 94.50% accuracy on flac and 85.43% on jbig2dec.
• Unstructured Workloads: Text processing applications (e.g., abc2mtex) showed lower accuracy (~50%) due to irregular memory layouts, highlighting a current limitation.

Performance Overhead

The system evaluated three instrumentation policies:

1. Boundary Defense (Import Function): Checks memory before host calls.
2. Internal Logic (Local Function): Checks at function entries.
3. Fine-Grained (Memory Instruction): Checks before every write.

Key Findings:

• Low Overhead for Coarse-Grained: The boundary defense policy incurred only 1.07× overhead (7% increase), making it viable for production.
• Predictable Fine-Grained Cost: Even the most intrusive policy (Memory Instruction) resulted in 1.82× overhead (82% increase), which is acceptable for high-security contexts.
• Backend Efficiency: The in-runtime (cpu-wasm) backend was the most efficient (avg. 6.42 ms latency). Surprisingly, GPU offloading was slower (42.94 ms) due to the PCIe data transfer bottleneck, proving that data locality is more critical than raw inference speed for this use case.

5. Significance and Conclusion

Walma represents a paradigm shift in WebAssembly security by moving from control-flow verification to state-centric attestation.

• Practicality: It demonstrates that ML-based memory attestation is feasible with predictable, tunable overheads (1.07× to 1.82×).
• Threat Coverage: It uniquely addresses the gap left by existing defenses: detecting data-only attacks and external tampering by untrusted hosts.
• Future Impact: The work suggests that for secure runtimes, keeping verification logic close to the execution context (in-runtime) is superior to offloading to accelerators due to data transfer costs.

The paper concludes that while detection for unstructured data needs improvement, Walma provides a robust, practical foundation for continuous integrity assurance in the growing ecosystem of WebAssembly deployments.