wasm-eval about virgil-crypto-javascript HOT 8 CLOSED

I was mistaken. Manifest v2 used wasm-eval. That's been removed. Now you can use 'wasm-unsafe-eval' in manifest v3.

However, ideally this lib wouldn't require it.

from virgil-crypto-javascript.

This shouldn't be closed. It's a security risk in the libs to use those methods then deploy to a website or chrome extension.

from virgil-crypto-javascript.

This library is based on wasm, you do understand that?

from virgil-crypto-javascript.

Yes. wasm-eval and wasm-unsafe-eval are not required in order to execute wasm. They're only required when the underlying wasm library makes unsafe calls.

from virgil-crypto-javascript.

we never intended to support google chrome extensions anyway

from virgil-crypto-javascript.

It's still a security risk when used in a browser. Seems really odd a security company is fighting this...? I mean if I'm wrong in some way thats one thing. But from my understanding the "eval" like functions allow arbitrary code to be run.

from virgil-crypto-javascript.

It's an open source project, you are welcome to make a PR.
If you can prove that it's actually a security issue and arbitrary code can actually be run, then please do. Otherwise let's not waste everyone's time

from virgil-crypto-javascript.

Based on the WebAssembly Sandbox, as described at https://github.com/WebAssembly/content-security-policy/blob/4c61db828b4a0739e4500e8d42d0ec85ef05505a/proposals/CSP.md#the-wasm-unsafe-eval-source-directive/ it seems the risk is small. I was a little thrown by the use of the words unsafe and eval.

Here's why I believe they're used, and it seems necessary to use them as there aren't alternatives yet. As described at https://developer.mozilla.org/en-US/docs/WebAssembly/Loading_and_running:

WebAssembly is not yet integrated with <script type='module'> or import statements, thus there is not a path to have the browser fetch modules for you using imports.

The older WebAssembly.compile/WebAssembly.instantiate methods require you to create an ArrayBuffer containing your WebAssembly module binary after fetching the raw bytes, and then compile/instantiate it. **This is analogous to new Function(string), except that we are substituting a string of characters (JavaScript source code) with an array buffer of bytes (WebAssembly source code).**

The bit in bold indicates the relation between the compile/instantiate calls and new Function(string). The eval word is used in CSP because of this relation. The same security risks that apply to "new Function(string)" or "eval()" in javascript apply to Wasm Instantiate calls, however wasms sandbox may help reduce risk. In short, arbitrary/dynamic remote code execution is possible. However, at this time that's the only way to load wasm modules. There is a risk--but nothing can be done about it if you want to use web assembly.

Having this understanding, and being able to explain it is not a waste of time. User's shouldn't be throwing 'unsafe' and 'eval' words into their CSP without understanding what the security impact of doing so is. wasm-unsafe-eval is not limited to Chrome Extensions in scope. It applies to the entire web.

Whether the ticket stays opened or closed is up to you. There's nothing to do about it for now.

from virgil-crypto-javascript.