Do not fear, people will implement WASM time-sharing systems, so you can not only execute random people’s code on your machine, you can also run a WASM anti-virus solution alongside!
The dangers of exposing APIs like web USB are compounded with performant and inscrutable blobs run in the browser. Thus, WASM exacerbates these issues.
My experience that we suffer far more from the fact that we have no idea when a payload is delivered, since a web server can serve distinct content to every viewer, than we do from the fact that some payloads are difficult to untangle.
I’ve seen arguments like this before but never fully understood them. It seems to me like asm.js is just as inscrutable as WASM, but it’s more annoying to work with for a couple reasons:
It’s fast, but somewhat inconsistently so as compared to WASM
Large download size
Not to mention all of the minifiers and manglers that exist for conventional JS. Why the WASM hate? It seems more useful to programmers than the alternatives, and we’re already paying the security cost of running untrusted executable code from the internet in browsers today.
asm.js is similarly gross, but people appear to be moving to its successor WASM.
Reversing minified and mangled JS is, I submit, a different level of inconvenient from reversing bytecode–especially bytecode that can suddenly leverage other language ecosystems obfuscation tools and technique. Just because they’re different levels of inconvenient doesn’t make one more acceptable than the other.
As for the security cost–look, a lot of attacks and nastiness open themselves up once you can leverage that improved performance. Spectre/Meltdown were directly enabled by better performance primitive for timing and shared array buffers, and yet some people refuse to acknowledge the problems they pose by their very existence.
I’ve griped about this all before, and at this point I’m basically resigned to the idea that fanboys and nerds more excited about performance and shiny and their chance to leave their teeny mark on the web ecosystem than about user security and rights and conservative engineering are probably going to win on this in the end.
I get the woes of security on the web — it’s really, really hard to make running untrusted code secure, especially with the “dancing pigs” problem. My point with asm.js, though, was that WASM doesn’t add anything new: before WASM, people were compiling to a fast subset of JavaScript, and that was equally difficult to decompile. And that really puts the problem squarely back in “running untrusted code securely is hard” camp: if you were a browser vendor, what would you do? Any language will have fast paths (and as a vendor you’re also incentivized to make those paths very fast), and if you enforce running only a single language, people can always compile to the set of operations that are fast in that language. WASM is an improvement over the ad-hoc version, at least.
But yeah, definitely get that security on the web is hard :(
I can see your fear but it might be unfounded. WASM doesn’t have access to all the Web Platforms API, that is not how it works. The WASM “ISA” is specified, it doesn’t have access to stuff outside it, you might be curious to check the specs at https://webassembly.github.io/spec/
Since the WASM file formats (both the bytecode one and the text one, which is based on S-expressions) are easy to parse, it is not too far-fetched to have static analysers checking the code out.
WASM doesn’t have access to file system or sockets or even the DOM among other limitations. It is basically a faster way to number crunch and/or port existing code written in other languages. All those side-effecty things need to be proxied over through JS and the Web Platform that will ask permissions and sandbox a ton of it.
In my humble option, I am much more confortable executing JS/WASM things on the client-side than trusting arbitraty SaaS backends with my data. I know what the Web Platform has access to and what I allow it to peer with.
I find WebUSB a really nice step forward as it allows WebAuth to provide stronger authentication schemes, which are always a good idea.
Thanks for the link. I was wanting to learn more about it. The intro is really good, too. Many desirable properties. I bet it was hard to design trying to balance all of that. Usually, that also means a formal specification might uncover some interesting issues.
They are still made of people who show up to work with a cold/hangover and make judgement calls (or try to curry favour with management by claiming credit).
The user still has to allow the website USB access to the device and if they are one of the people who own these USB calls they are probably smart enough not to allow it.
This comment contains content of such life-changing awesomeness that we must request your permission before revealing it to you. If you dare, click “Accept” in the dialog now displayed at the top of the window.
I’ve been interested in all things infosec for around 20 years at this point, and I /still/ regularly get those permission dialogs wrong, and the problem isn’t me, the problem is that the dialogs exist at all. Nobody can be expected to get them right, and even when present the behaviour they gate should never be game-ending as in WebUSB
Popular opinion holds that browser security warnings are ineffective. However, our study demonstrates that browser security warnings can be highly effective at preventing users from visiting websites: as few as a tenth of users click through Firefox’s malware and phishing warnings. We consider these warnings very successful.
People do react to unknown notifications. (The study goes on and talks about the efficiency of such notifications related to their design)
Sure, at enterprise scale, that still means something is going through, so you might want to deploy your browser with appropriate policies which deny such request every time if you want.
WebUSB is a mistake.
And with WASM, we will have even less chance of catching malware that can leverage it.
Do not fear, people will implement WASM time-sharing systems, so you can not only execute random people’s code on your machine, you can also run a WASM anti-virus solution alongside!
What’s the connection to WASM?
The dangers of exposing APIs like web USB are compounded with performant and inscrutable blobs run in the browser. Thus, WASM exacerbates these issues.
Is WASM more inscrutable than obfuscated JS?
My experience that we suffer far more from the fact that we have no idea when a payload is delivered, since a web server can serve distinct content to every viewer, than we do from the fact that some payloads are difficult to untangle.
I’ve seen arguments like this before but never fully understood them. It seems to me like asm.js is just as inscrutable as WASM, but it’s more annoying to work with for a couple reasons:
Not to mention all of the minifiers and manglers that exist for conventional JS. Why the WASM hate? It seems more useful to programmers than the alternatives, and we’re already paying the security cost of running untrusted executable code from the internet in browsers today.
asm.js is similarly gross, but people appear to be moving to its successor WASM.
Reversing minified and mangled JS is, I submit, a different level of inconvenient from reversing bytecode–especially bytecode that can suddenly leverage other language ecosystems obfuscation tools and technique. Just because they’re different levels of inconvenient doesn’t make one more acceptable than the other.
As for the security cost–look, a lot of attacks and nastiness open themselves up once you can leverage that improved performance. Spectre/Meltdown were directly enabled by better performance primitive for timing and shared array buffers, and yet some people refuse to acknowledge the problems they pose by their very existence.
I’ve griped about this all before, and at this point I’m basically resigned to the idea that fanboys and nerds more excited about performance and shiny and their chance to leave their teeny mark on the web ecosystem than about user security and rights and conservative engineering are probably going to win on this in the end.
:(
I get the woes of security on the web — it’s really, really hard to make running untrusted code secure, especially with the “dancing pigs” problem. My point with asm.js, though, was that WASM doesn’t add anything new: before WASM, people were compiling to a fast subset of JavaScript, and that was equally difficult to decompile. And that really puts the problem squarely back in “running untrusted code securely is hard” camp: if you were a browser vendor, what would you do? Any language will have fast paths (and as a vendor you’re also incentivized to make those paths very fast), and if you enforce running only a single language, people can always compile to the set of operations that are fast in that language. WASM is an improvement over the ad-hoc version, at least.
But yeah, definitely get that security on the web is hard :(
I can see your fear but it might be unfounded. WASM doesn’t have access to all the Web Platforms API, that is not how it works. The WASM “ISA” is specified, it doesn’t have access to stuff outside it, you might be curious to check the specs at https://webassembly.github.io/spec/
Since the WASM file formats (both the bytecode one and the text one, which is based on S-expressions) are easy to parse, it is not too far-fetched to have static analysers checking the code out.
WASM doesn’t have access to file system or sockets or even the DOM among other limitations. It is basically a faster way to number crunch and/or port existing code written in other languages. All those side-effecty things need to be proxied over through JS and the Web Platform that will ask permissions and sandbox a ton of it.
In my humble option, I am much more confortable executing JS/WASM things on the client-side than trusting arbitraty SaaS backends with my data. I know what the Web Platform has access to and what I allow it to peer with.
I find WebUSB a really nice step forward as it allows WebAuth to provide stronger authentication schemes, which are always a good idea.
Thanks for the link. I was wanting to learn more about it. The intro is really good, too. Many desirable properties. I bet it was hard to design trying to balance all of that. Usually, that also means a formal specification might uncover some interesting issues.
I thought YubiCo was one of the good companies :(
They are still made of people who show up to work with a cold/hangover and make judgement calls (or try to curry favour with management by claiming credit).
The user still has to allow the website USB access to the device and if they are one of the people who own these USB calls they are probably smart enough not to allow it.
This comment contains content of such life-changing awesomeness that we must request your permission before revealing it to you. If you dare, click “Accept” in the dialog now displayed at the top of the window.
I’ve been interested in all things infosec for around 20 years at this point, and I /still/ regularly get those permission dialogs wrong, and the problem isn’t me, the problem is that the dialogs exist at all. Nobody can be expected to get them right, and even when present the behaviour they gate should never be game-ending as in WebUSB
Unless:
Such users empirically do not exist.
[citation needed]
At quick glance, I found this study: https://pdfs.semanticscholar.org/4c40/c0ea6b02630839658ba7939dd609c621bf17.pdf
People do react to unknown notifications. (The study goes on and talks about the efficiency of such notifications related to their design)
Sure, at enterprise scale, that still means something is going through, so you might want to deploy your browser with appropriate policies which deny such request every time if you want.
Oh, neat link!
That said, with a million users only a tenth is still a hundred thousand.
Sure, but that problem we have on so many levels.
For individuals, it’s protection, for cohorts, less so.