7 ms·

I'm sure there will be exploits, as the attack surface will become bigger. But isn't wasm designed from the ground up to be sandboxed in a certain memory space

I'm sure there will be exploits, as the attack surface will become bigger. But isn't wasm designed from the ground up to be sandboxed in a certain memory space? And won't that prevent buffer overruns from gaining access to other parts of the browser?

pjmlp 8y ago
Yes it is sanboxed, but the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled.
- magicalist 8y ago
  > the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled. it can be, but there are large classes of security issues that aren't possible like they usually are with those languages. eg it's not possible to jump to arbitrary locations, you can't write to executable memory, etc. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
  - pjmlp 8y ago
    Still not having bounds protection is a very big one, and 40 years of CVE history doesn't help.
    - vardump 8y ago
      WebAssembly does have bounds checking, you can't write outside the designated memory block. On 64-bit systems with virtual address space to spare, you can offload bounds checking to MMU by memory mapping 2 GB+ protection zone both below and above the exposed memory region. If you then limit all pointers/offsets to 32-bit, there should be no direct way to corrupt anything else. You can't reach anything interesting within 32-bit offsets. Of course one can corrupt WebAssembly instance memory all they want, but it won't matter. Performance and security win. Left CPU bugs outside consideration, hopefully those can be addressed in WASM codegen. Not like it's that different from current Javascript JIT cases.
      - pjmlp 8y ago
        The memory block contains all data together in well, a block, thus you can happily overwrite two neighbouring arrays, unless I am missing something here WebAssembly does not have fat pointers.
        vardump 8y ago
        Sure, you can corrupt all the data in your instance. You can't overwrite code or the true call stack, so what's the (security) risk?
        pjmlp 8y ago
        Funny question, basically with corrupted data anything goes. For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor. But yeah, code and true call stack will be perfectly safe.
        vardump 8y ago
        One day a random bit flip in a web app on a non ECC-protected iPad * controlling a life-critical system will kill a person. It's just a matter of time. * Or any other device with data corrupting hardware or software issues.
        pjmlp 8y ago
        Yep it is just a matter of time. Successful lawsuits against insecure software need to become a common event until most companies actually start paying attention to their technology stack and development processes.
        ubercow13 8y ago
        Is that a security risk? That could just happen due to a logic bug.

pjmlp 8y ago

Yes it is sanboxed, but the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled.

magicalist 8y ago
> the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled. it can be, but there are large classes of security issues that aren't possible like they usually are with those languages. eg it's not possible to jump to arbitrary locations, you can't write to executable memory, etc. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
- pjmlp 8y ago
  Still not having bounds protection is a very big one, and 40 years of CVE history doesn't help.
  - vardump 8y ago
    WebAssembly does have bounds checking, you can't write outside the designated memory block. On 64-bit systems with virtual address space to spare, you can offload bounds checking to MMU by memory mapping 2 GB+ protection zone both below and above the exposed memory region. If you then limit all pointers/offsets to 32-bit, there should be no direct way to corrupt anything else. You can't reach anything interesting within 32-bit offsets. Of course one can corrupt WebAssembly instance memory all they want, but it won't matter. Performance and security win. Left CPU bugs outside consideration, hopefully those can be addressed in WASM codegen. Not like it's that different from current Javascript JIT cases.
    - pjmlp 8y ago
      The memory block contains all data together in well, a block, thus you can happily overwrite two neighbouring arrays, unless I am missing something here WebAssembly does not have fat pointers.
      - vardump 8y ago
        Sure, you can corrupt all the data in your instance. You can't overwrite code or the true call stack, so what's the (security) risk?
        pjmlp 8y ago
        Funny question, basically with corrupted data anything goes. For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor. But yeah, code and true call stack will be perfectly safe.
        vardump 8y ago
        One day a random bit flip in a web app on a non ECC-protected iPad * controlling a life-critical system will kill a person. It's just a matter of time. * Or any other device with data corrupting hardware or software issues.
        pjmlp 8y ago
        Yep it is just a matter of time. Successful lawsuits against insecure software need to become a common event until most companies actually start paying attention to their technology stack and development processes.
        ubercow13 8y ago
        Is that a security risk? That could just happen due to a logic bug.