WebAssembly, JVM, CLR and Managed Runtime Security — DedSec Project

Managed runtimes and bytecode VMs create different security boundaries from native binaries. Memory safety may improve, but deserialization, reflection, dynamic loading, sandbox escapes, native interfaces, JIT compilation, and capability exposure remain important.

Learning objectives

By the end of this module you should be able to:

• Explain Bytecode verification and connect it to a concrete trust boundary or security invariant.
• Explain Memory model and connect it to a concrete trust boundary or security invariant.
• Explain JIT trust and connect it to a concrete trust boundary or security invariant.
• Explain Reflection and dynamic loading and connect it to a concrete trust boundary or security invariant.
• Explain Deserialization and connect it to a concrete trust boundary or security invariant.
• Explain WebAssembly imports and connect it to a concrete trust boundary or security invariant.

Deep concepts

1. Bytecode verification

Managed runtimes validate or constrain bytecode/module structure before execution. Verification reduces classes of malformed code but does not prove application authorization or logic is safe.

2. Memory model

JVM/CLR memory safety prevents many direct pointer errors in ordinary managed code, while unsafe/native interop reintroduces native memory risks. WebAssembly uses linear memory and explicit host imports.

3. JIT trust

Just-in-time compilers translate frequently executed code into native instructions. They are complex privileged components inside the runtime security model and require regular patching/hardening.

4. Reflection and dynamic loading

Reflection, plugins, class loading, expression engines, and dynamic assembly/module loading can convert data or configuration into powerful behavior. Apply allowlists and signature/provenance controls where appropriate.

5. Deserialization

Object serialization frameworks can instantiate types or invoke callbacks. Prefer simple data formats/schemas and treat untrusted native object deserialization as a high-risk design choice.

6. WebAssembly imports

A Wasm module can access only capabilities exposed by its host/runtime model. The host import surface, filesystem/network preopens, and embedding application are the real security boundary.

7. Native interfaces

JNI, P/Invoke, FFI, browser/runtime host calls, and native extensions cross from managed assumptions into native code. Inventory those edges and validate data/length/ownership carefully.

8. Sandbox verification

Test what the runtime can actually access: files, environment, network, clocks, randomness, devices, host calls, and process creation. Configuration determines the practical sandbox.

Authorized exercises

Exercise 1 — Create a harmless local Wasm or managed-language hello-world and document every capability the runtime exposes to it

Create a harmless local Wasm or managed-language hello-world and document every capability the runtime exposes to it.

Exercise 2 — Build a safe deserialization threat model comparing plain JSON DTO parsing with native object deserialization

Build a safe deserialization threat model comparing plain JSON DTO parsing with native object deserialization.

Exercise 3 — Inventory native/FFI dependencies in a small managed application and classify why each trust-boundary crossing exists

Inventory native/FFI dependencies in a small managed application and classify why each trust-boundary crossing exists.

Knowledge checks

1. Explain the most important trust boundary in WebAssembly, JVM, CLR and Managed Runtime Security without naming a security tool.
2. Give one example where cryptographic or authentication success still does not imply authorization success.
3. Describe one stale-state or replay condition relevant to this module.
4. Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
5. Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.

Guided study workflow