Closed Bug 1613735 Opened 6 years ago Closed 6 years ago

denial of service in firefox with NoScript if the symbol # is appended many times after an URL

Categories

(WebExtensions :: Developer Outreach, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mittererdaniel, Unassigned)

Details

(Keywords: csectype-dos, sec-other)

Attachments

(1 file)

Attached file test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

My OS:Windows 10 Home x64
append a large number of the '#' symbol after the URL. For example https://example.com/####...
this error can be reproduced by either entering such a URL in the browser bar and click search / connect or by clicking on a link in a webpage.
testfile is also included with this bug report.

Actual results:

unable to connect to any Websites at all (refreshing old tabs doesnt work ,new Tabs and entering URLs dont work ,searching in address bar also doesnt work), restart fixes problem.

Expected results:

Website should load / Error message. Firefox Developer Edition doesn't have this issue,Chrome + IE also do not have it.

(In reply to Daniel Mitterer from comment #0)

Firefox Developer Edition doesn't have this issue

This is a little suspicious; there's not that much difference between Firefox devedition and release (only 1 version, so about 4-6 weeks of development time, and some default settings are different).

Can you reproduce this issue on a clean profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles ) with Firefox release? I could not reproduce it on the original development version of 72, at least (nor on current 73 beta, or on nightly). Tested on macOS. It seems plausible that this has something to do with a setting or an add-on, rather than with Firefox itself.

Flags: needinfo?(mittererdaniel)

i used a clean profile and it didnt happen.
so i tried reinstalling all my extensions and refreshing my test site until i reached noscript.
Only with noscript turned on this bug happens. so this is not a firefox bug.

Flags: needinfo?(mittererdaniel)

i will report this to the noscript dev team

(In reply to Daniel Mitterer from comment #3)

i will report this to the noscript dev team

Thanks for the super quick response! Yes, reporting to noscript would be a good idea. Because Giorgio also has a bugzilla account, I'm going to ping them here in case this turns out to be an issue with a webextension API or similar that we still need to address within Firefox. I tried to get a quick performance profile to see where the slowness comes from, but when the browser hangs, the profiler UI hangs too so that didn't work out... Hopefully Giorgio can figure this one out.

Group: firefox-core-security → core-security-release
Component: Untriaged → Other
Flags: needinfo?(g.maone)
Product: Firefox → External Software Affecting Firefox
Version: 72 Branch → unspecified

This most likely takes a heavy CPU toll on the XSS filter (even though it should stop after a 20 secs anti-DOS timeout). If my theory is correct, I'm gonna fix it very shortly in next release.
Thank you for reporting.

Flags: needinfo?(g.maone)

I can confirm this URL causes the XSS filter parser being DOSed (just for 20 seconds at most, though, as expected). However, I couldn't reproduce the "block everything" behavior, because the browser (except for NoScript's UI) remains responsive enough (due to the parser yielding on long processing tasks by design) to allow me opening new tabs, closing the current one or even using the [X] stop button and interrupting the loading.
Unfortunately, as I said, NoScript does remain unresponsive until the parsing is done or the timeout is reached, so it's a DOS against NoScript at least and needs to be fixed. Working on it.

Component: Other → Developer Outreach
Product: External Software Affecting Firefox → WebExtensions

Update.
I've just finished making a big change in the XSS filter, quite scary but resolutive to handle all the future situations like this: moved all the potentially long-running injection checking logic in a dedicated WebWorker, rather than just breaking it in asynchronous mini-tasks and yielding between them, like it used to be. This WebWorker is forcibly terminated on a 20 seconds timeout, in which case a "20 secs timeout exceeded: DOS attack?" XSS prompt is issued, and user can choose to go ahead or block the request with the usual "potential XSS" UI.
In any case, all the processing happens in the background and both the browser and NoScript's UI remains responsive all the time (it can even handle other interactive "potential XSS" instances in the meanwhile).

Now I just need to fix the actual "multiple hashes" bug (even though the above fully mitigates it) and release.
Thank you for this incentive to finally complete an overdue, albeit daunting, task :)

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: denial of service in firefox if the symbol # is appended many times after an URL → denial of service in firefox with NoScript if the symbol # is appended many times after an URL

Thanks for jumping on this Giorgio. Marking P3 to get it out of our triage, but feel free to adjust and/or close as appropriate.

Priority: -- → P3

I've just released NoScript 11.0.14rc1 my the Beta Channel and submitted 11.0.14 to AMO for approval in the stable release channel.
They both contain the "scary change" I mentioned in comment #7, quite refined to ensure a smooth user experience.
By refactoring the InjectionChecker into a WebWorker the whole UI (both Firefox's and NoScript's) remains responsive all the time, and after 20 seconds users are presented with a "Potential XSS Warning" mentioning that maybe a DOS attempt as made and showing the offending URL, giving users the choice to block or go on like it happens for other loads triggering the filter.

In the end I decided not to work around the specific test case reported here and based on the repetition of about 120,000 "#" characters, because honestly there are several similar ways to choke the multiple parsers and regular expressions used by the InjectionChecker, and trying to chase each one would be of low value and high risk of regressions on the filter's sensitivity.

On the other hand, I believe this change is an usable and robust way to handle the whole class of possible DOS attempts, much like the JavaScript timeout dialog did for script-based DOS attacks in HTML web pages.

If there's no objection, I'm gonna close this as soon as 10.0.14 is approved by AMO editors and auto-updated in the release channel.

NoScript 11.0.15 has been released on the stable AMO channel.
Closing, thanks.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: