WASM poses a disproportionate risk to users
Categories
(Core :: JavaScript: WebAssembly, defect)
Tracking
()
People
(Reporter: mark, Unassigned)
Details
WebAssembly (WASM) poses a disproportionate risk to end-users and should be disabled by default, or be subject to per-site/per-extension permission policies (opt-in).
With more than half of the cases of WASM in use on the top 1 million websites being malware[1], having WASM enabled by default in content (as it is in Firefox) is a huge risk for all users of the browser, and not in proportion to the advantages gained by it. Even its allowed use in browser extensions is problematic because it likely becomes impossible to properly vet extensions and their safety if it contains non-human-readable machine code as WASM that will likely not be able to be properly analyzed by an automated process either.
Please consider taking a very careful approach to allowing WASM in the browser; at the very least it should be per-site and opt-in for content, and preferably simply disabled by default (or at the very least until such time as a proper permissions system is implemented). I also think it should become an explicit granted permission for extensions with the extension author needing to provide a clear description why it needs WASM.
Thanks in advance for your consideration and keeping users safe.
[1] "Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes". https://www.infoq.com/news/2019/10/WebAssembly-wasm-malicious-usage/
|
||
Comment 1•6 years ago
•
|
||
(In reply to Mark Straver from comment #0)
Even its allowed use in browser extensions is problematic because it likely becomes impossible to properly vet extensions and their safety if it contains non-human-readable machine code as WASM that will likely not be able to be properly analyzed by an automated process either.
How is that fundamentally different from, say, asm.js code? Let's say we take a C/C++ code base and compile it using LLVM/Emscripten to both an asm.js and Wasm file. Then we open the asm.js file and we use Wasm's text format to display the Wasm file. The two files will be basically identical as both formats are impossible to understand or audit for a human, no?
Yes Wasm is nice for crypto-mining and stuff because it's generally faster than JS. However banning Wasm doesn't eliminate that problem - they'll just use the asm.js version again and still mine bitcoins on your machine, just a little slower. It's not a fundamental difference or new capability.
|
Reporter | |
Comment 2•6 years ago
|
||
The main point I'm making is not that it "can be used for malicious purposes", because that is the same for any programming language you give people access to. The problem is that it is being actively used for this and on a very large scale, at that. If half of the time you visit a website with WASM it's actually malicious, I'd say that is a massive problem that something needs to be done about, right now. This isn't the first time that good ideas can't be left to endure because of abuse, and won't be the last -- that's why I propose some form of permission system is created for this, e.g. through page permissions, but it should be some form of opt-in, either way.
As for the extension question: So how do you currently vet WebExtensions that have this kind of code in it? Do you even vet them at all?
I have no insight in the numbers involved in malicious WASM use in extensions, and it's more a secondary concern for this bug, since there's more control mechanisms in place already for extensions anyway, but I wanted to mention it because extensions run in chrome context and are more privileged than content by definition; so a higher risk for the user even if it occurs less. Feel free to ignore that concern if you think it's not risky/pervasive enough to warrant work on it -- my primary concern as stated is web content, here.
|
||
Comment 3•6 years ago
•
|
||
JS is also already being used for malicious purposes. Anyways, this was a discussion to be had 2 years ago, when wasm shipped in all browsers. Disabling it now would break the web, as it's used by >1% of page loads, so this isn't something we can even really consider now.
|
|
Reporter | |
Comment 4•6 years ago
|
||
I'm saying you should consider it anyway. 2 years ago you didn't have the problems with it we have now.
This is no different than other good features that have eventually been disabled because of too widespread abuse in the wild.
I'm pretty sad that you're not even going to consider a permissions-based model which would allow it to remain enabled, but in a safer way.
But hey, your party, I guess.
Description
•