3 ms·

tangentially related, but could anybody give me the TLDR on whether increased usage of WASM on the internet is expected to open up a new slew of security vulner

by tbm57 3y ago

tangentially related, but could anybody give me the TLDR on whether increased usage of WASM on the internet is expected to open up a new slew of security vulnerabilities for users? Someone posted on here before that even JS was controversial during its adoption (and now for some users), I can only imagine that some of those concerns are multiplied when you're talking about something with such broad capabilities as WASM

afiori 3y ago
For now wasm does not have any more risk than obfuscated JS. It is possible that there are a lot of tool to examine JS code for "suspicious code" and that those tools might not work well on WASM. In practice the WASM interpreter in the browser is a functionality that can be (almost) completely polyfilled. Personally I would be way more worries about hardware exploits via WebGL.
- afiori 3y ago
  Also it is likely that the browser debugger will be less feturefull for wasm and that future multithreaded support will make obfuscation even easier. But it is probably already possible with JSFuck and webworkers.
paulgb 3y ago
WebAssembly running in the browser runs in an isolated environment whose only access to the outside world is by calling out to JavaScript functions exposed to it when it was initialized. So it doesn’t open up any new APIs. It does get recompiled to bytecode that runs directly on the processor, so in theory there could be vulnerabilities that come up from that, but I think it’s a pretty well-understood surface area at this point.
- folkrav 3y ago
  I know it's not fundamentally that different from the running arbitrary code we have right now, but something about the idea of indiscriminately running binaries invisibly downloaded over the WWW rubs me the wrong way. Edit: read the first half of my sentence again.
  - dymk 3y ago
    That’s what we’ve been doing since the dawn of JavaScript, in a VM with a much larger surface area. A simper VM should be quite a bit safer than the status-quo.
  - codeflo 3y ago
    > something about the idea of indiscriminately running binaries invisibly downloaded over the WWW rubs me the wrong way I think that's because the word "binary" has connotations that aren't strictly technically justified. There's no difference between running WASM and running JS (which is usually obfuscated anyway). Both are JITted into machine code, and it's important the JIT is implemented securely. (JIT compilers have been sources of exploits.) The only difference is complexity of the source language, where simpler languages are easier to secure. And WASM is orders of magnitude simpler than JS.
  - lumb63 3y ago
    I have some bad news for you…
  - afiori 3y ago
    I believe wasm will allow for far greater opportunities for code obfustation. You can already do things like http://www.jsfuck.com/ http://www.jsfuck.com/ and even more complex ones, but they would likely have bad performace. With wasm you could do malware-level obfuscation with less drawbacks.
Jweb_Guru 3y ago
WASM's runtime is far simpler than JS's, or even something like the JVM, particularly due to lack of garbage collection. The language was deliberately designed to be straightforward and efficient to JIT compile to a safe virtual machine, e.g. attention was paid to making sure bounds checking could be elided efficiently for constant offsets while being enabled elsewhere. It's also significantly simplified compared to assembly, and lacks functionality like arbitrary jumps that are common sources of vulnerabilities. It's pretty much ideal for the usecase of "I want to run pretty fast code on an untrusted machine" which is the main reason it's taking off. (Obviously, as WASM JIT compilers get more elaborate and it incorporates things like GC'd references, some of the advantages of this design wrt simplicity will disappear, but I anticipate that these kinds of features will mostly not be used in settings like databases).
- malkia 3y ago
  Dart/flutter can now target wasm (unstable), so better gc support is coming (e.g. not gc running from whatever you compiled, but rather the wasm vm would do for you)
kevingadd 3y ago
WASM being used to exploit your PC isn't much of a risk, because it has a really robust security model. It's been used in exploit chains before but my understanding is that the number of times people have found holes in WASM sandboxes is much smaller than the number of times people have found holes in JS runtimes. So it's pretty fit for purpose there. Unfortunately, the design of WASM and common compilers targeting it means that your security is at risk as a user, even though your PC is safe. Applications compiled to WASM have a wide variety of fun security vulnerabilities that have been gone on native targets for decades, which means that if (for example) Gmail moved to WASM, it would now be possible for malicious parties to attack your Gmail tab even though they can't attack your PC. Some examples: * Address space layout randomization is gone - if an attacker gets a write-anwyhere primitive, it will work 100% of the time * Function pointers are densely packed - any possible value within the correct range (0 - function count) is a valid function pointer, as long as the signature matches. Even worse than not having ASLR. * Page protections are gone - all data is mutable, even things that shouldn't be like string constants compiled into the binary * Zero page accesses don't trap - while compilers go out of their way to try and make reading/writing from null pointers fail in WASM, the actual runtime happily allows you to do it. This makes attacks easier to execute because while stray nulls would kill a native application on dereference, in WASM they will just yield a 0 and execution will often continue. * Most stuff is static linked - for native applications, it is common (albeit less common now in our modern era of Electron Hell) to pull in services from the OS and its packages, whether it's zlib or https or whatnot. The WASM runtime model generally offers a very limited set of capabilities in comparison, and there's no equivalent way to dynamically link against vendored packages that get security updates automatically. So every application ships its own ICU (for time zone and localization data), ships its own zlib (for compression/decompression), ships its own crypto (because the browser crypto APIs are extremely limited and async-only), etc... Ultimately WebAssembly runtimes are very secure, but you have to protect everything else from the code you're running, because the code itself can easily be attacked by uncontrolled input.
jillesvangurp 3y ago
On paper, this just uses the same security model as javascript and obviously a lot of thought is going into security and sandboxing with this. What has been problematic historically was a lot of native code written in a hurry by dot com era companies being unleashed on browsers via a poorly thought out plugin model. Flash, Silverlight, Java Applets, and loads more stuff existed while people were still OK serving stuff up without SSL, trying to figure out cookies and generally not putting a lot of thought into cross site scripting attacks. That was a security nightmare and all the obvious things happened. WASM does not seem like a repeat of that. Rather it builds on all the learning we've had since then.

by tbm57 3y ago

afiori 3y ago

For now wasm does not have any more risk than obfuscated JS. It is possible that there are a lot of tool to examine JS code for "suspicious code" and that those tools might not work well on WASM. In practice the WASM interpreter in the browser is a functionality that can be (almost) completely polyfilled. Personally I would be way more worries about hardware exploits via WebGL.

afiori 3y ago
Also it is likely that the browser debugger will be less feturefull for wasm and that future multithreaded support will make obfuscation even easier. But it is probably already possible with JSFuck and webworkers.

paulgb 3y ago

WebAssembly running in the browser runs in an isolated environment whose only access to the outside world is by calling out to JavaScript functions exposed to it when it was initialized. So it doesn’t open up any new APIs. It does get recompiled to bytecode that runs directly on the processor, so in theory there could be vulnerabilities that come up from that, but I think it’s a pretty well-understood surface area at this point.

folkrav 3y ago
I know it's not fundamentally that different from the running arbitrary code we have right now, but something about the idea of indiscriminately running binaries invisibly downloaded over the WWW rubs me the wrong way. Edit: read the first half of my sentence again.
- dymk 3y ago
  That’s what we’ve been doing since the dawn of JavaScript, in a VM with a much larger surface area. A simper VM should be quite a bit safer than the status-quo.
- codeflo 3y ago
  > something about the idea of indiscriminately running binaries invisibly downloaded over the WWW rubs me the wrong way I think that's because the word "binary" has connotations that aren't strictly technically justified. There's no difference between running WASM and running JS (which is usually obfuscated anyway). Both are JITted into machine code, and it's important the JIT is implemented securely. (JIT compilers have been sources of exploits.) The only difference is complexity of the source language, where simpler languages are easier to secure. And WASM is orders of magnitude simpler than JS.
- lumb63 3y ago
  I have some bad news for you…
- afiori 3y ago
  I believe wasm will allow for far greater opportunities for code obfustation. You can already do things like http://www.jsfuck.com/ http://www.jsfuck.com/ and even more complex ones, but they would likely have bad performace. With wasm you could do malware-level obfuscation with less drawbacks.

Jweb_Guru 3y ago

WASM's runtime is far simpler than JS's, or even something like the JVM, particularly due to lack of garbage collection. The language was deliberately designed to be straightforward and efficient to JIT compile to a safe virtual machine, e.g. attention was paid to making sure bounds checking could be elided efficiently for constant offsets while being enabled elsewhere. It's also significantly simplified compared to assembly, and lacks functionality like arbitrary jumps that are common sources of vulnerabilities. It's pretty much ideal for the usecase of "I want to run pretty fast code on an untrusted machine" which is the main reason it's taking off. (Obviously, as WASM JIT compilers get more elaborate and it incorporates things like GC'd references, some of the advantages of this design wrt simplicity will disappear, but I anticipate that these kinds of features will mostly not be used in settings like databases).

malkia 3y ago
Dart/flutter can now target wasm (unstable), so better gc support is coming (e.g. not gc running from whatever you compiled, but rather the wasm vm would do for you)

kevingadd 3y ago

WASM being used to exploit your PC isn't much of a risk, because it has a really robust security model. It's been used in exploit chains before but my understanding is that the number of times people have found holes in WASM sandboxes is much smaller than the number of times people have found holes in JS runtimes. So it's pretty fit for purpose there. Unfortunately, the design of WASM and common compilers targeting it means that your security is at risk as a user, even though your PC is safe. Applications compiled to WASM have a wide variety of fun security vulnerabilities that have been gone on native targets for decades, which means that if (for example) Gmail moved to WASM, it would now be possible for malicious parties to attack your Gmail tab even though they can't attack your PC. Some examples: * Address space layout randomization is gone - if an attacker gets a write-anwyhere primitive, it will work 100% of the time * Function pointers are densely packed - any possible value within the correct range (0 - function count) is a valid function pointer, as long as the signature matches. Even worse than not having ASLR. * Page protections are gone - all data is mutable, even things that shouldn't be like string constants compiled into the binary * Zero page accesses don't trap - while compilers go out of their way to try and make reading/writing from null pointers fail in WASM, the actual runtime happily allows you to do it. This makes attacks easier to execute because while stray nulls would kill a native application on dereference, in WASM they will just yield a 0 and execution will often continue. * Most stuff is static linked - for native applications, it is common (albeit less common now in our modern era of Electron Hell) to pull in services from the OS and its packages, whether it's zlib or https or whatnot. The WASM runtime model generally offers a very limited set of capabilities in comparison, and there's no equivalent way to dynamically link against vendored packages that get security updates automatically. So every application ships its own ICU (for time zone and localization data), ships its own zlib (for compression/decompression), ships its own crypto (because the browser crypto APIs are extremely limited and async-only), etc... Ultimately WebAssembly runtimes are very secure, but you have to protect everything else from the code you're running, because the code itself can easily be attacked by uncontrolled input.

jillesvangurp 3y ago

On paper, this just uses the same security model as javascript and obviously a lot of thought is going into security and sandboxing with this. What has been problematic historically was a lot of native code written in a hurry by dot com era companies being unleashed on browsers via a poorly thought out plugin model. Flash, Silverlight, Java Applets, and loads more stuff existed while people were still OK serving stuff up without SSL, trying to figure out cookies and generally not putting a lot of thought into cross site scripting attacks. That was a security nightmare and all the obvious things happened. WASM does not seem like a repeat of that. Rather it builds on all the learning we've had since then.