4 ms·

Pardon my wasm illiteracy here, what exactly makes it more secure? Struggling to see it.

• earenndil 7y ago
  Sandboxing is trivial, because you can cover all paths to the outside world.
  • DarthGhandi 7y ago
    I edited my earlier comment to remove the sandboxing part thinking this may be embedded specific, so not sure you saw that, so ask again how is this special? would you rather inspect potentially malicious wasm or js?
• 29athrowaway 7y ago
  All web APIs are designed to be secure in the context of the web. Needs to be memory safe otherwise a wasm program can execute arbitrary code, access memory that it should not, etc.
• ridiculous_fish 7y ago
  WASM has a sandboxing model. The idea is: 1. Control flow is always checked. You can't jump to an arbitrary address, you jump to index N in a control flow table. 2. Calls out of the sandbox are also table based. 3. Indexed accesses are bounds checked. On 64 bit platforms, this is achieved by demoting the wasm to 32 bit and using big guard pages. On 32 bit platforms, it's explicit compares. The result is something which may become internally inconsistent (can Heartbleed) but cannot perform arbitrary accesses to host memory.
  • tasogare 7y ago
    How is that different from CLR or JVM?
    • ridiculous_fish 7y ago
      I'll speak to JVM; I'm less familiar with CLR but I believe it's the same. JVM and WASM both have statically-verifiable control flow. No wild jumps, no executable stacks, etc. Phew. Arrays and pointer arithmetic are a big difference. WASM has a big linear memory block, and instructions may access arbitrary locations within it - the runtime performs bounds checking only at the edges. So your `sprintf` can still overflow the buffer, and smash the stack's data, but can't affect the host, or the control flow. JVM goes further: it prohibits pointer arithmetic and pushes array accesses down into the instruction stream. To access a JVM array, you must provide the array reference itself, and the runtime will perform bounds checking using the length. The JVM approach gives you better runtime safety - no Heartbleed! The WASM approach is lower-level and is more easily adapted to existing system languages: C++, Rust, other LLVMites.
      • pjmlp 7y ago
        CLR was designed to support C++ since day one. And while WASM trumps the security trumpet, without actually supporting proper bounds checking, the CLR will taint C++ pointer arithmetic as unsafe, thus making the whole module unsafe. So I as consumer can decide if I am willing to trust an unsafe module or not.
        • johncolanduoni 7y ago
          The CLR doesn’t guarantee control flow integrity (modulo type confusion) or any form of isolation when linear memory accesses are used. So here WASM offers another option in the middle between trust and don’t trust: “trust unsafe module only to not compromise its own functionality; no attacking the rest of the process or kernel” (modulo runtime bugs).
          • pjmlp 7y ago
            Well for that execution of unsafe Assemblies was already enabled anyway, so there isn't much that the verifier can do. Which is something that WASM isn't being honest about, corruption of internal data structures is allowed. If I can control what goes into memory just by calling module public functions with the right data set and access patterns, CFI won't help a thing. Suddenly the authorization module that would authenticate me as regular user, might give me another set of capabilities and off to the races.
  • pjmlp 7y ago
    Internally inconsistency is already good enough for possible security exploits, by making the module reveal stuff that would otherwise be forbidden.
    • cfallin 7y ago
      That's not the goal of a VM/runtime, though: it only ensures that the hosted code cannot escape the sandbox, and provides a correct implementation of the semantics of each VM opcode. The hosted code's computation implemented with those opcodes is a black box to the VM. Consider: should the VM somehow try to analyze the running code and determine when it's about to commit a logical error and return "forbidden" data? What specification states which data is forbidden? Consider: even the most high-level VM can execute a program with logical errors if it is Turing-complete. A Java or Erlang program running on a bug-free, fully-compliant implementation of the respective VM can still get (e.g.) an authorization condition wrong, or incorrectly implement a security protocol, or return data from the wrong (in-bounds, but wrong!) index in an array.
      • pjmlp 7y ago
        Indeed, what WASM advocates cannot do is advocate safety, that it is better than any other bytecode format since 1958, when it isn't so. Secondly, it could have been designed with bounds checking for any kind of data access. The CLR is honest about it, when C++/CLI uses C style low level tricks, the Assembly is considered tainted and requires explicit allowance of unsafe assemblies execution. An idea that goes back to Burroughs B5000, where tainted binaries (code using unsafe code blocks) requires admin permission for execution.
• sanxiyn 7y ago
  Unlike in x86 or ARM assembly, you can't overwrite the return address in WebAssembly.