Can't disable WebAssembly on Vanadium?

hemlockiv

I've seen these two posts on WASM in Vanadium already, and my understanding is that if JIT is disabled, so is WASM.

Well, I have disabled JIT (both in Android settings, and in Vanadium's settings, with no site exceptions), but according to this website which tests for WebAssembly support—https://wasm.joway.io—it appears WASM is still able to run on Vanadium. (When I disable WASM in IronFox, for example, that website shows "Not supported" as expected.)

Is there something else that can be done besides disabling JIT (and disabling all chrome://flags involving webassembly) to fully lock down WASM?

Watermelon

de0u DrumBrake likely contains vulnerabilities, but it is plausible to hope that it has fewer than the Vanadium JIT.

It's not about vulnerabilities, it's about exploit mitigations. JIT is incompatible with the mitigation that prevents code injection (dynamic code loading restriction), but interpreters are compatible with it. (Edit: The issue of vulnerabilities is still relevant, but that's a separate issue of attack surface. And as @soupslurpr said, it's not an issue.)

hemlockiv hemlockiv hemlockiv Without having read the provided articles, I'm presuming they mostly talk about malware delivered in WebAssembly format. Saying that WebAssembly is insecure because it allows the execution of malware is no different than saying GrapheneOS is insecure because it allows the user to install malware and grant it permissions that it will abuse. You could say that any computing device is inherently insecure, but GrapheneOS is said to be secure because it has a security model corresponding to the way it's used by its target audience (which is running many untrusted apps/webpages created by random parties, etc), and comprehensively puts effective-by-design mitigations against threats (although they could still be buggy) to fully match this model. Compare to e.g. desktop computers, which don't.

soupslurpr

We've recently enabled DrumBrake in Vanadium which means WebAssembly now works with JIT off using an interpreter. There isn't really a benefit to specifically turning WebAssembly off and not JavaScript as well if you wanna do that.

hemlockiv

soupslurpr There isn't really a benefit to specifically turning WebAssembly off

My understanding* is that WASM has a lot of security vulnerabilities, not least of which is remote code execution (we disable DCL from memory for the same reason, don't we?) and is primarily used by bad actors - a massive study found that over 75% of unique WASM modules were used for malvertising or cryptomining...

The better questions seems like, Why would I want webassembly in the first place?

(*I would be happy to learn that my understanding is not correct, btw! If wasm is actually safer than I think, please enlighten me.)

de0u

hemlockiv I appreciate the time you've taken to respond. Prior to your most recent replies, I don't think anyone actually had attempted to explain that interpreted WebAssembly was safer?

The original response from @soupslurpr (soupslurpr) pointed out the recent ability of Vanadium to interpret WebAssembly instead of JIT'ing it, and stated that turning WebAssembly off (for which there is not a toggle) without going all the way to disabling JS entirely (for which I believe there already is a toggle) would not add benefit. Though brief, I think that was accurate.

A variety of Internet sources were cited that can be read as alarming -- but not in light of the key issue, that running JS (whether or not it's WebAssembly) in a JIT is more dangerous than running it in an interpreter.

Then @soupslurpr stated (soupslurpr):

"WASM doesn't have inherent security vulnerabilities",
"The biggest source of vulnerabilities in the browser is the JIT",
"There's no significant attack surface being added by the WASM interpreter", and
"There isn't really a point in avoiding WASM but using JS" (for the second time).

Those claims all seem correct to me, and correctly differentiate between the risks of JIT'd JS versus interpreted JS.

A claim was made that "many security analysts" disagree, and further sources were mentioned -- but again those sources did not address the key issue of JIT'd JS versus interpreted JS, which @soupslurpr had mentioned twice. So it seemed to me that it might be productive to go through that in more detail.

soupslurpr

hemlockiv WASM doesn't have inherent security vulnerabilities. Native code can be compiled to both JavaScript and WASM. The biggest source of vulnerabilities in the browser is the JIT (Just In Time) compiler. It compiles JavaScript and WASM to native code right before the code is run.

Vanadium disables JIT by default, which previously broke WASM because there was no interpreter for it, but now there is one. There's no significant attack surface being added by the WASM interpreter.

So, there isn't really a point in avoiding WASM but using JS.

de0u

hemlockiv I would be happy to learn that my understanding is not correct, btw! If wasm is actually safer than I think, please enlighten me.

The issue is complicated.

I skimmed the Lehmann 2020 USENIX paper. Two vulnerability classes are mentioned: the possibility for WebAssembly apps to break into the browser, and the possibility for an app that has been compiled into WebAssembly to contain errors that could confuse the app. The paper appears to be largely about the second vulnerability class. That is, if a user is playing a game in Vanadium, and the game is written in C++ and compiled to WebAssembly, and the game uses WebSocket or something like that to communicate with malicious users on the network, then the game might be corrupted, crash, etc. That does not mean that Vanadium would be corrupted or crash, or that the underlying GrapheneOS system would be at risk.

There are risks related to running WebAssembly as fast as possible, which is done by running the JS code in a JIT, but those risks can be addressed by running WebAssembly in a safer execution engine (at present: not a JIT). The belief expressed by @soupslurpr that the DrumBrake interpreter is a safer way to run WebAssembly programs is very plausible.

The CrowdStrike piece says they "collected and analyzed 12,291 unique WebAssembly samples from May 2018 to June 2021". I don't see a description of how they did the collection. Was it a scraping of the top 50,000 web sites by traffic? If it's not known what population was examined then it's not clear what it might mean for 75% of that population to be malicious. CrowdStrike is in the security business, so they might well not have focused on the WebAssembly code most likely to land in a browser.

de0u

hemlockiv I would be happy to learn that my understanding is not correct, btw! If wasm is actually safer than I think, please enlighten me.

Multiple people in this thread, including a GrapheneOS developer, have attempted to explain that interpreted WebAssembly is safer than JIT'd WebAssembly.

There is good reason to believe that interpreted WebAssembly is much safer than JIT'd WebAssembly, and there is good reason to believe that interpreted WebAssembly is approximately as safe as regular JavaScript.

alwaysprotected

Why sites use WASM is since its faster than Javascript.
Proton for example use WASM for encrypting/decrypting and disabling it will break the site.
But 99% of websites dont use it.

A toggle for it would be nice since it is an attack vector, and disabling is more secure.

hemlockiv

thmf To me it looks like using WASM in Vanadium is safer than having V8 disabled in Cromite.

Let's not get off topic.

alwaysprotected Proton for example use WASM for encrypting/decrypting and disabling it will break the site.

If security or speed is your concern, you should not be using protonmail in your browser wtf

soupslurpr WASM doesn't have inherent security vulnerabilities.

Many security analysts, including a few I had linked, seem to disagree. Can you point me to specific evidence to support your claim? Because when I have searched for information of the security/exploitability of WASM, the results don't look encouraging:

whatname

WASM is dangerous. I'm glad that im using Cromite, which does have a global switch to disable it (V8)

de0u

whatname WASM is dangerous.

Breathing is dangerous, the Internet is dangerous, etc.

Moving beyond that involves thread modeling, risk analysis, and choosing mitigations. For some users, disabling JavaScript entirely may make sense some of the time; for other users, perhaps some situations might call for a device without a web browser.

DrumBrake likely contains vulnerabilities, but it is plausible to hope that it has fewer than the Vanadium JIT.

thmf

whatname WASM is dangerous. I'm glad that im using Cromite, which does have a global switch to disable it (V8)

Since you mentioned WASM is dangerous it seems like you value security. Well, I'd be very cautious with Cromite then. Here are just a few quotes from the project members who (I assume) you trust since you're here:

https://discuss.grapheneos.org/d/10550-mull-hardened-firefox-security/52

matchboxbananasynergy Cromite makes a lot of choices that make it a subpar choice, and in my opinion, doesn't prioritize security.
Some examples of this:
Addition of JPEG-XL, which is a lot of additional attack surface over Chromium.
Addition of Eyeo's adblocking engine, written in C++ (memory unsafe). Eyeo is the company that bought "uBlock" (not uBlock Origin) and does "acceptable ads". Their code contains tracking that the maintainer of Cromite has to remove. Missing something there wouldn't be good. It's a very strange choice to add to the browser.
Cromite does not support CFI. It used to, but then it broke, and instead of fixing the issue, they simply stopped using it.
Of course, they also don't use MTE, which Vanadium does on devices supporting it.
Cromite is the successor to Bromite, a now-dead project that changed its licensing to GPLv3 and wouldn't share patches with Vanadium despite taking from it. All in all, I personally see no reason why it's so widely recommended in so called "privacy circles".

https://discuss.grapheneos.org/d/10550-mull-hardened-firefox-security/59

GrapheneOS Cromite makes changes which significantly reduce security, and most of their privacy changes are highly questionable.

https://discuss.grapheneos.org/d/10550-mull-hardened-firefox-security/61

GrapheneOS They do not implement many of the features correctly and take problematic shortcuts. It leads to them having a long list of features which sound useful but which are largely reducing security and not working properly. They incorporate highly problematic third party code from Eyeo full of serious security bugs and full of invasive tracking code. Their technical decisions are not the full picture of what we were referring to though. It's quite relevant that they have no issue with plagiarism, scamming and harassment, even towards people they were taking substantial amounts of code from in the past which they then downplayed. You would be better off using Brave which despite the controversies about cryptocurrency, etc. is far more technically competent and also far more trustworthy than this.

https://discuss.grapheneos.org/d/7141-chromite-vs-vanadium-for-the-average-person/31

final Likewise, the only other browser the project recommends is Brave. It preserves mobile Chromium's security posture while adding additional state partitioning, anti-fingerprinting improvements and the most advanced content filtering engine. Vanadium has greater security enhancements like MTE support in production

To me it looks like using WASM in Vanadium is safer than having V8 disabled in Cromite.

de0u

hemlockiv Many security analysts, including a few I had linked, seem to disagree.

Again, there are multiple classes of concern.

Concerns about whether the internal state of an app compiled to WebAssembly might be corruptible are not at all the same as concerns about a WebAssembly program escaping into the browser or even into the OS.

The snyk.io piece lists a wide variety of concerns, but several of them are about the internal state of WebAssembly apps. It also mentions XSS. XSS attacks began with, and still mostly affect, regular web pages that have nothing at all to do with WebAssembly. Disabling WebAssembly does not protect against XSS mistakes in non-WebAssembly web apps. And in fact disabling WebAssembly may well result in a site falling back to a regular web app; if the WebAssembly app has an XSS vulnerability, probably the regular web app will too.

It is possible to pile up a list of bad things that might happen while WebAssembly is running. But that list of bad things is happening only because the Internet is involved! Turning off WebAssembly may well not provide protection against that list of bad things, but turning off the Internet probably will.

hemlockiv When I have searched for information of the security/exploitability of WASM, the results don't look encouraging.

I don't think counting up the number of articles that express some concern about WebAssembly, without figuring out which of those concerns are/aren't relevant to a specific threat model, is likely to be a productive approach.

Vanadium disables JIT by default due to a fair density of site-escape and browser-escape vulnerabilities in JITs. Vanadium does not have a toggle for disabling interpreted WebAssembly, because of an absence of evidence that interpreted WebAssembly is a larger threat than regular interpreted JavaScript. If it is possible to provide evidence that interpreted WebAssembly is a larger threat than regular interpreted JavaScript, that would be relevant to a request for a toggle to disable interpreted WebAssembly.

hemlockiv

de0u Multiple people in this thread, including a GrapheneOS developer, have attempted to explain that interpreted WebAssembly is safer than JIT'd WebAssembly.

I appreciate the time you've taken to respond. Prior to your most recent replies, I don't think anyone actually had attempted to explain that interpreted WebAssembly was safer? SoupSlurper stated that DrumBrake could be used with JIT off, and later stated that this makes it safer, but never actually offered any explanations—let alone evidence—to support those statements.

The first time I actually read an explanation of why interpreted wasm is safer was in your last 2 replies, and for that I am very grateful!

de0u

hemlockiv Security issues are complicated, and details matter a lot.

The academic paper discussing particular risks within the WebAssembly model is probably 100% correct (again, I skimmed it rather than reading it carefully), but it was completely irrelevant to whether or not it's safe to run WebAssembly via DrumBrake in Vanadium.

The snyk.io article listing many bad things that might happen in general association with WebAssembly also looks largely correct, though at least one concern discussed is actually a concern about all web apps regardless of implementation language.

Overall, it can simultaneously be true that:

The web is full of articles expressing concerns related to WebAssembly in various ways, and
Running a web app in WebAssembly in the DrumBrake interpreter on Vanadium can be rather safe (just as safe as runnng a web app in regular JS in the regular JS interpreter on Vanadium).

The notion that "WebAssembly is dangerous" is dubious. The notion that "JITs are dangerous" is arguably more accurate.