Noscript blocking Dashlane extension Firefox 50

[Gauner]

I've just discovered that the latest Noscript is blocking the Dashlane extension in Firefox 50, causing it to not function at all. If I disable noscript, Dashlane works fine. This just seemed to happen recently, and from my limited investigation appears to be related to ABE blocking local connections. (not super technical )

I've tried the latest dev build and it still fails.

[im3or]

I have this problem too. I disabled all the extensions in the firefox, finally discovered it is NoScript's fault. Finally, disabled the ABE & my password manager is working fine now.

I am using NoScript 2.5.9.1 with FF 50 32-bit. My password manager is sticky password.

PS: Is ABE essential to NS? Are there any repercussions?

[barbaz]

Do you get any message from ABE in your Browser Console (Ctrl-Shift-J)?

PS: Is ABE essential to NS? Are there any repercussions?

By default, ABE is set to block CSRF to your local network. It blocks any requests to your local network that didn't originate from there. i.e. it prevents router tampering, websites playing with your local server(s), connections from websites to your computer, etc.

So, if you disable ABE, now any site can access any resource on your local network.

You will also lose NoScript's DNT implementation. If you want DNT, be sure to turn that feature on in your browser if you haven't already.

[Thrawn]

If ABE is blocking something, there should be details in the Browser Console (Ctrl+Shift+J), which we can use to help you craft an appropriate rule to allow Dashlane.

[Gauner]

What I'm seeing in the log is the following over and over.

Code: Select all

Firefox can’t establish a connection to the server at ws://127.0.0.1:15674/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:17896/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:17896/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:21953/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:21953/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:32934/ <<< about:blank - 1}

With this showing up from time to time as well:

Code: Select all

dashlane-extension:Error: Couldn't find the worker to receive this message. The script may not be initialized yet, or may already have been unloaded.
Stack trace:
send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:82:13
sendOrderToJs@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:245:70
sendOrderToAllFrames@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:249:70
KWTabController.prototype.sendOrderToAllFrames@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:665:62
activateDOMNodeInsertedEvents@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:589:64
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:454:94
KWTabsController.getCurrentTabController@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:770:66
@resource://gre/modules/commonjs/toolkit/loader.js -> resource://jetpack-extension-at-dashlane-dot-com/content/core.js:454:2
notify@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/timers.js:40:9

[Thrawn]

Hmm...it seems to be hitting a few different port numbers. For testing, try putting this rule above the existing rule in the SYSTEM ruleset:

Code: Select all

Site 127.0.0.1
Accept GET

[idf]

This was happening before FF 50 for Windows. The problem started, actually - this morning, when I was still on prior version of FF. I've been ignoring the FF notifications to update to FF 40 the last couple of days.

So Dashlane stopped working - and, actually, to try to FIX this, I updated to FF 50, which obviously didn't help.

I think I noticed a recent update to NoScript? Currently I have NoScript 2.9.5.1 installed.

If there was just a change to NoScript in the last day, that may be the problem. An update to NoScript seems to have hit at about the same time as a new version of Firefox.

I am running FF 49.0.1 for Mac - and Dashlane is working on that platform with NoScript 2.9.0.14, not sure why it is so far behind.

It might help diagnose matters if the changelog at noscript.net included date/time and not just version number of updates, and/or if there were a straightforward way to tell when NoScript updates on a computer. Let me know if I am overlooking something.

Hope there is a fix soon.

Thanks.

[idf]

Sorry for the typo. Where I wrote:

I've been ignoring the FF notifications to update to FF 40 the last couple of days.

I meant FF 50.

[Gauner]

Hmm...it seems to be hitting a few different port numbers. For testing, try putting this rule above the existing rule in the SYSTEM ruleset:

Code: Select all

Site 127.0.0.1
Accept GET

this seems to have fixed the issue.

This started recently, so I'm assuming either the latest Noscript or Firefox.

[im3or]

Do you get any message from ABE in your Browser Console (Ctrl-Shift-J)?

I get these:

Code: Select all

[ABE WAN] Detected WAN IP 59.89.130.191
MozSocialAPI injectController: unable to attachToWindow for resource://light_plugin_acf0e80077c511e59ded005056c00008-at-kaspersky-dot-com/data/background/sandbox.html: TypeError: containingBrowser is null  MozSocialAPI.jsm:84

And these over & over again:

Code: Select all

[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< http://localhost:45872/, about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://localhost:45872/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://localhost:45872/.  (unknown)
[ABE] < LOCAL> Deny on {GET http://localhost:45872/ <<< about:blank - 1}

[idf]

Putting this into ABE options, as suggested, solves it for me too:

Code: Select all

Site 127.0.0.1
Accept GET

The existing rule allows any behavior from local, and denies everything else. This rule apparently allows any GET operation from anywhere to succeed, regardless of source - which seems like it might break a fair amount of ABE protection by allowing some operations to succeed?

Is this a safe thing to allow? What is the nature of typical external attacks on local that ABE is designed to prevent?

Did something change in NoScript, or did something change in a Dashlane update? According to Dashlane changelog, the most recent version of Dashlane for Windows - version 4.6.3 - was released on November 15 - 8 or 9 days before this problem surfaced. My dashlane executables seem to have been updated on or before that date. (The executables are in AppData\Roaming\Dashlane, not in Program Files.)

It's possible that NoScript was changed in advance to try to work around a problem the developers knew was coming in Firefox 50, but FF 50 was released before this problem occurred in NoScript. I was getting notifications to upgrade to FF 50 for a least a day before Dashlane/NoScript broke in FF 49.

I hope that makes sense. Here is a better timeline:

FF 49 - no problem
FF 49 - a day or so ago, I started getting notices to upgrade to FF 50
FF 49 - Dashlane breaks before I upgrade FF. This happened early on 11/23 (Pacific Standard Time)
FF 50 - I upgraded FF to try to fix the problem, but Dashlane is still broken

Then I came here.

[barbaz]

This looks like a NoScript bug. Thanks for the report

Better ABE exception, if it works, would be -

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank

[idf]

Your suggestion

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank

Does work, but there is a 10-15 second pause before Dashlane starts working. (It is gray till ready; then it turns green.) The console shows this:

Code: Select all

Could not read chrome manifest 'file:///C:/Program%20Files/Mozilla%20Firefox/chrome.manifest'.
Use of nsIDOMWindowInternal is deprecated. Use nsIDOMWindow instead.  bootstrap.js:43:20
Warning: NetUtil.newChannel(uri) deprecated, please provide argument 'aWhatToLoad'
“nsICookieManager2.add()” is changed. Update your code and pass the correct originAttributes. Read more on MDN: https://developer.mozilla.org/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICookieManager2  my.js:156:5
[ABE WAN] Detected WAN IP 24.23.190.43
[ABE] < LOCAL> Deny on {GET http://127.0.0.1:11456/ <<< http://127.0.0.1:11456/, about:blank - 1}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
Firefox can’t establish a connection to the server at ws://127.0.0.1:11456/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:15674/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:17896/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:21953/.  (unknown)
Firefox can’t establish a connection to the server at ws://127.0.0.1:32934/.  (unknown)
Key event not available on some keyboard layouts: key=“c” modifiers=“accel,alt”  browser.xul
Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt”  browser.xul
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift”  browser.xul

But it still loads after all that.

By this point I don't know if what I have is correct. This is what I have for the SYSTEM ruleset:

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

Is that what you are proposing, or did I mess something up?

[barbaz]

Oops, my bad. This should work better -

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank 127.0.0.1 localhost

[idf]

Oops, my bad. This should work better -

Code: Select all

Site 127.0.0.1 localhost
Accept GET from about:blank 127.0.0.1 localhost

Yes! Errors gone, and extension initializes quickly.

Will there be a fix to NoScript making this change unnecessary? I'm guessing it would be a fix to how the default system LOCAL rule is currently being interpreted, rendering this extra rule obsolete (but perhaps harmless). I hope the changelog makes some mention of a fix in this area, and if you remember, could you update this thread after the fix, to tell us if we should delete this extra rule?

Thank you very much.