4 ms·

Will WebAssembly save us from this kind of CVEs? assuming it has capabilities to support "modern" web

by tester756 5y ago

dchest 5y ago
No, on the contrary, it makes the attack surface larger.
- tester756 5y ago
  How?
  - FastEatSlow 5y ago
    Web assembly is extra code and complexity in a web browser compared to one without, so there are more potential vulnerabilities
    - tester756 5y ago
      I don't buy it because you can apply same reasoning to every new / changed line of code, yet it ain't always true The question is, is WASM's security model / sandbox "safer" / "easier to actually execute" than JS'?
      - vbezhenar 5y ago
        It does not matter because JS is not going anywhere. Whether it’s more secure or not, it’s still additional attack surface.
        tester756 5y ago
        I believe it does Of course JS ain't gonna go anywhere now, but if popular JS frameworks started emitting WebAssembly behind the scenes, so devs could still write their JS(and C++/C#/etc) code, but it'd use WASM under the hood then that'd start process of the deprecation of JS. Which would mean that after all popular JS frameworks managed to migrate and popular sites adopted to this, then in ideal world you'd be able to turn off javascript and still use those sites/apps via WASM, not by default for everyone, but at least users that care would have an option to do so while still being able to use the web. You gotta start somewhere I'm wrong somewhere? or out of the touch with reality?
        dchest 5y ago
        Perhaps, you can start by learning what WASM is: https://developer.mozilla.org/en-US/docs/WebAssembly https://developer.mozilla.org/en-US/docs/WebAssembly As for vulnerabilities, here are nccgroup's slides about WASM explots: https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web.pdf https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-... Here's an example vulnerability in WASM parsing leading to RCE: https://labs.f-secure.com/assets/BlogFiles/apple-safari-wasm-section-vuln-write-up-2018-04-16.pdf https://labs.f-secure.com/assets/BlogFiles/apple-safari-wasm...
        vbezhenar 5y ago
        If we're talking about 20 years from now, nobody cares about popular frameworks. Huge majority of websites use old code and they must not break. Backwards compatibility of web is a huge deal. So deprecation of JS just will not happen in that period of time. What could happen is that browsers will support wasm natively and they'll translate JS into wasm. I'm not qualified enough to judge whether it would be possible to achieve current levels of JS performance with that approach, but theoretically it could be possible. In this case only wasm security will matter. But I did not hear about any kinds of those plans, those are just my wild speculations. So deprecating of JS is not going to happen anytime soon. Wasm will accompany JS and that's about it for the foreseeable future.
      - azinman2 5y ago
        WASM _IS_ JS. Some browsers do things to make it run faster. JS runs in its own security sandbox and is already suppose to be safe. Browsers get exploited in all kinds of ways, and IIRC, there have been WASM-specific exploits as well in the past. Your question is non-sensical as is. I think you need to expand it to have people be less confused as to what you’re asking.
  - hyperhopper 5y ago
    Before you had JS. Now you have JS + Web Assembly. The second one is bigger.
wolverine876 5y ago
How will WebAssembly save us?
- tester756 5y ago
  I'm asking
  - lucb1e 5y ago
    But why ask? Why not ask why we can't use forests or jquery to prevent these attacks? What is the logic here, how do you think it might work, even just vaguely if you don't have a worked-out solution? Edit: from another comment in a sibling thread, you indicate thinking that WASM has a "security model / sandbox". That would have been (part of) the answer to the grandparent comment I suppose.
    - tester756 5y ago
      My logic was here that WASM was created/designed by companies that do maintain browsers - Mozilla Microsoft Google Apple and it is marketed as "WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser." Basically I felt like it was designed with security in mind and I do wonder whether it'd prevent attacks like this
      - jhugo 5y ago
        If it helps, think of the sandbox as being at the border between "outside" and "inside", and the choice between JS and WASM being on the "inside". Changing the language/runtime within the sandbox doesn't change much if your sandbox is compromised. On the contrary, that extra code to parse WASM etc is just additional risk.
PoignardAzur 5y ago
So far WebAssembly implementations look fairly secure, thanks to a small attack surface. AFAICT WebAssembly CVEs are mostly DoS. And WebAssembly has been used by Mozilla for sandboxing: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... So it may help. But wasm is never going to be eg a substitute for JS, so it's not going to "save us" the way you imply.
ytpete 5y ago
I'm not sure WASM buys you anything you couldn't already get by just running your whole entire app in a VM. And if walling an app off in a VM makes it not useful (i.e. it's not useful if all it has access to is network & sandboxed storage) then using WASM in a browser would have similar issues. Or if a VM adds too much performance penalty then WASM probably does too.

Will WebAssembly save us from this kind of CVEs? assuming it has capabilities to support "modern" web

dchest 5y ago

No, on the contrary, it makes the attack surface larger.

tester756 5y ago
How?
- FastEatSlow 5y ago
  Web assembly is extra code and complexity in a web browser compared to one without, so there are more potential vulnerabilities
  - tester756 5y ago
    I don't buy it because you can apply same reasoning to every new / changed line of code, yet it ain't always true The question is, is WASM's security model / sandbox "safer" / "easier to actually execute" than JS'?
    - vbezhenar 5y ago
      It does not matter because JS is not going anywhere. Whether it’s more secure or not, it’s still additional attack surface.
      - tester756 5y ago
        I believe it does Of course JS ain't gonna go anywhere now, but if popular JS frameworks started emitting WebAssembly behind the scenes, so devs could still write their JS(and C++/C#/etc) code, but it'd use WASM under the hood then that'd start process of the deprecation of JS. Which would mean that after all popular JS frameworks managed to migrate and popular sites adopted to this, then in ideal world you'd be able to turn off javascript and still use those sites/apps via WASM, not by default for everyone, but at least users that care would have an option to do so while still being able to use the web. You gotta start somewhere I'm wrong somewhere? or out of the touch with reality?
        dchest 5y ago
        Perhaps, you can start by learning what WASM is: https://developer.mozilla.org/en-US/docs/WebAssembly https://developer.mozilla.org/en-US/docs/WebAssembly As for vulnerabilities, here are nccgroup's slides about WASM explots: https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web.pdf https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-... Here's an example vulnerability in WASM parsing leading to RCE: https://labs.f-secure.com/assets/BlogFiles/apple-safari-wasm-section-vuln-write-up-2018-04-16.pdf https://labs.f-secure.com/assets/BlogFiles/apple-safari-wasm...
        vbezhenar 5y ago
        If we're talking about 20 years from now, nobody cares about popular frameworks. Huge majority of websites use old code and they must not break. Backwards compatibility of web is a huge deal. So deprecation of JS just will not happen in that period of time. What could happen is that browsers will support wasm natively and they'll translate JS into wasm. I'm not qualified enough to judge whether it would be possible to achieve current levels of JS performance with that approach, but theoretically it could be possible. In this case only wasm security will matter. But I did not hear about any kinds of those plans, those are just my wild speculations. So deprecating of JS is not going to happen anytime soon. Wasm will accompany JS and that's about it for the foreseeable future.
    - azinman2 5y ago
      WASM _IS_ JS. Some browsers do things to make it run faster. JS runs in its own security sandbox and is already suppose to be safe. Browsers get exploited in all kinds of ways, and IIRC, there have been WASM-specific exploits as well in the past. Your question is non-sensical as is. I think you need to expand it to have people be less confused as to what you’re asking.
- hyperhopper 5y ago
  Before you had JS. Now you have JS + Web Assembly. The second one is bigger.

wolverine876 5y ago

How will WebAssembly save us?

tester756 5y ago
I'm asking
- lucb1e 5y ago
  But why ask? Why not ask why we can't use forests or jquery to prevent these attacks? What is the logic here, how do you think it might work, even just vaguely if you don't have a worked-out solution? Edit: from another comment in a sibling thread, you indicate thinking that WASM has a "security model / sandbox". That would have been (part of) the answer to the grandparent comment I suppose.
  - tester756 5y ago
    My logic was here that WASM was created/designed by companies that do maintain browsers - Mozilla Microsoft Google Apple and it is marketed as "WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser." Basically I felt like it was designed with security in mind and I do wonder whether it'd prevent attacks like this
    - jhugo 5y ago
      If it helps, think of the sandbox as being at the border between "outside" and "inside", and the choice between JS and WASM being on the "inside". Changing the language/runtime within the sandbox doesn't change much if your sandbox is compromised. On the contrary, that extra code to parse WASM etc is just additional risk.

PoignardAzur 5y ago

So far WebAssembly implementations look fairly secure, thanks to a small attack surface. AFAICT WebAssembly CVEs are mostly DoS. And WebAssembly has been used by Mozilla for sandboxing: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... So it may help. But wasm is never going to be eg a substitute for JS, so it's not going to "save us" the way you imply.

ytpete 5y ago

I'm not sure WASM buys you anything you couldn't already get by just running your whole entire app in a VM. And if walling an app off in a VM makes it not useful (i.e. it's not useful if all it has access to is network & sandboxed storage) then using WASM in a browser would have similar issues. Or if a VM adds too much performance penalty then WASM probably does too.