wasm-eval

[camhart]

The wasm libraries used by e3kit-js found in this project require 'wasm-eval' in the content security policy. This is a security risk. To complicate matters, Google is forcing Chrome extensions to use Manifest v3 as of June 1st 2024 (all other chrome extensions will be disabled/removed from the users device). Manifest v3 does not allow content security policies with "wasm-eval".

Why do these libraries require wasm-eval? I can't think of a reason it would be necessary, but I don't know much about these libs.

[camhart]

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.

[camhart]

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.

[Scratch-net]

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

[camhart]

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.

[Scratch-net]

we never intended to support google chrome extensions anyway

[camhart]

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.

[Scratch-net]

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

[camhart]

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.