Privatebin: 1.3 doesn't work in browsers that don't support webassembly (Tor Browser)

[t2d]

Steps to reproduce

1. Open instance with version 1.3 in TorBrowser e.g. https://snip.dssr.ch/

What happens

You won't see an editor or content

What should happen

You should see editor/content

Additional information

Basic information

Server address: https://snip.dssr.ch/

Browser: TorBrowser 8.5.4 (based on Mozilla Firefox 60.8.0esr) (64-bit)

PrivateBin version: 1.3

I can reproduce this issue on https://privatebin.net: Yes

Maybe related to #441?

[t2d]

It works with Firefox ESR+ Privatebin 1.3.
It works with TorBrowser + Privatebin 1.2.1.
Therefore, seems to be specific to TorBrowser + Privatebin 1.3.

[elrido]

I assume that means the tor browser doesn't consider this a secure context and disables access to the WebCrypto API. Could you provide the output displayed on your browser console (in the F12 menu) if there is any?

[t2d]

ReferenceError: WebAssembly is not defined[Learn More] zlib-1.2.11.js:13:15
ReferenceError: WebAssembly is not defined[Learn More] zlib-1.2.11.js:13:15

[rugk]

Okay, so Tor likely blocks WebAssembly.
Which is your security slider psoition? Does it help, if you change that?

[Salokyn]

I have the same problem on Chrome 75 or Firefox 52.

Chrome says:

Uncaught (in promise) CompileError: WebAssembly.compile(): Wasm code generation disallowed by embedder
at initialize (https://xxx.yyy/privatebin/js/zlib-1.2.11.js:34:42)

Works on https://privatebin.net/

[elrido]

Oh, I might just have forgotten to update the csp policy on that site. Le'mme check.

Edit: Nope, false alarm, it does come with the script-src set to 'unsafe-eval' for WASM support in Chrome. @Salokyn, is this on the same server or your own? If on your own server, please check your cspheader setting.

[Salokyn]

Thank you @elrido

I just fixed the cspheader setting I kept from v1.2.1 (the old one did not have script-src set to 'unsafe-eval').

It works now on Chrome 75.

Probably for another reason, it's still broken on Firefox 52 ESR (it's an oldie anyway -_-). It says:

ReferenceError: WebAssembly is not defined (zlib-1.2.11.js:13:15)

[t2d]

Okay, so Tor likely blocks WebAssembly.
Which is your security slider psoition? Does it help, if you change that?

It's on Standard. The lowest possibility.

[elrido]

@Salokyn - according to mozilla docs, WebAssembly is supported as of version 52, _but_ "Disabled in the Firefox 52 Extended Support Release (ESR)." - ESR 60 or the soon to be released 68 should solve this.

[t2d]

https://blog.torproject.org/new-release-tor-browser-80 says:

Bug 21549: Disable wasm for now until it is properly audited

Mentioned bug: https://trac.torproject.org/projects/tor/ticket/21549

[Salokyn]

@Salokyn - according to mozilla docs, WebAssembly is supported as of version 52, _but_ "Disabled in the Firefox 52 Extended Support Release (ESR)." - ESR 60 or the soon to be released 68 should solve this.

Ok thanks, I did not know that. It can be enabled in about:config by swithing option javascript.options.wasm to true.

[gerroon]

Setting this javascript.options.wasm to true fixes it for me in FF 67

[elrido]

@Giltyhub2 Please see appendix A in the release notes. All major browser vendors do support as of mid of 2017 - Since most browsers have an auto-update mechanism for platforms that have no package managers, we can rely on most users having updated their browsers at least once in the last 2 years.

[elrido]

Thanks to the above provided about:config flag that lets us control WASM in firefox, I had the opportunity to play around with the browsers behaviour when webcrypto API is enabled, but WASM isn't.

Two thoughts:

1. While we had added a feature discovery for the webcrypto API _and_ WASM to display a meaningful error message and the unit tests proved this to be working, in the browser the missing WASM causes zlib.js to error out which leads to privatebin.js awaiting zlib forever, so no error message does get displayed. This obviously needs fixing in zlib.js and/or privatebin.js - may be as simple as ensuring the feature detection is executed earlier then the zlib await in privatebin.js.
2. We only use WASM for the zlib library and compression. Our current logic already supports disabling of compression globally. If the point above is resolved, the crypto logic can automatically fall back to produce a paste with compression disabled - This means that a browser without WASM support could create pastes and at least read those without compression, just not the pastes/comments with compression enabled - we could display a meaningful warning in that case, so the user learns about the limitations of her/his browser (maybe create with an FAQ entry, so we can give hints about Torbrowser, Firefox ESR or enabling WASM, if disabled). This would be an improvement over not being able to create pastes at all.

[rugk]

Good plan, I thus categorize it as a bug.

Bug: No proper erro message/fallback handling for missing WASM support.

[elrido]

So, a brief status update on this one, now that I finally started looking into it. So far I have managed to fix the browser feature detection to the extent that it now displays the intended warnings in Chrome with insecure context (= webcrypto disabled) as well as when wasm is turned off. Three more areas need working on:

1. As described above, when there is no WASM we intend to let the user create uncompressed pastes but warn that they wont be able to read zlib compressed pastes (an admin could choose to disable compression entirely, on an instance -> then we should not show the warning). Part of this logic is there, but currently the InitialCheck.init() still treats this as a breaking change and interrupts the execution entirely.
2. I discovered why IE can't even display an error anymore: It gives up parsing JS files as soon as it stumbles across an async or await keyword, so it can't even execute the InitialCheck, even though we there stick to "traditional" JS. This bugs me, so I am considering to move the InitialCheck class sideways into a legacy.js that restricts itself to traditional JS (var instead of let/const, no async/await, etc.) so that these ancient browsers at least can display an error, if nothing else.
3. Working on 1. I discovered that our translation inserts the strings as text nodes (using jQuery .text(), instead of, for example, .html()). This is safe, as it will encode any HTML entities properly. But it also means the links tag in the warning "Your browser may require an HTTPS connection to support the WebCrypto API. Try switching to HTTPS." is turned into an encoded string. Unfortunately my attempts of changing this had various side effects (thankfully caught early in unit testing). I have today had one more idea how to solve this, but if this fails, I'll cut my losses and instead use a regular text message with no link or just an appended link.
   I'll let you know once I have something ready for testing.

[rugk]

It gives up parsing JS files as soon as it stumbles across an async or await keyword

When we also use/switch to ES6 modules, we can make an even better fallback: see the doc here.

There is a nomodule attribute that prevents "usual" JS files from being loaded when a browser supports moduls. AFAIK all browsers that support ES6 modules also support async/await.

This would be the cleaner solution IMHO. You then have a minimum support/target version you know you support and the legacy (nomodule) JS can just display the message.

1. sounds hard and is indeed security-critical. (okay, actually the input data is trusted(?), but anyway) If possible, I would prefer not to change it.

[elrido]

Reg. ES6 - we need to do feature detection in any case, as we have found out that we can't rely on such assumptions with the 1.3 release and all the subsequent errors it caused with plugins and less common browser types or versions. I also have no intention to refactor the JS again any time soon and will focus on all of the UI feature requests we planned for 1.4. But you are of course very welcome to work on ES6 modularization, if you like to and also can ensure it works in some kind of unit testing in travis, etc. that is equivalent or better then what we have.

Reg. 3 - if we don't change it, we will not be able to use HTML links in our error messages. I have a solution for it in 813e72d871e2d491 that you can review. Basically I only revert to html insertion, if the translated string contains a <a, while most strings are still inserted via the safer, entity encoding text node insertion.

[umonaca]

For anyone that wants to use Privatebin inside a Tor browser, here is the simple solution:

Go to about:config. Toogle javascript.options.wasm to true instead of the false by default. And that's it!

[rugk]

…though such about:config changes likely will make you identifiable, so remember to revert it later, at least.

Edit: to highlight this again: Do not change anything in Tor Browser! This destroys the anonymity provided by it. Only do so, if you know what you are doing!.