1. 19
  1. 4

    Very useful line of research, and it would be nice to have these sorts of concerns guide future development of wasm. Some of it is predicated on other features that are still being developed; for example, multiple memory sections would make hard separation of stack and heap data possible, and open the door to being able to mark memories read-only.

    That said, this also seems to cast wasm in a worse light than it needs to, because as far as I understand things like stack canaries and FORTIFY_SOURCE are the responsibility of the compiler outputting the wasm, not wasm itself. What is the instruction set supposed to do about those sorts of things?

    1. 1

      I suppose WASM runtimes could implement stack canaries themselve automatically for each call and function returns instruction. However this is pushing complexity into the core runtime that could (should?) be done from compiler emitted instruction so I don’t see as well what WASM is lacking other than ASLR and paging.

    2. 1

      I think we’re not worried about the WASM blobs being exploited, we’re worried about them doing the exploiting. The whole idea with WASM is a tradeoff to reduce what the evil nonfree blob out of our contral can do to a system. If I can reach in an exploit the blob… isn’t that a win for me?

      1. 2

        If I can reach in an exploit the blob… isn’t that a win for me?

        What would you win from that? You download and run the blob. If you want to change the blob behaviour you are free to modify it as you wish, exploiting it makes no sense in this context.

        You can worry about WASM blob exploitation because it might allow unexpected behaviour from something you trust. Let’s say you use a file-sharing service with a blob to decompress files. Someone sends you an arbitrary file that exploit this blob and ends up running arbitrary Javascript in your browser, stealing your session and other files you might store in there.

        Exploiting a WASM module is a very complicated way to have an XSS. An XSS in your browser usually means you get your session or data stolen. In NodeJS this means server code execution.

        1. 1

          Hm I don’t understand this framing. Some more comments:


          The point of WASM to me was to introduce the functionality and speed of native code on the web, like say the PNG decoder example given in the paper. But as they show, that has significant caveats and downsides.