6 ms·

I think the best summary of this paper (discussed last year as well [1]) is: Designers of the WebAssembly spec explicitly chose to scope its goal of a 'secure

I think the best summary of this paper (discussed last year as well [1]) is: Designers of the WebAssembly spec explicitly chose to scope its goal of a 'secure sandbox' to only include securing the host's memory from the WebAssembly VM. They have succeeded in this goal (modulo implementation deficiencies). However, they left open the question of how a developer might ensure the correctness of their program running in the sandbox. This paper explores the consequences of that original design goal for such a developer, and concludes that all the regular binary exploit mitigations may still be useful for ensuring program correctness. I made a comment at the time: > ... Notably, they don't appear to even try to break the WA-host memory barrier, which I actually find to be a validation of the core design goal of WebAssembly: isolate the damage a vulnerable program can inflict to the memory space (and thus also output) of that program. Protect the host from the program, but not the program from itself. Also, maybe don't dump WA output you can't validate directly into DOM. To which the paper's author replied: > ... I do agree with you, however, that our findings do not invalidate the overall design of WebAssembly. ... I also think "host security" (which we are not really looking into) is solid, with two qualifications: ... [1]: https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764

miohtama 6y ago
I do not understand the point of this paper. The correctness of the binary is the issue for a compiler, not for the run-time. It mainly discussed mitigations against legacy C code. E.g. new Rust code does not have these issues. Furthermore mitigating issues runtime has a performancy penalty and I do not want my code to be slower because some old C issues from back in the day.
- chubot 6y ago
  The point is that C compiled for the WebAssembly runtime is less secure than C in a traditional OS context, because of the lack of defenses on stack, heap, and control flow integrity. I agree it makes Rust more attractive than C for WebAssembly. But the original demos for WebAssembly were all in C, not Rust (games like Doom IIRC). The thing that made it attractive in the first place is that you could run existing code, e.g. image processing or machine learning in C/C++.
  - skyde 6y ago
    "secure against what"? Do you mean the script in the webpage running in my browser tab might be attacked by some virus already running on my computer? Or do you mean a virus running inside WebAssembly might attack my computer? If it's the first one, I dont think i really care.
    - sudosysgen 6y ago
      neither, the program might just crash or be buggy. Maybe in some rare cases do malicious things to the programs running in the sandbox.
    - aaronharnly 6y ago
      I think it’s more like: a script running in your browser tab, given some untrusted input (say, an image you import into an editing program) could be compromised by malicious input, such that the script runs malicious code and exfiltrates other data from the app (say, your email address or other private data you used on the page).
      - azakai 6y ago
        That's a definite risk in general. But worth adding that Wasm by design lets you statically inspect all the things the Wasm can call. If the Wasm receives access to networking, or eval(), etc., then there is a real risk. However, often the Wasm imports and exports are extremely limited and easy to verify for safety.
    - chubot 6y ago
      Section 5.1 gives a good example: an image sharing service that processes images using libpng. This has to be combined with a document.write() of HTML in C, which is realistic. Someone who controls the image data can perform an XSS, i.e. steal your credentials for the website, or your credit card info if that's stored server-side. That's not as valuable a target as controlling your computer, but it's not nothing, and can be chained. This is completely realistic as Figma is full blown image editor written in C++ compiled to WebAssembly :) https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
- infogulch 6y ago
  I agree that the paper's title is somewhat overblown, especially the prefix "Everything Old Is New Again". Specifically, "old" things like all VM runtimes being directly vulnerable to malicious code is not carried over by WA -- to the contrary, WA seems to have captial-S Solved this problem which is certainly an advance. That said, it does highlight that memory-safe source languages and other program exploit mitigations are still important even in a webassembly sandbox. Personally I wasn't confused about this fact, but it does clarify this point for any that might think that WA == no more security problems in any context.
- eyberg 6y ago
  > The correctness of the binary is the issue for a compiler, not for the run-time . That is not true. As the paper goes into depth, linear memory, lack of ASLR, and the lack of read-only memory are problematic regardless. The latter is the most important imo.
- daniellehmann 6y ago
  Daniel here, one of the authors. You are right, some of the issues highlighted in the paper could be solved by compilers targeting WebAssembly. One such mitigation that is (currently) missing are stack canaries. In contrast, stack canaries are typically employed by compilers when targeting native architectures. They also cost performance there (typically single digit percentages), but evidently compiler authors have decided that this cost is worth the added security benefit, since fixing "old C issues" in all legacy code in existence is not realistic. Note however, that other security issues highlighted in the paper _are_ characteristics of the language, notably linear memory without page protection flags. One consequence of this design is that there is no way of having "truly constant" memory -- everything is always writable. I do think that this is surprising and certainly weaker than virtual memory in native programs, where you _cannot_ overwrite the value of string literals at runtime.
  - titzer 6y ago
    The decision to not (yet) have finer-grained protection for WebAssembly memory pages was in part motivated by the JS API surface in the web embedding. WebAssembly memories are exposed to JS as ArrayBuffers, and optimizing JITs can and do optimize ArrayBuffer access down to naked stores and loads. In addition to the optimized JIT code, ArrayBuffers are used throughout the webstack for moving data into and out of programs (read: Chrome's 6 million lines of code). The entire webstack is not really prepared for read-only ArrayBuffers causing signals underneath. That said, we always knew a day would come where WebAssembly would get the ability to set more page protections. For non-web embeddings, this is easier, but as of yet, none of the engines I know of have either an API or are really prepared for the implications of this. I am still bullish on eventually getting that capability, though. Thanks for your paper.
    - daniellehmann 6y ago
      Thanks a lot for the additional background, and also for all the work on WebAssembly. It is a very cool language and having it available with linear memory now is much better than if it were still in the works due to figuring out page protections. As you said, I just hope page protections can still be added later (somebody needs to specify it, embedders need to be able to implement them, toolchains need to pick it up, etc.). Maybe memory vulnerabilities inside WebAssembly programs can also be mitigated in other ways that do not require such pervasive changes, e.g., by keeping modules small and compiling each "protection domain" (e.g., library) into its own module, or to have a separate memory. I am not sure about the performance cost of such an approach, though.

miohtama 6y ago

I do not understand the point of this paper. The correctness of the binary is the issue for a compiler, not for the run-time. It mainly discussed mitigations against legacy C code. E.g. new Rust code does not have these issues. Furthermore mitigating issues runtime has a performancy penalty and I do not want my code to be slower because some old C issues from back in the day.

chubot 6y ago
The point is that C compiled for the WebAssembly runtime is less secure than C in a traditional OS context, because of the lack of defenses on stack, heap, and control flow integrity. I agree it makes Rust more attractive than C for WebAssembly. But the original demos for WebAssembly were all in C, not Rust (games like Doom IIRC). The thing that made it attractive in the first place is that you could run existing code, e.g. image processing or machine learning in C/C++.
- skyde 6y ago
  "secure against what"? Do you mean the script in the webpage running in my browser tab might be attacked by some virus already running on my computer? Or do you mean a virus running inside WebAssembly might attack my computer? If it's the first one, I dont think i really care.
  - sudosysgen 6y ago
    neither, the program might just crash or be buggy. Maybe in some rare cases do malicious things to the programs running in the sandbox.
  - aaronharnly 6y ago
    I think it’s more like: a script running in your browser tab, given some untrusted input (say, an image you import into an editing program) could be compromised by malicious input, such that the script runs malicious code and exfiltrates other data from the app (say, your email address or other private data you used on the page).
    - azakai 6y ago
      That's a definite risk in general. But worth adding that Wasm by design lets you statically inspect all the things the Wasm can call. If the Wasm receives access to networking, or eval(), etc., then there is a real risk. However, often the Wasm imports and exports are extremely limited and easy to verify for safety.
  - chubot 6y ago
    Section 5.1 gives a good example: an image sharing service that processes images using libpng. This has to be combined with a document.write() of HTML in C, which is realistic. Someone who controls the image data can perform an XSS, i.e. steal your credentials for the website, or your credit card info if that's stored server-side. That's not as valuable a target as controlling your computer, but it's not nothing, and can be chained. This is completely realistic as Figma is full blown image editor written in C++ compiled to WebAssembly :) https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
infogulch 6y ago
I agree that the paper's title is somewhat overblown, especially the prefix "Everything Old Is New Again". Specifically, "old" things like all VM runtimes being directly vulnerable to malicious code is not carried over by WA -- to the contrary, WA seems to have captial-S Solved this problem which is certainly an advance. That said, it does highlight that memory-safe source languages and other program exploit mitigations are still important even in a webassembly sandbox. Personally I wasn't confused about this fact, but it does clarify this point for any that might think that WA == no more security problems in any context.
eyberg 6y ago
> The correctness of the binary is the issue for a compiler, not for the run-time . That is not true. As the paper goes into depth, linear memory, lack of ASLR, and the lack of read-only memory are problematic regardless. The latter is the most important imo.
daniellehmann 6y ago
Daniel here, one of the authors. You are right, some of the issues highlighted in the paper could be solved by compilers targeting WebAssembly. One such mitigation that is (currently) missing are stack canaries. In contrast, stack canaries are typically employed by compilers when targeting native architectures. They also cost performance there (typically single digit percentages), but evidently compiler authors have decided that this cost is worth the added security benefit, since fixing "old C issues" in all legacy code in existence is not realistic. Note however, that other security issues highlighted in the paper _are_ characteristics of the language, notably linear memory without page protection flags. One consequence of this design is that there is no way of having "truly constant" memory -- everything is always writable. I do think that this is surprising and certainly weaker than virtual memory in native programs, where you _cannot_ overwrite the value of string literals at runtime.
- titzer 6y ago
  The decision to not (yet) have finer-grained protection for WebAssembly memory pages was in part motivated by the JS API surface in the web embedding. WebAssembly memories are exposed to JS as ArrayBuffers, and optimizing JITs can and do optimize ArrayBuffer access down to naked stores and loads. In addition to the optimized JIT code, ArrayBuffers are used throughout the webstack for moving data into and out of programs (read: Chrome's 6 million lines of code). The entire webstack is not really prepared for read-only ArrayBuffers causing signals underneath. That said, we always knew a day would come where WebAssembly would get the ability to set more page protections. For non-web embeddings, this is easier, but as of yet, none of the engines I know of have either an API or are really prepared for the implications of this. I am still bullish on eventually getting that capability, though. Thanks for your paper.
  - daniellehmann 6y ago
    Thanks a lot for the additional background, and also for all the work on WebAssembly. It is a very cool language and having it available with linear memory now is much better than if it were still in the works due to figuring out page protections. As you said, I just hope page protections can still be added later (somebody needs to specify it, embedders need to be able to implement them, toolchains need to pick it up, etc.). Maybe memory vulnerabilities inside WebAssembly programs can also be mitigated in other ways that do not require such pervasive changes, e.g., by keeping modules small and compiling each "protection domain" (e.g., library) into its own module, or to have a separate memory. I am not sure about the performance cost of such an approach, though.