Using WASM securely within Chrome extensions

[Dave Teare]

Hello,

I'm really excited about the prospect of using WASM within our Chrome extension, specifically from within the background page. As a proof of concept I have the WebAssembly Studio fibannoci.wasm demo[1] configured in a sample extension and it's working fine after updating manifest.json to include `wasm-eval` in the CSP:

> "content_security_policy": "script-src 'self' 'wasm-eval'; object-src 'self'"

This is great but I'm not overly happy about including `wasm-eval` as in theory it would allow for arbitrary code execution. Along with the WebAssembly CSP spec recently renaming `wasm-eval` to `wasm-unsafe-eval`[2], I'm nervous about including this directive within our extension. 

I'm wondering if my worry is founded, however, as I'm having troubles imagining how an attacker could exploit `wasm-eval`. It seems to launch a successful exploit, an attacker would depend on `unsafe-eval` in order to inject their malicious code, which is something we would definitely NOT be including. And since our code will only ever load WASM files from within the extension folder (i.e. no remote downloading of code), these local files couldn't be tampered with by attackers as Chrome would detect the extension's code signature is no longer valid.

Assuming we avoid "unsafe-eval" and we only ever load WASM code from within the extension itself, is it safe to use `wasm-eval`? Are there other best practices we could be following to be even more defensive when using WASM?

By the way, it would be awesome if Chrome supported using SRI (sha256-*) hashes in the script-src. That would allay all these fears as we could calculate the sha during the build phase and ensure that only our code is ever ran. Unfortunately I couldn't get this to work. I created a sample project[3] that demonstrates the issue and opened issue 945121[4] to see about adding support for this if anyone is interested in more details. 

Thanks!

++dave;

[1]: WebAssembly Studio fibannoci.wasm demo: https://webassembly.studio/?f=aakxyho2ho 

[2]: "Rename 'wasm-eval' to 'wasm-unsafe-eval'" in WebAssembly CSP spec: https://github.com/WebAssembly/content-security-policy/pull/17

[3]: Sample WASM chrome extensions with various content security policies: https://github.com/dteare/wasm-csp

[4]: Issue 945121: WASM does not support SRI sha256 in CSP: https://bugs.chromium.org/p/chromium/issues/detail?id=945121

[Simeon Vincent]

Hey Dave,

Thanks for filing that bug. I'm not a CSP expert but I'm surprised to hear that loading Wasm files requires 'wasm-eval'/'wasm-unsafe-eval'; I would have assumed default-src 'self' would have been sufficient for loading the streaming version, since WebAssembly.instantiateStreaming() and WebAssembly.compileStreaming() consume the fetch stream directly rather than an arbitrary buffer. I'll have to talk to the team about how Wasm is expected to behave in extensions this week.

I'm excited to see what you've got in store, Dave!

Simeon - @dotproto

Extensions Developer Advocate

[Dave Teare]

Thanks for looking into this, Simeon. I look forward to seeing what you find! 

We can do a lot more with WASM in less time so I'm excited to be able to start using it. Hopefully soon. 🤞

++dave;

[Simeon Vincent]

Quick follow-up! I dug into the wasm loading issue a bit more and found that this is not an extension-specific issue. I've filed a feature request to adopt proposed Wasm CSP changes to be more in line with other browsers.

https://bugs.chromium.org/p/chromium/issues/detail?id=946838

Simeon - @dotproto

Extensions Developer Advocate

[Dave Teare]

Thank you Simeon. I've starred that issue and will follow along there.

I'm still curious about wasm-eval though. It feels like it's quite safe for a signed extension as any malicious actor would require `unsafe-eval` to exploit anything. I'm not a WASM expert, however, and would love to know if my feelings are founded or not.

++dave;

[Simeon Vincent]

I'm also not a WASM expert but my understanding of 'wasm-eval' was that it allows compilation and instantiation of any Wasm byte array. Assuming your JS is structured such that you're only ever fetching the Wasm payload from known path inside your extension, I don't think that leaves a vector for attackers to exploit. That, combined with Wasm's strict import/export-based communication channels makes me think you should be safe to use 'wasm-eval'.

Simeon - @dotproto

Extensions Developer Advocate