6 ms·

"Some kind of fat pointers or tagging" is exactly the sort of thing WebAssembly was created to get away from. You can use a language that provides them and tar

by Rusky 8y ago

"Some kind of fat pointers or tagging" is exactly the sort of thing WebAssembly was created to get away from. You can use a language that provides them and targets WebAssembly, without taking away the thing that makes the platform uniquely useful.

pjmlp 8y ago
Right, but how can you trust a WebAssembly library? It might have been compiled from Ada, Rust or plain C, just as an example. Telling just to use a language we trust is not an option if one is just using other people libraries. Thus bringing to the web the same security level as depending on regular native libraries, because a regular user is not going to check what a web page depends on.
- danShumway 8y ago
  If you're bringing in multiple separate WASM libraries, they'll run separately from each other. Don't give them access to any memory they shouldn't have access to. Note that this is considerably better than Javascript, because without going out of your way to make an iframe, separate Javascript scripts aren't isolated from each other, so you don't know if one of them is modifying a prototype or hooking around other variables in the global scope. By default, separate WASM modules don't have access to the same memory.
  - pjmlp 8y ago
    The whole point is about corrupting WASM modules INTERNAL memory via public exported functions, just because they happen to have typical out-of-bounds errors. Linux Security Summit 2018 had a report that 68% of kernel exploits are caused by out-of-bounds errors. User space doesn't write on kernel level, but can call syscalls, which happen to trigger such exploits. WebAssembly is no different, regardless how they are sandboxed between modules.
    - danShumway 8y ago
      If you have access to JS on the host system, why would you use such a roundabout, overcomplicated way to attack a module? Why wouldn't you just use JS to remove the WASM module, replace it with a malicious module you wrote, and then overwrite the exported functions? Safe pointers won't protect you from a malicious host environment. And like the original parent said, if you have code where you want safe pointers, use a language that requires them. Your module will be protected from any other WASM dependencies you bring in because they run in separate contexts and can't access each other. Don't give them access to critical memory. WASM makes this easy. You're just not protected from a compromised host environment -- but that's not new, that's the case for everything on the web. WASM protects the page from your module, not the other way around. Imagine that I'm running Linux, and I put Windows in a VM inside of Linux. Is it a problem that Linux could compromise or mess with my Windows VM? Of course not, that's intended -- the point of a VM is not to protect the system running inside the VM, it's to protect the system running outside of it. Maybe I don't understand what your threat model is. Are you worried about serverside code? I don't know that many people are really looking into running WASM on the serverside, and I don't see how the threat model is any different from writing a server in something like C++.
  - panic 8y ago
    Not sharing memory is a pretty big restriction, though. For example, if you have variable-length data like a string, you can't pass it to a WASM module instance without either calling a function repeatedly for each data unit (slow) or sharing memory and passing a pointer (unsafe).
    - danShumway 8y ago
      Someone can correct me if I'm wrong[0], but I believe the proposal for shared linear memory allows importing multiple chunks. So assuming nothing changes and my understanding is correct, you'll just have to split your memory into two chunks; one that's safe to share and one that you keep private to your module. And of course, unless you're writing WASM yourself by hand (which is possible, but I don't know how many people are doing it), your compiler should handle all of this for you -- so at the point where Rust or whatever says, "we want to allow you to split your code into multiple WASM modules instead of just bundling it all into one", it would have to come up with some kind of allocation strategy for this. [0]: https://webassembly.org/docs/semantics/#linear-memory https://webassembly.org/docs/semantics/#linear-memory
      - panic 8y ago
        That's a link to the spec, which documents the fact that every memory operator refers to a single "default" linear memory (which can be shared or private). I don't think any of the features on the roadmap (https://webassembly.org/docs/future-features/ https://webassembly.org/docs/future-features/) include support for this kind of chunked memory. I agree that it would be very useful, though!
        danShumway 8y ago
        Linear memories (default or otherwise) can either be imported or defined inside the module. ... In the MVP, linear memory cannot be shared between threads of execution. The addition of threads :unicorn: will allow this. To me that sounds like, "define multiple linear memories, then import them after you instantiate the module." But I could be misinterpreting.

by Rusky 8y ago

pjmlp 8y ago

Right, but how can you trust a WebAssembly library? It might have been compiled from Ada, Rust or plain C, just as an example. Telling just to use a language we trust is not an option if one is just using other people libraries. Thus bringing to the web the same security level as depending on regular native libraries, because a regular user is not going to check what a web page depends on.

danShumway 8y ago
If you're bringing in multiple separate WASM libraries, they'll run separately from each other. Don't give them access to any memory they shouldn't have access to. Note that this is considerably better than Javascript, because without going out of your way to make an iframe, separate Javascript scripts aren't isolated from each other, so you don't know if one of them is modifying a prototype or hooking around other variables in the global scope. By default, separate WASM modules don't have access to the same memory.
- pjmlp 8y ago
  The whole point is about corrupting WASM modules INTERNAL memory via public exported functions, just because they happen to have typical out-of-bounds errors. Linux Security Summit 2018 had a report that 68% of kernel exploits are caused by out-of-bounds errors. User space doesn't write on kernel level, but can call syscalls, which happen to trigger such exploits. WebAssembly is no different, regardless how they are sandboxed between modules.
  - danShumway 8y ago
    If you have access to JS on the host system, why would you use such a roundabout, overcomplicated way to attack a module? Why wouldn't you just use JS to remove the WASM module, replace it with a malicious module you wrote, and then overwrite the exported functions? Safe pointers won't protect you from a malicious host environment. And like the original parent said, if you have code where you want safe pointers, use a language that requires them. Your module will be protected from any other WASM dependencies you bring in because they run in separate contexts and can't access each other. Don't give them access to critical memory. WASM makes this easy. You're just not protected from a compromised host environment -- but that's not new, that's the case for everything on the web. WASM protects the page from your module, not the other way around. Imagine that I'm running Linux, and I put Windows in a VM inside of Linux. Is it a problem that Linux could compromise or mess with my Windows VM? Of course not, that's intended -- the point of a VM is not to protect the system running inside the VM, it's to protect the system running outside of it. Maybe I don't understand what your threat model is. Are you worried about serverside code? I don't know that many people are really looking into running WASM on the serverside, and I don't see how the threat model is any different from writing a server in something like C++.
- panic 8y ago
  Not sharing memory is a pretty big restriction, though. For example, if you have variable-length data like a string, you can't pass it to a WASM module instance without either calling a function repeatedly for each data unit (slow) or sharing memory and passing a pointer (unsafe).
  - danShumway 8y ago
    Someone can correct me if I'm wrong[0], but I believe the proposal for shared linear memory allows importing multiple chunks. So assuming nothing changes and my understanding is correct, you'll just have to split your memory into two chunks; one that's safe to share and one that you keep private to your module. And of course, unless you're writing WASM yourself by hand (which is possible, but I don't know how many people are doing it), your compiler should handle all of this for you -- so at the point where Rust or whatever says, "we want to allow you to split your code into multiple WASM modules instead of just bundling it all into one", it would have to come up with some kind of allocation strategy for this. [0]: https://webassembly.org/docs/semantics/#linear-memory https://webassembly.org/docs/semantics/#linear-memory
    - panic 8y ago
      That's a link to the spec, which documents the fact that every memory operator refers to a single "default" linear memory (which can be shared or private). I don't think any of the features on the roadmap (https://webassembly.org/docs/future-features/ https://webassembly.org/docs/future-features/) include support for this kind of chunked memory. I agree that it would be very useful, though!
      - danShumway 8y ago
        Linear memories (default or otherwise) can either be imported or defined inside the module. ... In the MVP, linear memory cannot be shared between threads of execution. The addition of threads :unicorn: will allow this. To me that sounds like, "define multiple linear memories, then import them after you instantiate the module." But I could be misinterpreting.