Wasmtime GitHub notifications bot (Mar 21 2020 at 04:08): Wasmtime GitHub notifications bot (Mar 21 2020 at 04:08):sunfishcode commented on Issue #871:
Hello! I recently started adding some content to the security-sandboxing document, and it answers this question, at least at a high level.
All "pointers" in C are compiled into wasm as indices into linear memory, which you can think of as just an array of bytes, with bounds checking. So while your vulnerable C code may store beyond the ends of the nominal array, it can't access any memory outside the wasm instance's memory.
Also, all control transfers in wasm are checked, at compile time or runtime, to ensure they go to known branch/jump destinations. Among other things, this means that even if you load a machine-code payload, you can't make the program jump to it.
Does this clarify things? If not, please let us know as we're interested in expanding the documentation to answer questions people have!
Wasmtime GitHub notifications bot (Mar 06 2021 at 11:45):bluescreen303 commented on Issue #871:
better late than never :)
Yes, that document clarifies things a lot. Many thanks!
Wasmtime GitHub notifications bot (Mar 06 2021 at 11:45):bluescreen303 closed Issue #871:
I noticed the documentation for how the sandbox works is just a stub currently. I would really like to know more about it, so this issue is just to track progress.
- I read https://bytecodealliance.org/articles/announcing-the-bytecode-alliance and am enthousiastic
- I played around with rust / wasmpack before and tried the hello world and capabilities system in wasmtime.
- I understand how proper wasm modules only get access to certain resources and capabilities their parent gives them
- However, compiled(jitted) code all runs in 1 (operating system) process so it can potentially do system calls and access all memory in the process
One thing I would really like to get clarified is how the sandbox (and possibly the just-in-time compilation of wasm to machine code) will protect against the following scenario:
- I create a bit of c code that has a buffer overflow in a function
- I compile this c code to wasm
- I say my wasm module doesn't need any capabilities and only expose a string -> string function
- I create an additional module that will call the vulnerable module with a payload that overflows the buffer with some machine code for the target architecture
- this machine code isn't generated by the jit, didn't come from a valid wasm module
- so it can do things like memory access and syscalls and isn't bound to what the wasm module received as inputs
- I somehow find a way to have the instruction pointer jump to this malicious code (as I would be able to do in c)
My guess is that either the overflowing wouldn't work (how is this protected given that c is compilable into wasm), or there is no way to get the overflowed malicious code to execute (how would wasmtime protect against this?), but I would like some nice documentation explaining this.
Last updated: Oct 23 2024 at 20:03 UTC