5 ms·

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

by 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-...
  - skyde 6y ago
    "Someone who controls the image data" to me that sound like something outside the sandbox manipulating the image data given to the sandbox. If this is the case it mean there is already a hacker or virus running outside the sandbox which mean I already have bigger problem to worry about :).
    - tasogare 6y ago
      No, it means a random user can upload a malicious image and hack the service.
emn13 6y ago
I think that's grossly overstating things. I'd put it this way: C compiled for the WebAssembly runtime is more secure than C in a traditional OS context, however, it has fewer defenses available that protect the program against it's own bugs, including those triggered maliciously. That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two normal programs. The host has better protection from a WASM program than a C program. Those protections are akin to a VMs, but likely better. The protections that are missing aren't irrelevant, but likely less relevant than in an OS context because WASM's I/O is so heavily constrained. Malicious data is still a possibility, but not quite as trivially triggerable as in any other networked program. Similarly, once hacked, those same limitations make the scope for mischief much, much more limited. Sure, there are attacks conceivable against a WASM program that couldn't work when protected by various defenses in depth available to a "normal" OS program, but the reverse is true too - if you will; the scope of bugs is much, much smaller in WASM, but within that limited scope they'll be more easily triggerable. However, since the scope is so limited, I have a hard time believing the net effect is negative in practice.
- chubot 6y ago
  Yeah that's fair, WASM I/O is basically "opt in", where as the I/O on an normal OS is basically "opt out" (with something like seccomp, or not at all). WASM does follow the principle of least privilege better.
- staticassertion 6y ago
  > two WASM programs will be more strongly isolated from one another than two normal programs. Innocent and naive as I am, I feel like this shouldn't be true in a post-spectre world? Surely intra-process isolation is recognized as, at minimum, a difficult problem to solve today? The attack surface of your host, given arbitrary compute powers (which wasm has), is quite significant. It's not to say that intra-process isolation isn't a worthwhile goal, I'd rather see new systems designed with the idea if they can be. I'm just saying I don't know that "unsandboxed but has lots of mitigations" vs "sandboxed but trivially exploitable" is so clearcut.

by chubot 6y ago

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-...
- skyde 6y ago
  "Someone who controls the image data" to me that sound like something outside the sandbox manipulating the image data given to the sandbox. If this is the case it mean there is already a hacker or virus running outside the sandbox which mean I already have bigger problem to worry about :).
  - tasogare 6y ago
    No, it means a random user can upload a malicious image and hack the service.

emn13 6y ago

I think that's grossly overstating things. I'd put it this way: C compiled for the WebAssembly runtime is more secure than C in a traditional OS context, however, it has fewer defenses available that protect the program against it's own bugs, including those triggered maliciously. That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two normal programs. The host has better protection from a WASM program than a C program. Those protections are akin to a VMs, but likely better. The protections that are missing aren't irrelevant, but likely less relevant than in an OS context because WASM's I/O is so heavily constrained. Malicious data is still a possibility, but not quite as trivially triggerable as in any other networked program. Similarly, once hacked, those same limitations make the scope for mischief much, much more limited. Sure, there are attacks conceivable against a WASM program that couldn't work when protected by various defenses in depth available to a "normal" OS program, but the reverse is true too - if you will; the scope of bugs is much, much smaller in WASM, but within that limited scope they'll be more easily triggerable. However, since the scope is so limited, I have a hard time believing the net effect is negative in practice.

chubot 6y ago
Yeah that's fair, WASM I/O is basically "opt in", where as the I/O on an normal OS is basically "opt out" (with something like seccomp, or not at all). WASM does follow the principle of least privilege better.
staticassertion 6y ago
> two WASM programs will be more strongly isolated from one another than two normal programs. Innocent and naive as I am, I feel like this shouldn't be true in a post-spectre world? Surely intra-process isolation is recognized as, at minimum, a difficult problem to solve today? The attack surface of your host, given arbitrary compute powers (which wasm has), is quite significant. It's not to say that intra-process isolation isn't a worthwhile goal, I'd rather see new systems designed with the idea if they can be. I'm just saying I don't know that "unsandboxed but has lots of mitigations" vs "sandboxed but trivially exploitable" is so clearcut.