32.29 KB, image/png
47 bytes, text/x-phabricator-request
|Details | Review|
47 bytes, text/x-phabricator-request
|Details | Review|
Component: General → Security
QA Contact: general → firefox
Whiteboard: [sg:low dos?]
Whiteboard: [sg:low dos?] → [sg:nse dos?]
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.
Whiteboard: [sg:nse dos?] → [sg:dos]
Since bug 59314 landed, is this also planned for Firefox 4? It is quite annoying too...
Can't see the auth dialog for the test URL
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: → 647010
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?
OS: Windows XP → All
Priority: -- → P1
Hardware: x86 → All
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
Priority: P1 → --
Duplicate of this bug: 1425264
Summary: 'Authentication Required' dialogue being application model produces a vector for attack → 'Authentication Required' dialogue being application modal produces a vector for attack
Duplicate of this bug: 1432072
Does not meet the severity criteria for the bug bounty program
Flags: sec-bounty? → sec-bounty-
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: Last year
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: Last year → Last year
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.
Duplicate of this bug: 1439157
Duplicate of this bug: 1447661
@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.
Duplicate of this bug: 1486206
Duplicate of this bug: 1498217
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.
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/
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
6 months ago
Pushed by email@example.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
Attachment #9040430 - Flags: approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.