---
title: Wasm Code-Confidentiality Attack
url: https://www.emergentmind.com/topics/wasm-code-confidentiality-attack
type: topic
---

# Wasm Code-Confidentiality Attack

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 [2512.14376], [2212.07899].

## 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 [2512.14376].

## 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 [2212.07899].

## 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 [2512.14376].

## 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%) [2512.14376].

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 [2212.07899]. 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 [2212.07899], [2512.14376].

## 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 [2212.07899], [2512.14376].

## 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 [2512.14376], [2212.07899].

Source: https://www.emergentmind.com/topics/wasm-code-confidentiality-attack