Hacker News new | ask | show | jobs
by jetzzz 1291 days ago
If you are running untrusted WASM files with wasmedge be aware that it doesn't sandbox by default. WASM can contain native code that will be executed without sandboxing. From the docs [0][1]:

> The wasmedge CLI tool will execute the WebAssembly in ahead-of-time(AOT) mode if available in the input WASM file.

> The wasmedgec can compile WebAssembly into native machine code (i.e., the AOT compiler). For the pure WebAssembly, the wasmedge tool will execute the WASM in interpreter mode. After compiling with the wasmedgec AOT compiler, the wasmedge tool can execute the WASM in AOT mode which is much faster.

They added an option (--force-interpreter) to disable running untrusted native code [2]:

> Thanks for reporting this. I think we can have a flag to disable the automatically loaded AOT sections from an unknown given universal wasm format. One possible situation is that users want to execute a wasm file with interpreter mode, however, they use a universal wasm format received from a malicious developer, and then the bad thing happens.

[0]: https://wasmedge.org/book/en/cli/wasmedge.html

[1]: https://wasmedge.org/book/en/cli/wasmedgec.html

[2]: https://github.com/WasmEdge/WasmEdge/issues/1631

1 comments

Hmm, we allow the CLI to execute AOT code sections embedded in WASM files as a convenience feature -- you can do AOT compilation and then execute it on your CLI.

For server side deployment, you should always do the AOT compilation on the server. But I agree this could be more clear. We are adding a new CLI option to disable AOT code segment in the WASM file for people who do not wish to perform the separate AOT compilation step.