John Barberio Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

As demonstrated by the above URL, a page with many embedded images that require authentication causes the 'Authentication Required' dialogue to be shown over and over again.

This gives the possibility of it being used as a DOS style attack, where a page loads random 'authentication required' in a javascript loop, or simply presenting a page with thousands of embeded images.

Reproducible: Always

Steps to Reproduce:
1. Load a page such as http://gobase.org/studying/articles/mioch/7/index.html
2. Authentication Required dialogue appears, and locks out access to the the browser window until dismissed.
3. Authentication Required dialogue appears, and locks out access to the the browser window until dismissed.
4. Authentication Required dialogue appears, and locks out access to the the browser window until dismissed...
(and so on)

	timeless
	Comment 1 • 17 years ago

this is not more interesting than: javascript:while(1)alert(1)

stopping that requires a debugger or some other window where you can inject a replacement alert function or possibly the ability to disable javascript.

the standard dialog has to be content modal. as for javascript, javascript has to be blocking.
http://viper.haque.net/~timeless/blog/8/ is what I wrote about this subject...

For kicks, you can actually trigger this by using Image objects instead of <img> tags.

Most of these problems are solvable. the only problem that's really hard is while 1 alert, but without solving that, trying to fix the other things is really just a waste of time because it's by far the easiest for someone to take if they want to be annoying. (Although fixing that with a sledge hammer is also relatively easy.)

	John Barberio Reporter
	Comment 2 • 17 years ago

To reply to Timeless's comment...

These dialogs are explicitly not *content* modal, they are *window* modal. If they were solely content modal, ie blocking only the rendering of content or processing of script until dismissed, there would not be a problem, the user could simply close that tab or navigate somewhere else. However, they're window modal, and block interaction with the entire window until dismissed. On some platforms this includes being unable to close that window, which for most people means they can't close the browser without taking unusual measures.

	John Barberio Reporter
	Comment 3 • 15 years ago

Prodding this as it's been a year without investigation.

	Vykintas Vyšniauskas
	Comment 4 • 14 years ago

Since bug 59314 landed, is this also planned for Firefox 4? It is quite annoying too...

	Shriram (irc: Mavericks)
	Comment 5 • 12 years ago

Can't see the auth dialog for the test URL

	John Barberio Reporter
	Comment 6 • 12 years ago

Please note the date on the original filing. In the five years that have passed, the page being used for an example has changed it's content, and doesn't demonstrate the issue any more.

You should still be able to recreate the bug by browsing to any page with a long series of http auth required embedded content to recreate the bug. To make it a DOS attack on the user, keep attempting to reload http auth content via javascript.

As a further example, go to http://www.httpwatch.com/httpgallery/authentication/ and try example 10. The dialogue box for auth you get from that javascript triggered event is Window Model in Firefox, so it locks the entire window till you dismiss it.

Now work out what happens for the user if the java script code used were 
 " while (true)
  {
  return ('authenticatedimage/default.aspx?' + Math.random().toString(10));
  }
 "

	Florian Bender
	Comment 7 • 10 years ago

Bug 647010 proposes to disable subresource HTTP-auth prompts. Due to web compat concerns, however, this probably cannot by enabled by default, at least for same-origin subresources. I proposed a pref in Bug 647010 comment 27 so anybody can enable this if wanted.

	Daniël van de Giessen
	Comment 9 • 7 years ago

I just came across a phishing site using the window-modal authentication as a
vector to lock the user on the site. Specifically:

 - It would request authentication with a ransom message as realm, in this case
   something like `Internet Security Alert! WanaCry Ransomware Threat Detected.
   CALL Microsoft <SOME LOCAL PHONE NUMBER HERE> for Free Checkup`.
 - Next, on a failed authentication (probably the user clicking away the modal)
   a HTML page would be returned in the 401, styled like your typical ransomware
   locker screen, complete with MP3 audio and featuring texts like "your
   computer has been locked". Which, incidently, by exploiting the auth modal,
   could actually seem kind of true for a non-technical user.
 - The technical details: the HTML page would contain a line of JavaScript
   triggering a new page load:
   `<script type="text/javascript">window.location="indexx.php";</script>`
   (Also, note the double "x" in the location: every reload another "x" would be
   added. Perhaps to work around limitations on max failed auths per location
   before a browser would just give up? Not sure.)
 - Since the old page would stay rendered while the new auth modal is shown, now
   both the HTML ransomware screen and the ransomware message in the modal are
   visible.
 - And, since closing the auth modal immediately triggers a page load and thus a
   new request and thus a new auth modal, it is impossible for most users to
   close the tab or even close Firefox entirely.

End result is very effective as a phishing attack vector: A maximized window with
a attacker-controlled message is shown, and it cannot be closed, potentially
giving the user a feeling of loss of control, contributing to effectiveness of
the phishing message presented.

I encountered this specific example on the domain hachiko444 dot club, at the
path /nl/indexx.php. Assemble and visit that URL at your own risk. ;) Didn't
spot anything scary myself, but your mileage may vary and you might be safer
using for example curl to examine the HTML source code.

Making auth modals tab-modal, see bug 613785, would effectively kill this attack
vector, since it becomes trivial for a user to just close the offending tab.

Putting this here as to provide a clearer demonstration of how this is being used.

	John Barberio Reporter
	Comment 10 • 7 years ago

Prodding again, on this 11 year old acknowledged security flaw that has exploits in the wild.

Can there please be a security minded review of why this flaw has gone unfixed for 11 years?

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 11 • 7 years ago

In reply to Daniël van de Giessen from comment #9)
> I just came across a phishing site using the window-modal authentication as a
> vector to lock the user on the site. 

Thanks for the heads up Daniel and the clear steps to reproduce. As far as I can see from notes in various related bugs (613785, 1389155) recent abuse in the wild has caused us to revisit 613785. There is work ongoing in this area - see all bugs underneath bug 1271852 - especially bug 647010. The summary is that there are a number of intertwined user interface security improvements being worked on.

(In reply to John Barberio from comment #10)
> Prodding again, on this 11 year old acknowledged security flaw that has
> exploits in the wild.
> 
> Can there please be a security minded review of why this flaw has gone
> unfixed for 11 years?

I'm not sure if the question is rhetorical or not, but while modal authentication dialogs do present a DoS vector, this is only one of many vectors with which a page can DoS the browser (with the user's only choice being to close and restart the browser). (and certainly 11 years ago it was easier still than it is today with the era of multi-process architecture).

If you are genuinely curious about the state and plans of web authentication and UI improvement, see active discussion in bug 613785, bug 647010 and related bugs.

	Daniel Veditz [:dveditz]
	Comment 14 • 6 years ago

Does not meet the severity criteria for the bug bounty program

	Johann Hofmann [:johannh] Assignee
	Comment 17 • 6 years ago

Please don't discuss meta topics like this in the bugs that are tracking the issue. A better place would be e.g. the dev-security mailing list.

We have a lot of high-impact bugs that are stalled this way for a long time, I don't think anyone is seriously scratching their heads as to why it happens, it's usually a combination of:

- Technical complexity requiring hard trade-offs and significant time investment
- Lack of ownership and/or resourcing
- People entrenched on two opposing sides of an important decision
- Inability to compromise on a non-perfect solution (as you describe above)

My experience tells me that things like this are quite hard to prevent preemptively. And it happens to all projects, not just in Bugzilla, but here it's very visible to you because we do it all in public. And maybe it's not a bad thing. I realize that this bug has the highest priority to you, but there are a lot of people in other important bugs who disagree.

	John Barberio Reporter
	Comment 18 • 6 years ago
advocacy-reviewed

Thank you for your reply.

As there appears to be no lead person in charge of security in your project willing to take ownership of the failure, there seems to be no reason for me to keep this issue open as it is unlikely to be fixed. I will discourage use of Firefox and Mozilla based software from use due to systemic problems in responding to security concerns.

	Johann Hofmann [:johannh] Assignee
	Comment 19 • 6 years ago
follow-up-to-spam

"Takes a long time to fix" is not equal to wontfix. We're working on this, so we should keep it open.

	John Barberio Reporter
	Comment 20 • 6 years ago
advocacy-reviewed

I will only accept re-opening of this bug if someone there takes ownership of it, and the Assignee: field is filled out.
Thank you.

	Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo
	Comment 21 • 6 years ago

John, I direct your attention to https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and this passage in particular:

'No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact of and interest in your suggestions.'

Second, there is a team reviewing and responding to security issues, their public activity is part of release notes and a listing of CVEs addressed in Firefox can be found here: https://www.mozilla.org/en-US/security/advisories/

Third, this bug has already been reviewed by the security team and determined not to be a critical issue, please see the comment history.

	:Gijs (he/him)
	Comment 22 • 6 years ago

Also, I'll note that it is not correct to say no work has been done to mitigate attacks here since this was filed, see e.g. bug 1312243.

	fettucini
	Comment 26 • 6 years ago

@Emma Humphries:
Please take under consideration the age of this bug - 11 YEARS. 

Even if it was not identified critical, this behavior indicates badly a designed or implemented application, and the bug was given credit for a reason.

I would agree with the idea, that only discussing issues over such a long time, and not actually getting anywhere, may put off even some very patient users - or even developers. Not the first time to see this here, one of my favorites being:
https://bugzilla.mozilla.org/show_bug.cgi?id=278689

I'd like to suggest implementing a workflow, that automatically bumps aging bugs to the bugmasters (e. g. after 2 years), in order to give it a chance for higher prioritizing or direct assignment - the sooner, the higher their severity is - if not already in place. 

Also, I discourage the application of duplicate-izing bugs too quickly, since that can easily lead to missing a point and closing unresolved issues, e. g.:
https://bugzilla.mozilla.org/show_bug.cgi?id=1237051

Probably, the bugmasters should rather communicate with reporters and split up / create new bugs for issues, that contain in part related, duplicated or completely different issues.

Otherwise, some reporters might be put off and valuable information about issues might be lost.

	Uplink
	Comment 31 • 6 years ago

I've encountered such a page. Its means of continuously displaying the authentication window:

index.html:
<iframe src="page-giving-401.html"></iframe>

page-giving-401.html:
<script>window.location.reload()</script>

Yes, that simple.

Using the mouse to cancel the modal keeps you captive. Pressing the Escape key seems to make FF give up after a few boxes, although it still loads that page forever in the background. The malicious site even had a face Basic Auth box shown - you'd click on it and another window would open, grabbing your browser with modals again.

Behaviour of ther browsers:

- Chrome: It never gives up, it keeps asking you to authenticate, but you can close the tab or navigate to other tabs without any problem whenever you like, because the prompt isn't a modal.

- Edge: It never gives up, and it displays a modal that prevents you from using your browser, but the delay between boxes is so high that you have time to close the tab.

That's all I tried.

	rugk
	Comment 33 • 5 years ago

BTW, this issue is being reported at https://www.zdnet.com/article/malicious-sites-abuse-11-year-old-firefox-bug-that-mozilla-failed-to-fix/

	Charlie Hayes
	Comment 34 • 5 years ago

Along with slashdot: https://news.slashdot.org/story/18/12/10/0220258/malicious-sites-abuse-11-year-old-firefox-bug-that-mozilla-failed-to-fix

	timeless
	Comment 35 • 5 years ago

John, sorry, by "has to be", i didn't mean "it is this way today [when I wrote my comment] because it must be in order to function", but rather "aspirationally, it has to be (future tense) this way in order to not result in problems that you and I were describing".

	alex_mayorga
	Comment 36 • 5 years ago

¡Hola!

The URL on this bug no longer has an 'Authentication Required' dialogue.

So updating the steps and URL here:

Steps:
- Load http://www.httpwatch.com/httpgallery/authentication/#showExample10
- Click "DISPLAY IMAGE"

Actual results:
Firefox becomes unusable until the dialog is dismissed.

Expected results:
Firefox is usable even if the dialog is not dismissed.

The spec at https://tools.ietf.org/html/rfc7617 doesn't seem to indicate the the prompt has to be a modal AFAICT.

¡Gracias!
Alex

	Pulsebot
	Comment 43 • 5 years ago

Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d05f776eb840
Improve auth dialog blocking heuristics. r=MattN
https://hg.mozilla.org/integration/autoland/rev/cf32e70c234f
Add a test for rate limiting the authentication prompt. r=MattN