4 ms·

It does

pjmlp 8y ago
It does not, something like char buff[100]; char func(int idx) { char *ptr = buff; return ptr[idx]; } int main (void) { printf("%c", func(200)); return 0; } Compiles nicely to something like this (module (type $FUNCSIG$ii (func (param i32) (result i32))) (import "env" "putchar" (func $putchar (param i32) (result i32))) (table 0 anyfunc) (memory $0 1) (export "memory" (memory $0)) (export "func" (func $func)) (export "main" (func $main)) (func $func (; 1 ;) (param $0 i32) (result i32) (i32.load8_s (i32.add (get_local $0) (i32.const 16) ) ) ) (func $main (; 2 ;) (result i32) (drop (call $putchar (i32.load8_s offset=216 (i32.const 0) ) ) ) (i32.const 0) ) ) Which will gladly blow up, or not, when i32.load8_s gets called. https://webassembly.studio/ https://webassembly.studio/
- comesee 8y ago
  The load8_s instruction will check that the computed offset into the memory of size 64KB (1 wasm page) does not index past the bounds of 64KB. If it does, the program will trap.
  - pjmlp 8y ago
    Which will not work on the provided example, thus leading to memory corruption. Where is the WebAssembly implementation that traps on my example?
    - comesee 8y ago
      WebAssembly protects the host from memory corruption by the user module. To do this it does a bounds check before executing the load. It does not protect a user module from itself. It does not change the semantics of C. Relevant documentation http://webassembly.github.io/spec/core/syntax/instructions.html#syntax-instr-memory http://webassembly.github.io/spec/core/syntax/instructions.h...
      - pjmlp 8y ago
        > It does not protect a user module from itself. It does not change the semantics of C. Which is my whole point, WebAssembly does not protect memory corruption inside of the module code, which allows for security exploits anyway. On my sample code if I expose func() to the host, and it gets called with 200 as parameter for a buffer size of 100 bytes, no trap will ocurr. On a real use case that call might induce an internal memory corruption that will, for example, change the behavior of other functions exposed to the host. If you wish I can provide an example how to do that, which you can try out in your favorite spec compliant Web Assembly implementation.
        TomMarius 8y ago
        Current WASM spec is a MVP. There will be other ways to expose functionality to the host that should be safer. See future proposals. Your points are valid though.
        comesee 8y ago
        How is this relevant to wasmjit? User space programs written in C can already corrupt themselves. As far as I can tell there is no new inherent risk to kernel stability by running wasm code in kernel space as long as the wasm spec is followed. Just like wasm programs aren't able to corrupt the browser sandbox in which they run.
        pjmlp 8y ago
        The sandbox gives a false sense of security, because it opens a new attack vector. Apparently you fail to understand how security exploits are taken. For example, lets say I have an authentication module provided as WebAssembly, written in C. The browser makes use of the said WebAssembly module to authenticate the user. Now we make a cross site scripting attack that calls the WebAssembly functions in a sequence that triggers memory corruption inside of the module, thus influencing how the authentication functions work. Afterwards the JavaScript functions that call those WebAssembly ones, might authenticate a bad user that would otherwise be denied access. A contrived scenario that can be easily programmed in https://webassembly.studio/ https://webassembly.studio/ .

It does

It does not, something like char buff[100]; char func(int idx) { char *ptr = buff; return ptr[idx]; } int main (void) { printf("%c", func(200)); return 0; } Compiles nicely to something like this (module (type $FUNCSIG$ii (func (param i32) (result i32))) (import "env" "putchar" (func $putchar (param i32) (result i32))) (table 0 anyfunc) (memory $0 1) (export "memory" (memory $0)) (export "func" (func $func)) (export "main" (func $main)) (func $func (; 1 ;) (param $0 i32) (result i32) (i32.load8_s (i32.add (get_local $0) (i32.const 16) ) ) ) (func $main (; 2 ;) (result i32) (drop (call $putchar (i32.load8_s offset=216 (i32.const 0) ) ) ) (i32.const 0) ) ) Which will gladly blow up, or not, when i32.load8_s gets called. https://webassembly.studio/ https://webassembly.studio/

comesee 8y ago
The load8_s instruction will check that the computed offset into the memory of size 64KB (1 wasm page) does not index past the bounds of 64KB. If it does, the program will trap.
- pjmlp 8y ago
  Which will not work on the provided example, thus leading to memory corruption. Where is the WebAssembly implementation that traps on my example?
  - comesee 8y ago
    WebAssembly protects the host from memory corruption by the user module. To do this it does a bounds check before executing the load. It does not protect a user module from itself. It does not change the semantics of C. Relevant documentation http://webassembly.github.io/spec/core/syntax/instructions.html#syntax-instr-memory http://webassembly.github.io/spec/core/syntax/instructions.h...
    - pjmlp 8y ago
      > It does not protect a user module from itself. It does not change the semantics of C. Which is my whole point, WebAssembly does not protect memory corruption inside of the module code, which allows for security exploits anyway. On my sample code if I expose func() to the host, and it gets called with 200 as parameter for a buffer size of 100 bytes, no trap will ocurr. On a real use case that call might induce an internal memory corruption that will, for example, change the behavior of other functions exposed to the host. If you wish I can provide an example how to do that, which you can try out in your favorite spec compliant Web Assembly implementation.
      - TomMarius 8y ago
        Current WASM spec is a MVP. There will be other ways to expose functionality to the host that should be safer. See future proposals. Your points are valid though.
      - comesee 8y ago
        How is this relevant to wasmjit? User space programs written in C can already corrupt themselves. As far as I can tell there is no new inherent risk to kernel stability by running wasm code in kernel space as long as the wasm spec is followed. Just like wasm programs aren't able to corrupt the browser sandbox in which they run.
        pjmlp 8y ago
        The sandbox gives a false sense of security, because it opens a new attack vector. Apparently you fail to understand how security exploits are taken. For example, lets say I have an authentication module provided as WebAssembly, written in C. The browser makes use of the said WebAssembly module to authenticate the user. Now we make a cross site scripting attack that calls the WebAssembly functions in a sequence that triggers memory corruption inside of the module, thus influencing how the authentication functions work. Afterwards the JavaScript functions that call those WebAssembly ones, might authenticate a bad user that would otherwise be denied access. A contrived scenario that can be easily programmed in https://webassembly.studio/ https://webassembly.studio/ .