Closed Bug 377496 Opened 18 years ago Closed 6 years ago

'Authentication Required' dialogue being application modal produces a vector for attack

Categories

(Firefox :: Security, defect, P1)

Product:
Firefox
Component:
Security
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 67
Tracking Flags:
Tracking Status
firefox-esr60 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- verified
firefox67 --- verified

People

(Reporter: barberio, Assigned: johannh)

References

(Blocks 2 open bugs,
URL
)

Details

(Keywords: csectype-dos, sec-want, Whiteboard: [sg:dos][adv-main66-])

Attachments

(3 files)

authentication dialog handling in opera 11
(deleted), image/png
Details
Bug 377496 - Improve auth dialog blocking heuristics. r=MattN
(deleted), text/x-phabricator-request
lizzard
: approval-mozilla-beta+
Details
Bug 377496 - Add a test for rate limiting the authentication prompt. r=MattN
(deleted), text/x-phabricator-request
lizzard
: approval-mozilla-beta+
Details
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)
Component: General → Security
QA Contact: general → firefox
Whiteboard: [sg:low dos?]
Whiteboard: [sg:low dos?] → [sg:nse dos?]
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.)
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.
Prodding this as it's been a year without investigation.
Blocks: eviltraps
Whiteboard: [sg:nse dos?] → [sg:dos]
Since bug 59314 landed, is this also planned for Firefox 4? It is quite annoying too...
Depends on: 613785
Can't see the auth dialog for the test URL
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)); } "
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.
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=647010
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.
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?
Flags: sec-bounty?
Flags: needinfo?(wleung)
OS: Windows XP → All
Priority: -- → P1
Hardware: x86 → All
Flags: needinfo?(wleung) → needinfo?(ptheriault)
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.
Severity: critical → enhancement
Flags: needinfo?(ptheriault)
Keywords: sec-want
Priority: P1 → --
Summary: 'Authentication Required' dialogue being application model produces a vector for attack → 'Authentication Required' dialogue being application modal produces a vector for attack
Does not meet the severity criteria for the bug bounty program
Flags: sec-bounty? → sec-bounty-
Blocks: 1435085
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.
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
"Takes a long time to fix" is not equal to wontfix. We're working on this, so we should keep it open.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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.
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.
@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.
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.
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".
¡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
URL: http://gobase.org/studying/articles/m... → http://www.httpwatch.com/httpgallery/...

I've looked into this a bit with the intent of coming up with a short term fix. I'll summarize the state of this issue and chart a path forward for the short and long term:

The issue

The basic auth prompt in Firefox is window modal and blocks the entire browser from being interacted with when open. This can be easily abused by websites to effectively prevent users from using Firefox ("DOS"). It is made extra bad by the fact that the dialog shows a credentials field and that websites can provide a message to the user. This is often combined with locking the user in DOM fullscreen, auto-playing sound and offering extension installs to "fix" some "virus".

This bug has gone unsolved for a long time because a previous attempt at short term mitigation failed (bug 1312243) and other possible solutions pose a significant engineering challenge that no team of experienced Firefox engineers has been resourced to work on.

Proposed short term mitigation

The fix in bug 1312243 introduced a maximum of three consecutive cancelations (controlled by a pref) that a user could perform until Firefox would prevent the page from showing more dialogs.

This, in my opinion, is a great idea. The implementation, however, has a major fallacy: It checks the inner window id in the well-meaning attempt to find user navigation or reloads and clears its internal counter when that window id changes. Unfortunately this also clears the counter on non-user-initiated navigations and reloads. I believe that the true intention of the patch was to cancel the auth dialog after 3 attempts, except if:

  • The user reloads the page on their own terms
  • The user navigates to a different site on their own

Which is what I plan to implement, using the same pattern we applied to implement temporarily blocked site permissions:

  • Temporarily store basic auth counter state on the browser object, as a map from baseDomain (eTLD+1) to number of cancellations
  • Reset this state only on user initiated reload
  • Reset the counter for a domain if the user has entered login data into the dialog and submitted

This would mitigate the DOS issue while hopefully not breaking any sites that rely on basic auth.

In addition to that, we plan to put in place other short-term mitigations for the abuse of DOM fullscreen, specifically in combination with showing prompts like the auth prompt, extension install prompts or permission prompts.

Long term solution

While the above proposal does help against a DOS attack, the simple fact that a website can spawn an application modal dialog that forces you to enter your credentials is, to say the least, not optimal. To properly and finally solve the full extent of this issue, there are two more bugs we need to tackle:

  • Bug 1426656, which would add a "Prevent this website from showing auth dialogs" checkbox to the auth dialog, making it clearer to the user that this isn't something they have to put up with (similar to the alert() dialog)
  • Bug 613785, which makes the auth dialog tab modal.

Comments appreciated.

Assignee: nobody → jhofmann
Status: REOPENED → ASSIGNED
status-firefox64: affected → wontfix
status-firefox65: affected → wontfix
status-firefox67: --- → affected
No longer depends on: 613785
Keywords: csectype-dos
Priority: -- → P1
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=613785, https://bugzilla.mozilla.org/show_bug.cgi?id=1426656, https://bugzilla.mozilla.org/show_bug.cgi?id=1312243

The fix in bug 1312243 introduced a maximum of three consecutive cancelations (controlled by a pref) that a user could perform until Firefox would prevent the page from showing more dialogs.

This, in my opinion, is a great idea. The implementation, however, has a major fallacy: It checks the inner window id in the well-meaning attempt to find user navigation or reloads and clears its internal counter when that window id changes. Unfortunately this also clears the counter on non-user-initiated navigations and reloads. I believe that the true intention of the patch was to cancel the auth dialog after 3 attempts, except if:

  • The user reloads the page on their own terms
  • The user navigates to a different site on their own

Which is what I plan to implement, using the same pattern we applied to implement temporarily blocked site permissions:

  • Temporarily store basic auth counter state on the browser object, as a map from baseDomain (eTLD+1) to number of cancellations
  • Reset this state only on user initiated reload
  • Reset the counter for a domain if the user has entered login data into the dialog and submitted

This would mitigate the DOS issue while hopefully not breaking any sites that rely on basic auth.

Matt, I'll look into testing this tomorrow, feel free to go slow on the review. I just wanted to have the patch up for feedback quickly.

(In reply to Johann Hofmann [:johannh] from comment #37)

I think on the whole this is the right approach. I would actually propose we set the limit to 1 dialog, not 3. If the user needs that dialog they can refresh and/or actually input something, which would reset the counter. One other thing:

  • Bug 613785, which makes the auth dialog tab modal.

Comments appreciated.

bug 613785 comment 21 is still applicable, it seems, in that we'd need to ensure that things work correctly when http auth blocks blocking resources. I suspect that's the hard part, IIRC making the dialog tab-modal could in theory be done just by passing the right "allow tabmodal" bool via the propbag given to the alerts service.

(In reply to :Gijs (he/him) from comment #40)

(In reply to Johann Hofmann [:johannh] from comment #37)

I think on the whole this is the right approach. I would actually propose we set the limit to 1 dialog, not 3. If the user needs that dialog they can refresh and/or actually input something, which would reset the counter.

Yeah, I actually agree with you but I think there are folks who don't. Maybe an IRC/vidyo conversation can help clear this up, and I think we should defer it to another bug and start a conversation there. 3 is a very good start if it's properly enforced.

  • Bug 613785, which makes the auth dialog tab modal.

Comments appreciated.

bug 613785 comment 21 is still applicable, it seems, in that we'd need to ensure that things work correctly when http auth blocks blocking resources. I suspect that's the hard part, IIRC making the dialog tab-modal could in theory be done just by passing the right "allow tabmodal" bool via the propbag given to the alerts service.

Yes, I still believe that making the dialog tab modal is the end game for this issue, but this is sort of what I was referring to when I wrote about technical complexities that prevent a faster solution. I think in this case it boils down to the "blocking subresources" thing and also the fact that showing an auth dialog completely in content land, without overlapping chrome, might not be something we want to do. The WebPayments team had a POC for a dialog that prevents these two issues AFAIK but it's just not a short term solution.

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

https://hg.mozilla.org/mozilla-central/rev/d05f776eb840
https://hg.mozilla.org/mozilla-central/rev/cf32e70c234f

Status: ASSIGNED → RESOLVED
Closed: 7 years ago → 6 years ago
status-firefox67: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

I don't think bug 1525267 is related. That's a different issue altogether.

Blocks: 1530395

Now that bug 1525267 is fixed we figured we could go for a late 66 uplift, considering that this is being exploited in the wild.

Blocks: 1532338

Comment on attachment 9039990 [details]
Bug 377496 - Improve auth dialog blocking heuristics. r=MattN

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: None
  • User impact if declined: Fake malware sites blackmail users into giving out their credentials, installing real malware, and/or calling expensive "support" hotlines.

I'm sure you've seen one of those.

  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: It might be nice to do a QA round of sites that require basic auth (though I'm not aware of any). They should still function.
  • List of other uplifts needed: Bug 1525267
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): This patch had a lot of bake-time and should be quite safe to take, but we moved a few things around in bug 1525267, which didn't have as much bake. Overall I think given the fact that this is actively being exploited in the wild it could be worth taking the small risk.
  • String changes made/needed: None
Attachment #9039990 - Flags: approval-mozilla-beta?

Comment on attachment 9039990 [details]
Bug 377496 - Improve auth dialog blocking heuristics. r=MattN

Has test coverage, security improvement for users, let's give it a try.

Attachment #9039990 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Whiteboard: [sg:dos] → [sg:dos][adv-main66-]
Flags: qe-verify+

I was able to reproduce the issue on older Beta (20190128143734) and Firefox release builds using the steps from comment 36.

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

The issue is verified as fixed on the latest Beta 67.0b7 (20190331141835) and Firefox 66.0.2 (20190326175229). The authentication prompt isn't displayed after the third attempt to accept or dismiss it.

Status: RESOLVED → VERIFIED
status-firefox66: fixed → verified
status-firefox67: fixed → verified
Flags: qe-verify+

As of Firefox 73.0, it's back, and being actively used in an attack right now. Ubuntu Linux 18.04 LTS.

See image: https://i.imgur.com/EOUCK0i.png

This is coupled with an attack which uses large amounts of memory in the browser. So, even though Firefox offers the option to stop the page, you can't click on it because the basic authentication prompt blocks other interaction.

Repeated clicking on the "cancel" button for the basic authentication prompt does not dismiss it.

Note: someone has purchased a large number of Bing keywords leading to the attack site, including "firefox bug", so this is going to have some current impact.

(In reply to John Nagle from comment #52)

Note: someone has purchased a large number of Bing keywords leading to the attack site, including "firefox bug", so this is going to have some current impact.

Can you please open a new bug blocking this one using this URL and putting some info in there - such as the URL of the website where it happens?

Thanks!

Flags: needinfo?(nagle)

As requested, opened a new bug at:

https://bugzilla.mozilla.org/show_bug.cgi?id=377496

Attack page redirects to http://165.22.224.156

Flags: needinfo?(nagle)

(In reply to John Nagle from comment #54)

As requested, opened a new bug at:

https://bugzilla.mozilla.org/show_bug.cgi?id=377496

I think you pasted the wrong bug 🙂
The new bug is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1616126

See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1616126
Keywords: regression
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: