3 ms·

WASM started making is way into browsers just as we removed the last remnants of Java Applets. Now we have too re-secure a whole new stack.

• overthrow 4y ago
  At least WASM is first-party code written by the browser developers. I'll take that any day over a pile of third-party plugins.
• naikrovek 4y ago
  the WASM people knew that going in and it's part of the design. it's also why WASM is so slow compared to native executables; security guarantees have a performance cost.
  • pjmlp 4y ago
    Yet several security issues still aren't taken care of, https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... https://www.usenix.org/conference/usenixsecurity21/presentation/narayan https://www.usenix.org/conference/usenixsecurity21/presentat...
    • naikrovek 4y ago
      well it's not perfect, no. my point stands though. WASM is not ActiveX where the whole applet has admin permission on the computer.
      • pjmlp 4y ago
        In abstract, in practice it depends on which runtime is being used.
    • marcosdumay 4y ago
      Hum... You are aware that those are one where the attacker gains execution capabilities inside the sandbox and one hardware vulnerability that affects every single language, right?
      • pjmlp 4y ago
        Gaining execution capabilities inside the sandbox is already good enough to compromise its behaviour, e.g. everyone gets true back when is_admin() gets called. More devs should get security trainings.
        • marcosdumay 4y ago
          Yes, but it's a complete mischaracterization to claim it's a failure of the sandbox. On this specific case, it is quite a big deal to add write and execute controls to the WASM memory, so it requires further justification than "I can do stack underflow attacks on my C code". Even though "I can do stack underflow attacks on my C code" is relevant information.