5 ms·

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

by nynx 7y ago

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.
        thayne 7y ago
        > That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically True, but a conforming implementation has at least some sandboxing, since it prevents arbitrary memory access. But the degree to which it is sandboxed depends on the functions that are exposed by the runtime.
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.

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

by 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.
      - thayne 7y ago
        > That's how wasm is meant to be, but doesn't give any detail as to how that's achieved programatically True, but a conforming implementation has at least some sandboxing, since it prevents arbitrary memory access. But the degree to which it is sandboxed depends on the functions that are exposed by the runtime.

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.