[FIXED] NoScript 10.1.7.3 causes Firefox 59.0.1 to freeze

[KonomiKitten]

NoScript 10.1.7.3 causes Firefox 59.0.1 to freeze when visiting this URL https://www.huffingtonpost.com.au/2017/ ... _21646943/

Code: Select all

Application Basics
------------------

Name: Firefox
Version: 59.0.1
Build ID: 20180315233128
Update Channel: release
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
OS: Linux 4.9.0-6-amd64
Multiprocess Windows: 1/1 (Enabled by default)
Web Content Processes: 4/4
Stylo: content = true (enabled by default), chrome = false (disabled by default)
Google Key: Found
Mozilla Location Service Key: Found
Safe Mode: false

Code: Select all

Extensions
----------

Name: NoScript
Version: 10.1.7.3
Enabled: false
ID: {73a6fe31-595d-460b-a920-fcc0f8843232}

[Giorgio Maone]

The extension details say "Enabled: false" but I suppose NoScript was enabled when it happened, wasn't it?
Anyway, could you please

1. Share your NoScript Options>Export output (by email if you prefer)
2. Check whether latest development build 10.1.7.4rc1 help

?
Thank you!

[KonomiKitten]

The extension details say "Enabled: false" but I suppose NoScript was enabled when it happened, wasn't it?

Correct

Check whether latest development build 10.1.7.4rc1 help

Still freezes sadly.

Share your NoScript Options>Export output (by email if you prefer)

Code: Select all

{
  "policy": {
    "DEFAULT": {
      "capabilities": [
        "frame",
        "fetch",
        "other"
      ],
      "temp": false
    },
    "TRUSTED": {
      "capabilities": [
        "script",
        "object",
        "media",
        "frame",
        "font",
        "webgl",
        "fetch",
        "other"
      ],
      "temp": false
    },
    "UNTRUSTED": {
      "capabilities": [],
      "temp": false
    },
    "sites": {
      "trusted": [
        "§:addons.mozilla.org",
        "§:afx.ms",
        "§:ajax.aspnetcdn.com",
        "§:ajax.googleapis.com",
        "§:bootstrapcdn.com",
        "§:code.jquery.com",
        "§:firstdata.com",
        "§:firstdata.lv",
        "§:gfx.ms",
        "§:google.com",
        "§:googlevideo.com",
        "§:gstatic.com",
        "§:hotmail.com",
        "§:live.com",
        "§:live.net",
        "§:maps.googleapis.com",
        "§:mozilla.net",
        "§:netflix.com",
        "§:nflxext.com",
        "§:nflximg.com",
        "§:nflxvideo.net",
        "§:noscript.net",
        "§:outlook.com",
        "§:passport.com",
        "§:passport.net",
        "§:passportimages.com",
        "§:paypal.com",
        "§:paypalobjects.com",
        "§:securecode.com",
        "§:securesuite.net",
        "§:sfx.ms",
        "§:tinymce.cachefly.net",
        "§:wlxrs.com",
        "§:yahoo.com",
        "§:yahooapis.com",
        "§:yimg.com",
        "§:youtube.com",
        "§:ytimg.com"
      ],
      "untrusted": [],
      "custom": {}
    },
    "enforced": false,
    "autoAllowTop": false
  },
  "local": {
    "debug": false,
    "showCtxMenuItem": true,
    "showCountBadge": true,
    "showFullAddresses": false,
    "storage": "local",
    "uuid": "f0234288-0dab-41d2-aad7-98850488202d"
  },
  "sync": {
    "global": false,
    "xss": true,
    "clearclick": true,
    "storage": "sync"
  },
  "xssUserChoices": {}
}

[Giorgio Maone]

The most notable thing in your configuration is that you've "Scripts globally allowed (dangerous)" box ticked.
That's admittedly a setting which has not been thoroughly tested in real-world scenarios, mostly because it's a "last resort" switch cutting out the whole permissions system.
You can achieve a similar but much more controlled effect by configuring the DEFAULT preset with the permissions you think should be granted to all the pages: this way you can still use the UNTRUSTED one to restrict the capabilities of selected pages.

Actually, I'm very tempted to move that option away from the General tab (in the Advanced, maybe) and/or to rename it to something more descriptive of its actual meaning, quite different than the "Classic" one, like "Disable restrictions on scripting and active content even on UNTRUSTED sites". Maybe giving feedback about this disablement by disabling or hiding also the preset themselves and the per-site permissions tab while it's checked would be a good idea.

I'm currently investigating what makes the "rest" of NoScript (most likely the XSS filter) freeze the browser on that page when the permissions enforcing subsystem is disabled. Thanks for sharing your data.

[KonomiKitten]

That's admittedly a setting which has not been thoroughly tested in real-world scenarios, mostly because it's a "last resort" switch cutting out the whole permissions system.

Yeah I generally do that because I don't want to permit each website to run JavaScript and I just want NoScript for it's other protections.

You can achieve a similar but much more controlled effect by configuring the DEFAULT preset with the permissions you think should be granted to all the pages: this way you can still use the UNTRUSTED one to restrict the capabilities of selected pages.

I wasn't aware of this, sounds much better I'm going to use this from now on.

Actually, I'm very tempted to move that option away from the General tab (in the Advanced, maybe) and/or to rename it to something more descriptive of its actual meaning, quite different than the "Classic" one, like "Disable restrictions on scripting and active content even on UNTRUSTED sites". Maybe giving feedback about this disablement by disabling or hiding also the preset themselves and the per-site permissions tab while it's checked would be a good idea.

Oh I thought it did what the classic one does, I'd say it would definitely be a good idea to rename and move it to better express what it does.

I'm currently investigating what makes the "rest" of NoScript (most likely the XSS filter) freeze the browser on that page when the permissions enforcing subsystem is disabled. Thanks for sharing your data.

I actually still get a freeze with permitting scripts in DEFAULT only and going to the page so I'm not sure it's just the permission subsystem causing the problem.

Edit: Removed all the settings since the next post details exactly how to reproduce the freeze.

[KonomiKitten]

Follow up, I've managed to narrow down the exact permissions to reproduce the freeze.

1. Reset NoScript Settings.
2. Go to https://www.huffingtonpost.com.au/2017/ ... _21646943/
3. Permit

Code: Select all

huffingtonpost.com.au

4. Permit

Code: Select all

twitter.com

After step 4 when Firefox tries to reload it will reload forever and freeze needing a force quit. Hope this helps with debugging.

Edit: I've replicated these steps even in a completely fresh profile with the stable version of NoScript and the freeze occurs there too.

[pal1000]

I was looking into this as well.
This issue can be reproduced with default settings.
Version 10.1.7.4rc1 is affected. This can be reproduced on Windows as well.

- Visit https://www.huffingtonpost.com.au/2017/ ... _21646943/
- Trust huffingtonpost.com.au or https://www.huffingtonpost.com.au;
- Trust twitter.com and witness the issue.
You can reproduce in a more granular way by trusting https://platform.twitter.com first, then https://syndication.twitter.com, so the hang occurs when https://syndication.twitter.com is trusted. Further tests indicate this issue occurs only when the frame permission is granted to trusted sites.

Clean recovery tip: Open Add-Ons Manager, disable and then re-enable NoScript. You don't even have to close any tab. This is standard web-extension unblocking procedure.

[Giorgio Maone]

Found the culprit, thanks the detailed reports by KonomiKitten and pal1000.
I'm gonna release a fix later today

[Giorgio Maone]

Should be fixed in latest development build, please verify, thanks.
v 10.1.7.4rc2
=============================================================
x Fixed "Appearance" NoScript Options tab missing on Android
x [XSS] Fixed semicolon-separated JSON payloads DDOSing the
JSON-optimizer, e.g. with syndication.twitter.com subframes
(thanks KonomiKitten and pal1000 for reports)
x [UI] Renamed "Scripts globally allowed (dangerous)" option
to "No permissions enforcement (dangerous)" to better
reflect its actual effect
x [UI] Better feedback about "No permission enforcement" by
disabling the "Preset customization" section and and the
"Per-site Permissions" tab
x [UI] Moved XSS-related options to the "Advanced" tab

[pal1000]

I confirm it's fixed. Thanks.

[KonomiKitten]

Awesome, thanks for the hard work fixed here.