4 ms·

Wasm is not sandboxed. Wasm is simply another standard way of writing instructions that can be platform independent. Wasm has no standard library software for s

Wasm is not sandboxed. Wasm is simply another standard way of writing instructions that can be platform independent. Wasm has no standard library software for sandboxing. Sandboxing is entirely dependent upon software implimenting execution of wasm instructions. Very few do this, there are fewer from reputable sources that do it without a JavaScript engine, and none that put sandboxing first.

nynx 7y ago
Wasm is sandboxed. It's designed to be entirely safe to run.
- saagarjha 7y ago
  Apart from the fact that it can potentially run forever, which can be unacceptable in certain contexts.
  - AgentME 7y ago
    That can be addressed by pre-processing WASM like in https://github.com/ewasm/wasm-metering https://github.com/ewasm/wasm-metering so it aborts if it runs for too many steps.
    - devwastaken 7y ago
      Instruction modification is a hack. The proper way is to control as a VM.
- devwastaken 7y ago
  That's entirely dependent upon the runtime. Wasm is advertised as many things it's not. The only thing it is, is a set of instructions. Here, go through the list. https://github.com/appcypher/awesome-wasm-runtimes https://github.com/appcypher/awesome-wasm-runtimes
  - the_duke 7y ago
    And all of those basic instructions only operate in a protected memory space. There is no stack to manipulate,no way to do syscalls or interact with the host environment in any way that is not mediated by the runtime. Wasm instructions are not native instructions. The spec [1] clearly states that Webassembly is sandboxed. A non-sandboxing implementation would be either non-compliant or have bugs (which admittedly they most likely do at this point, considering they are still new). [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...
    - devwastaken 7y ago
      Which is all completely dependent upon the implimentation of the executing software. Lets take it from the beginning, 1. wasm is a set of instructions. 2. those instructions have to be turned into instructions the hardware understands to execute them. No where in here is there a requirement of sandboxing. With a sandbox, a 'protected memory space' is dependent upon the implimentor. There's no such thing as a magic software sandbox that you just drop into software and congrats, secure. You impliment it.
      - the_duke 7y ago
        > No where in here is there a requirement of sandboxing Let me quote the Webassembly spec [1]: > WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...
        devwastaken 7y ago
        There is a seperation between spec and implimentation. That quote doesn't at all disagree with me. That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically. You can impliment all of that and still have a vulnerable runtime because of how you implimented it. You can also just put in system access as functions, as some runtimes do because they don't care about sandboxing.
- Spivak 7y ago
  Wasm is no more or less sandboxed than any other VM. It’s entirely up to the implementation how much access it gets to the outside world.
- mhh__ 7y ago
  WASM implementations are sandboxed - which can be defeated in theory as, given that there were POC spectre attacks on Javascript VMs it must be possible to do the same on what would be a Webassembly frontend to the same backend (practically) - but eBPF (or the validator to be more specific) is designed to conservatively only accept programs that it can guarantee have certain semantics.
the_duke 7y ago
I'm curios where you got this information from, but you are quite misinformed. Webassembly is designed to be sandboxed and safe to run. Interaction with the host environment is only possible via the runtime.

nynx 7y ago

Wasm is sandboxed. It's designed to be entirely safe to run.

saagarjha 7y ago
Apart from the fact that it can potentially run forever, which can be unacceptable in certain contexts.
- AgentME 7y ago
  That can be addressed by pre-processing WASM like in https://github.com/ewasm/wasm-metering https://github.com/ewasm/wasm-metering so it aborts if it runs for too many steps.
  - devwastaken 7y ago
    Instruction modification is a hack. The proper way is to control as a VM.
devwastaken 7y ago
That's entirely dependent upon the runtime. Wasm is advertised as many things it's not. The only thing it is, is a set of instructions. Here, go through the list. https://github.com/appcypher/awesome-wasm-runtimes https://github.com/appcypher/awesome-wasm-runtimes
- the_duke 7y ago
  And all of those basic instructions only operate in a protected memory space. There is no stack to manipulate,no way to do syscalls or interact with the host environment in any way that is not mediated by the runtime. Wasm instructions are not native instructions. The spec [1] clearly states that Webassembly is sandboxed. A non-sandboxing implementation would be either non-compliant or have bugs (which admittedly they most likely do at this point, considering they are still new). [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...
  - devwastaken 7y ago
    Which is all completely dependent upon the implimentation of the executing software. Lets take it from the beginning, 1. wasm is a set of instructions. 2. those instructions have to be turned into instructions the hardware understands to execute them. No where in here is there a requirement of sandboxing. With a sandbox, a 'protected memory space' is dependent upon the implimentor. There's no such thing as a magic software sandbox that you just drop into software and congrats, secure. You impliment it.
    - the_duke 7y ago
      > No where in here is there a requirement of sandboxing Let me quote the Webassembly spec [1]: > WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. [1] https://webassembly.github.io/spec/core/intro/introduction.html#security-considerations https://webassembly.github.io/spec/core/intro/introduction.h...
      - devwastaken 7y ago
        There is a seperation between spec and implimentation. That quote doesn't at all disagree with me. That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically. You can impliment all of that and still have a vulnerable runtime because of how you implimented it. You can also just put in system access as functions, as some runtimes do because they don't care about sandboxing.
Spivak 7y ago
Wasm is no more or less sandboxed than any other VM. It’s entirely up to the implementation how much access it gets to the outside world.
mhh__ 7y ago
WASM implementations are sandboxed - which can be defeated in theory as, given that there were POC spectre attacks on Javascript VMs it must be possible to do the same on what would be a Webassembly frontend to the same backend (practically) - but eBPF (or the validator to be more specific) is designed to conservatively only accept programs that it can guarantee have certain semantics.

the_duke 7y ago

I'm curios where you got this information from, but you are quite misinformed. Webassembly is designed to be sandboxed and safe to run. Interaction with the host environment is only possible via the runtime.