Page 1 of 2

ABE seems to be broken since the latest release [2.9.5.1]

Posted: Thu Nov 24, 2016 9:49 pm
by palme
Before updating to the version 2.9.5.1 the ABE rule

Code: Select all

Site .twitter.com
Accept from .twitter.com
Deny
worked without a problem. But after the update i get this error when i type twitter.com into the address bar:

Code: Select all

Request {GET https://twitter.com/ <<< moz-nullprincipal:{e219bd0e-db0a-46d0-afdc-f8789103f85dc} - 6} filtered by ABE: <.twitter.com> Deny
Although opening twitter with "firefox twitter.com" from the command line works without a problem.

Is this a bug or how do i have to change the rule to get it working again?

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Thu Nov 24, 2016 9:52 pm
by barbaz
Does the issue occur in latest development build 2.9.5.2rc1?

If so, as a workaround, try change your ABE rule to this -

Code: Select all

Site .twitter.com
Accept from .twitter.com moz-nullprincipal:
Deny

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Thu Nov 24, 2016 9:55 pm
by palme
thanks. this works. but is this a bug or a feature?

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Thu Nov 24, 2016 9:57 pm
by barbaz
palme wrote:thanks. this works.
You're welcome, but are you referring to the latest dev build or the change in ABE rule?

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Thu Nov 24, 2016 9:59 pm
by palme
barbaz wrote:
palme wrote:thanks. this works.
You're welcome, but are you referring to the latest dev build or the change in ABE rule?
the rule change works, but the latest version 2.9.5.2rc1 doesnt fix the problem without the rule change

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Thu Nov 24, 2016 10:02 pm
by barbaz
Thanks.

Moving this thread to NoScript Development as a bug report.

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Sat Dec 03, 2016 7:53 pm
by johnscript
I was going to report this issue, looks like it's still there in NoScript 2.9.5.2rc5 .

With a simple rule such as

Code: Select all

Site .informaction.com
Accept from SELF .noscript.net 
Deny
at first just eliminating the leading dot on the first line seems to work, but then eventually ABE will unexpectedly trigger a blocking when moving around, the only way to make this work really is adding moz-nullprincipal: as suggested

Code: Select all

Site .informaction.com
Accept from SELF .noscript.net moz-nullprincipal:
Deny
but what does this moz-nullprincipal: stand for, and what's the meaning of the numerical string that follows moz-nullprincipal: in the ABE error message ?

Are we giving away any security by adding this line to existing ABE rules?

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Sat Dec 03, 2016 8:10 pm
by barbaz
johnscript wrote:but what does this moz-nullprincipal: stand for,
https://developer.mozilla.org/docs/Mozi ... principals
johnscript wrote: what's the meaning of the numerical string that follows moz-nullprincipal: in the ABE error message ?
That's just a UUID. Nothing to see there.

https://www.youtube.com/watch?v=-H10VqfkYOk

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Sun Dec 04, 2016 8:38 pm
by _xx_
Giorgio mentioned here viewtopic.php?f=7&t=22296&p=84979 that with FF53 nightly builds, FF is reporting to NoScript that pages from the command-bar have an origin of moz-nullprincipal[UUID] instead of the system principal, which is apparently a change made somewhere between FF50 and FF53. People in that thread were noticing problems with XSS protection, not ABE, but it seems to be caused by the same problem. He said he's looking for a (temporary) solution.

There is a security issue (as pointed out here viewtopic.php?f=23&t=8870#p45810) with just having a rule of "Accept from moz-nullprincipal:", but as long as you have the actual domain in front of it (meaning it only allows origins of moz-nullprincipal associated with that domain), you'll be fine. The annoying part is that you have to append the moz-nullprincipal to every allow rule for every domain you're loading from the command bar (vs loading from bookmarks).

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Mon Dec 05, 2016 8:54 pm
by johnscript
OK, thanks for the info.

There is a security issue (as pointed out here viewtopic.php?f=23&t=8870#p45810) with just having a rule of "Accept from moz-nullprincipal:"
I thought so, even if it was just a hunch - I don' t really understand this stuff...
but as long as you have the actual domain in front of it (meaning it only allows origins of moz-nullprincipal associated with that domain), you'll be fine.
Yes, that's how I'm appending it to my existing rules (I think) .

In the meantime, I may have spotted something else : since this ABE issue appeared, some ABE rules on certain websites apparently block image downloads.

For instance, a rule like this one

Code: Select all

Site .informaction.com
Anon INC (IMAGE,CSS) from SELF .noscript.net  moz-nullprincipal:
Deny INC SUB
Accept from SELF .noscript.net  moz-nullprincipal:
Deny
will actually block the download of the InformAction logo at the top left of the page styles/prosilver/imageset/site_logo.gif

Removing the just this rule fixes the issue, all other things being equal (no other changes needed) .

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Mon Dec 05, 2016 8:57 pm
by johnscript
This is the error message in the console

Code: Select all

NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0xxxxxx
(NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.responseStatus]
the actual number would be 0x80040111 but that is triggering the forum antispam filter.

which appears related to this line aRequest.responseStatus == 450 in gre/components/DownloadLegacy.js .


Is this possibly related or a totally different issue for which I should open another thread?

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Mon Dec 05, 2016 9:08 pm
by barbaz
Not sure. Looks related enough to leave here for now.

I confirm the failed download. But I get very different console messages.

Code: Select all

DEPRECATION WARNING: saveImageURL should be passed the private state of the containing window.
You may find more details about this deprecation at: https://bugzilla.mozilla.org/show_bug.cgi?id=1243643
chrome://global/content/contentAreaUtils.js 154 saveImageURL
chrome://communicator/content/nsContextMenu.js 1122 nsContextMenu.prototype.saveMedia
chrome://navigator/content/navigator.xul 1 oncommand
this.Deprecated.warning()
Deprecated.jsm:79
saveImageURL()
contentAreaUtils.js:154
nsContextMenu.prototype.saveMedia()
nsContextMenu.js:1122
oncommand()
navigator.xul:1
Deprecated.jsm:79

[ABE] < .informaction.com> Deny SUB INCLUSION on {GET https://forums.informaction.com/images/badge-informaction.png <<< chrome://browser/content/browser.xul - 1}
TEST rule:
Site .informaction.com
Anonymize INCLUSION(IMAGE, CSS) from SELF .noscript.net moz-nullprincipal:
Deny SUB INCLUSION
Accept from SELF .noscript.net moz-nullprincipal:
Deny

NS_ERROR_NOT_AVAILABLE: Cannot call openModalWindow on a hidden windownsPrompter.js:347

NS_ERROR_NOT_AVAILABLE: Cannot call openModalWindow on a hidden window
openModalWindow()
nsPrompter.js:347
ModalPrompter.prototype.openPrompt()
nsPrompter.js:550
ModalPrompter.prototype.alert()
nsPrompter.js:602
Prompter.prototype.alert()
nsPrompter.js:59
DownloadListener/makeClosure/<()
contentAreaUtils.js:282
nsPrompter.js:347
Try this work-around -

Code: Select all

Site .informaction.com
Accept from chrome:
Anon INC (IMAGE,CSS) from SELF .noscript.net  moz-nullprincipal:
Deny INC SUB
Accept from SELF .noscript.net  moz-nullprincipal:
Deny

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Tue Dec 06, 2016 11:45 am
by johnscript
Adding Accept from chrome: right after the domain, as you suggested, does work.

Still, the only error message that I can see without that line is the one I've posted above, there's nothing like that long message you've posted - maybe there's also some interaction with uBlock or some other addon at play.

Then again, same question about before for moz-nullprincipal: , does Accept from chrome: eventually reduce security?

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Tue Dec 06, 2016 12:38 pm
by Giorgio Maone
johnscript wrote:Accept from chrome: eventually reduce security?
No it doesn't: you should get that origin only if you initiate the load from the navigation bar or some add-on.

Re: ABE seems to be broken since the latest release [2.9.5.1

Posted: Tue Dec 06, 2016 2:48 pm
by barbaz
Something very odd I just noticed -
barbaz wrote:[ABE] < .informaction.com> Deny SUB INCLUSION on {GET https://forums.informaction.com/images/badge-informaction.png <<< chrome://browser/content/browser.xul - 1}
TEST rule:
Site .informaction.com
Anonymize INCLUSION(IMAGE, CSS) from SELF .noscript.net moz-nullprincipal:
Deny SUB INCLUSION
Accept from SELF .noscript.net moz-nullprincipal:
Deny
That was from testing on SeaMonkey, which does not have that chrome: URI.
File Not Found

The file chrome://browser/content/browser.xul cannot be found. Please check the location and try again.
Image