Wasm Code-Confidentiality Attack

• Wasm Code-Confidentiality Attack is a side-channel attack that exploits TEEs' page-fault and timing leaks to extract WebAssembly bytecode.
• It uses a two-phase approach—profiling and extraction—to fingerprint opcode handlers via CPU latencies and page fault patterns, achieving up to 78% recovery.
• Mitigation strategies include handler diversification, code layout randomization, and hardware modifications to obscure sensitive execution metadata.

A WebAssembly (Wasm) code-confidentiality attack denotes an adversarial strategy that exploits side channels in Trusted Execution Environments (TEEs), notably Intel SGX and AMD SEV-SNP, to extract executed Wasm bytecode (opcodes) from an otherwise confidential execution context. While TEE platforms guarantee memory encryption and authentication, they leak execution metadata via page tables and controlled single-stepping. Recent research demonstrates that, compared to native binaries, Wasm IR executed within an interpreter is highly susceptible to instruction leakage, frequently exposing 45–78% of opcodes under single execution traces—an outcome that challenges the code confidentiality claims of TEE-based confidential computing (Berthilsson et al., 16 Dec 2025, Puddu et al., 2022).

1. Threat Model and Core Vulnerabilities

The attack assumes an adversary with supervisor privileges (hypervisor or OS), full control over VM scheduling/interruption, and the ability to manipulate page tables. The primary objective is to recover as much of the victim’s Wasm opcode stream as possible, relying exclusively on outside-enclave signals. No code or data modifications are introduced inside the TEE, and no cryptographic keys are assumed compromised.

AMD SEV-SNP, despite encrypting and authenticating guest memory, reveals the sequence and access types (execute/read/write) of page faults and the exact guest physical page numbers. Each 4 KB page used by the Wasm interpreter (for opcode handlers, optable, stack) produces a discernible runtime pattern. Intel SGX, in contrast, protects guest-physical to host-physical page mapping and limits observation to occurrence of page faults, without exposing page numbers. This difference yields a much richer signal for code recovery under SEV-SNP (Berthilsson et al., 16 Dec 2025).

2. Technical Distinctions: Wasm on TEE vs. Native Execution

When interpreted within a TEE, each Wasm opcode is implemented by a fixed “handler” in the interpreter, often comprising a small number of native x86 instructions. Interpreters, such as WAMR, employ a consistent table-based dispatch mechanism—creating distinctive, repeating memory access patterns per opcode (e.g., optable lookup, stack R/W). This deterministic memory footprint, paired with the small instruction set of Wasm (≈172 core opcodes), causes significant “leakage amplification”—each opcode corresponds to a highly characteristic sequence of native memory accesses and code page touches. Conversely, native binaries tend to inline, randomize, and diversify control flow and memory access, diffusing the leakage signal and making instruction recovery with the same methodology infeasible (Puddu et al., 2022).

3. Attack Methodology and Fingerprinting

The attack pipeline proceeds in two complementary phases: profiling (building opcode fingerprints) and extraction (recovering victim’s opcodes).

Profiling Phase: An identical VM, running the target interpreter, executes each opcode in isolation with instrumentation (e.g., a write to a designated "sync" page before dispatch). For every handler, the system collects:

• Per-instruction CPU latencies
• Page-fault event vectors (E/R/W at 4 KB page granularity)
• Bit-vectors representing instruction types and stack access patterns

The result is a canonical fingerprint for each Wasm opcode:

$$f = (f_{latency}, f_{pfaults}, f_{type}, \text{stack pattern})$$

Extraction Phase: The production workload is single-stepped (e.g., via SEV-Step under SEV-SNP), and all execution metadata are recorded after each instruction. Pre-processing identifies the interpreter's optable and stack pages, filtering out non-interpreter faults. The execution trace is segmented (using “sync” writes) so that each segment ideally maps to a single opcode dispatch.

For each segment $t$, matching computes similarity scores $S(f, t)$ to every profiled fingerprint $f$, leveraging:

• Pearson correlation for numerical channels (e.g., instruction latencies)
• Hamming-score for discrete trace patterns (E/R/W, stack access)

The final predicted opcode is the one with the highest combined similarity score:

$\hat{f} = \mathop{\mathrm{argmax}}_f\, S(f, t)$

Recall is quantified as:

$r_c = 1 - \frac{E + M + I}{N}$

where $N$ is the total number of extraction regions, $E$ the number of incorrect matches, $M$ of missed, and $I$ of spurious insertions (Berthilsson et al., 16 Dec 2025).

4. Experimental Evaluation and Results

Empirical analysis was performed using SEV-SNP on an AMD EPYC 8124P with a patched WAMR interpreter (iwasm) guest stack. Workloads included cryptographic routines (AES), number theory microbenchmarks (prime finding), and a chess engine.

Recall rates on SEV-SNP, compared to the best prior SGX single-step results, are summarized below.

Workload	Recall (SEV-SNP)	Recall (SGX, single-step)
AES (O0–O2)	67.6–76.7%	28% (avg)
primes.wat	78.1%	not evaluated
chess (O0–O3)	67.4–74.1%	–

Across seven evaluated applications, the mean recall was 67–78%, with the majority of false matches and misses attributed to overlapping latency distributions and register/memory sub-instruction ambiguities. Noise filtering (excluding traces ±3σ outside the reference distribution) improved recall by ≈3%. The attack demonstrated robustness across deeper control flow (chess O3: $N \sim 10^8$ extraction regions, recall ≈74%) (Berthilsson et al., 16 Dec 2025).

Earlier studies using SGX and the WAMR interpreter reported an overall $R_1$ (fraction of unique opcode matches) ≥ 45%, with recovery in top-3 candidates for 95% of regions in a single real workload run (Puddu et al., 2022). Native binary execution, even under strong attacker models, yielded negligible instruction recovery: $R_1 \approx 0\%$, $>90\%$ of x86 instructions remained highly ambiguous.

5. Amplification Effects and Interpreter Leakiness

The marginal leakiness of Wasm IR inside TEEs is structurally rooted: each Wasm opcode typically expands to 8–120 native instructions within the interpreter. The x86 ISA is vast, but the compactness of the Wasm ISA means that ambiguous native instruction traces resolve to a unique or near-unique Wasm opcode in most cases, thus amplifying the risk.

Unlike native code, which disperses faults and memory accesses over a randomized code and stack layout, the static “optable + stack” paradigm of Wasm interpreters is recurrent and predictable. This effect, compounded by the reduced entropy and semantic granularity of Wasm instructions, yields a strong side channel in the paging and timing signals collected through the TEE’s exposed address space (Puddu et al., 2022, Berthilsson et al., 16 Dec 2025).

6. Countermeasures and Mitigation Strategies

Mitigation approaches span hardware, compiler/runtime, and obfuscation layers:

• Hardware/ISA-level: Conceal page-faults' guest-physical page numbers from the hypervisor, randomize page-fault delivery (AEX-Notify, TLBlur).
• Compiler/Runtime-level:
  • Handler diversification: generate multiple, semantically identical handlers for each opcode and randomize dispatch.
  • Code layout randomization: shuffle or pad handler arrangement to destroy fixed page-opcode alignment.
  • Transition to tiered or full JIT execution to obviate static mapping patterns.
• Obfuscation: Random insertion of dummy memory accesses, stack offset randomization, and instruction-level noise injection (e.g., dummy loads) to mask observable page-fault patterns.

Additional strategies include dummy-instruction padding of IR streams and the design of interpreters with constant-time per-opcode execution that accesses uniform pages regardless of dispatched instruction. Hardware modifications—such as restricting per-instruction state exposure to post-retirement or encrypting code pages—are also advocated (Puddu et al., 2022, Berthilsson et al., 16 Dec 2025).

7. Broader Implications and Security Outlook

These code-confidentiality attacks demonstrate that the use of Wasm IR within TEEs, even under strong hardware memory-protection models, is fundamentally vulnerable to page-fault and timing side channels not present in native execution. Interpreter-based confidential computing platforms relying on TEEs and Wasm cannot guarantee robust code secrecy against privileged adversaries under realistic assumptions. Defending against such attacks requires nontrivial modifications in both TEEs and Wasm execution engines, shifting toward either hardware isolation of page-access metadata or dynamic, randomized interpreter behaviors.

In summary, by leveraging the increased granularity of address-space exposure in AMD SEV-SNP and the deterministic handling patterns of Wasm interpreters, recent work achieves >70% recovery of Wasm instruction streams in a single trace—surpassing prior SGX single-step extraction rates and highlighting an essential tradeoff between interpreter portability and code confidentiality in TEE scenarios (Berthilsson et al., 16 Dec 2025, Puddu et al., 2022).