3 ms·

Yes. WASM is secure in that it won't let programs escape. But it runs C and C++ programs which means that it lets them do anything those programs would do - jus

Yes. WASM is secure in that it won't let programs escape. But it runs C and C++ programs which means that it lets them do anything those programs would do - just inside a secure box. If you want your program to be more correct and secure that's then down to you to make sure it is. WASM just makes sure it can't take over the user's PC (or host's, if it's running outside of a browser).

pjmlp 4y ago
Which is a message that unfortunely many WASM advocates leave out, asserting it is secure all over the board, hence why I tend to point out there are actually some footnotes related to it.
- paulgb 4y ago
  Maybe I’m missing some nuance here but it’s not clear to me what the omission by wasm advocates is? > And this kids, is why security in WASM still needs to be taken with a grain of salt if any of those modules touch critical data or return values that influence the caller's decisions Isn’t this true of any sandboxed environment? You can trust it not to touch things outside of the sandbox, but any holes you poke to get data in/out need their own verification.
  - pjmlp 4y ago
    WASM is sold as being 100% secure. No it isn't true for all sandboxed environments, there are sandboxed environments where memory accesses are bound checked for the underlying data types, instead of only the complete linear memory segment.
    - paulgb 4y ago
      Thanks, that makes sense. This would only matter if you’re sharing the linear memory between different bytecode modules, though, right? If only one wasm module can touch a span of linear memory I can’t think of anything that it could do that wouldn’t be possible with type-aware bound checks (in the extreme, it could just treat the memory as an array of u8s and implement data structures on top of that, bypassing any type-awareness that the VM has)
      - pjmlp 4y ago
        In the extreme, one can write bytecode or Assembly directly and thus exploit everything, including binaries generated from safe languages. The point is preventing that a 100 byte array gets a 200 index access, even though the overall linear memory segment for the WASM module is 500 big.
modeless 4y ago
Not only that, but WASM leaves out security features that native platforms have, making it actually easier in some ways to exploit programs than it would be if they were native. https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...

pjmlp 4y ago

Which is a message that unfortunely many WASM advocates leave out, asserting it is secure all over the board, hence why I tend to point out there are actually some footnotes related to it.

paulgb 4y ago
Maybe I’m missing some nuance here but it’s not clear to me what the omission by wasm advocates is? > And this kids, is why security in WASM still needs to be taken with a grain of salt if any of those modules touch critical data or return values that influence the caller's decisions Isn’t this true of any sandboxed environment? You can trust it not to touch things outside of the sandbox, but any holes you poke to get data in/out need their own verification.
- pjmlp 4y ago
  WASM is sold as being 100% secure. No it isn't true for all sandboxed environments, there are sandboxed environments where memory accesses are bound checked for the underlying data types, instead of only the complete linear memory segment.
  - paulgb 4y ago
    Thanks, that makes sense. This would only matter if you’re sharing the linear memory between different bytecode modules, though, right? If only one wasm module can touch a span of linear memory I can’t think of anything that it could do that wouldn’t be possible with type-aware bound checks (in the extreme, it could just treat the memory as an array of u8s and implement data structures on top of that, bypassing any type-awareness that the VM has)
    - pjmlp 4y ago
      In the extreme, one can write bytecode or Assembly directly and thus exploit everything, including binaries generated from safe languages. The point is preventing that a 100 byte array gets a 200 index access, even though the overall linear memory segment for the WASM module is 500 big.

modeless 4y ago

Not only that, but WASM leaves out security features that native platforms have, making it actually easier in some ways to exploit programs than it would be if they were native. https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat...