Closed
Bug 854340
Opened 11 years ago
Closed 11 years ago
Firefox for Android cannot break out of a loop + alert attack
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(firefox19 wontfix, firefox20 affected, firefox21 fixed, firefox22 fixed)
VERIFIED
FIXED
Firefox 22
People
(Reporter: masayuki, Assigned: mfinkle)
References
()
Details
(Whiteboard: [parity-Chrome][parity-Opera][parity-Stock])
Attachments
(1 file)
1.85 KB,
patch
|
wesj
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
lsblakk
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
Such as data:text/html,<script>for(;;){alert("heh");}</script>, Firefox for Android don't have a solution for attempting to stop the script by a checkbox. This attack is now being spread by twitter in Japan.
Reporter | ||
Comment 1•11 years ago
|
||
FYI: Google Chrome for Android shows checkbox for stopping the attack.
Assignee | ||
Comment 3•11 years ago
|
||
Assigning to Wes
Assignee: nobody → wjohnston
Flags: needinfo?(mbrubeck)
Assignee | ||
Comment 4•11 years ago
|
||
I'm not sure why this is not just working. It looks like all the code is cross platform: http://hg.mozilla.org/mozilla-central/rev/e036427942ff
Assignee | ||
Comment 5•11 years ago
|
||
A quick look with JimDB shows: * The dialog never wants to be blocked. This check is always false: http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#5136 * mLastDialogQuitTime always seems to be null (0) http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#2847 * LeaveModalState is never called so the mLastDialogQuitTime is never set: http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#7219
Assignee | ||
Updated•11 years ago
|
Assignee: wjohnston → mark.finkle
Assignee | ||
Comment 6•11 years ago
|
||
This patch adds calls to enter and leave modal state. Desktop does that here: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/prompts/src/nsPrompter.js#387 http://mxr.mozilla.org/mozilla-central/source/toolkit/components/prompts/src/nsPrompter.js#401 I could try to reuse the winUtil variable in the patch, but it seemed lie a small win, if any.
Attachment #729756 -
Flags: review?(wjohnston)
Comment 7•11 years ago
|
||
Comment on attachment 729756 [details] [diff] [review] patch Review of attachment 729756 [details] [diff] [review]: ----------------------------------------------------------------- ::: mobile/android/components/PromptService.js @@ +132,2 @@ > PromptUtils.fireDialogEvent(this._domWin, "DOMWillOpenModalDialog"); > + winUtils = this._domWin.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDOMWindowUtils); let winUtils. It might be nice to cache this object. If we have a _domWin, we can assume we have a callerWin and a winUtils later... I think? @@ +145,5 @@ > + > + let retval = PromptUtils.sendMessageToJava(msg); > + > + if (this._domWin) { > + if (callerWin) { I'm not sure we really need this check. If we get here and have a _domWin but no callerWin, something strange has happened. @@ +146,5 @@ > + let retval = PromptUtils.sendMessageToJava(msg); > + > + if (this._domWin) { > + if (callerWin) { > + winUtils = this._domWin.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDOMWindowUtils); if you leave this in, let winUtils
Attachment #729756 -
Flags: review?(wjohnston) → review+
Reporter | ||
Comment 8•11 years ago
|
||
Thank you for the quick fix. I'd like drivers to decide which release should take this.
status-firefox19:
--- → wontfix
status-firefox20:
--- → affected
status-firefox21:
--- → affected
status-firefox22:
--- → affected
tracking-firefox20:
--- → ?
tracking-firefox21:
--- → ?
tracking-firefox22:
--- → ?
Assignee | ||
Comment 9•11 years ago
|
||
Landed with the "let" fixes remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/797fdffba764
Assignee | ||
Comment 10•11 years ago
|
||
Comment on attachment 729756 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: User can get into a dialog box loop Testing completed (on m-c, etc.): landed Risk to taking this patch (and alternatives if risky): not too risky. adds code desktop already uses for alerts. String or UUID changes made by this patch: none I think it's too late to make it into beta (fx20) so I am not even requesting. Maybe if we need to respin a beta?
Attachment #729756 -
Flags: approval-mozilla-aurora?
Assignee | ||
Updated•11 years ago
|
Summary: Firefox for Android cannot against loop + alert attack → Firefox for Android cannot break out of a loop + alert attack
Updated•11 years ago
|
Whiteboard: [parity-Chrome] → [parity-Chrome][parity-Opera][parity-Stock]
Comment 11•11 years ago
|
||
Comment on attachment 729756 [details] [diff] [review] patch [Triage Comment] This is a low risk fix (code we've already had in desktop for a while) that will add a checkbox to let users out of this loop. Because this 'prank' (non-security risk but VERY annoying) can be played from *any* weblink and it renders the installed Firefox completely unusable (users would have to uninstall/reinstall) I think we should take this all the way up and do respins of FF20 beta & rc.
Attachment #729756 -
Flags: approval-mozilla-release+
Attachment #729756 -
Flags: approval-mozilla-beta+
Attachment #729756 -
Flags: approval-mozilla-aurora?
Attachment #729756 -
Flags: approval-mozilla-aurora+
Comment 12•11 years ago
|
||
(In reply to lsblakk@mozilla.com from comment #11) > ... (users would have to uninstall/reinstall) That's not true. Just have to quit the browser and re-open it.
Comment 13•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/797fdffba764
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
Updated•11 years ago
|
QA Contact: aaron.train
Comment 14•11 years ago
|
||
Verified fixed on latest m-c
Updated•11 years ago
|
Status: RESOLVED → VERIFIED
Updated•11 years ago
|
Assignee | ||
Comment 15•11 years ago
|
||
aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/2b921224a702 beta: https://hg.mozilla.org/releases/mozilla-beta/rev/05c78f110edf release (default): http://hg.mozilla.org/releases/mozilla-release/rev/03dab2c24ba2 release (relbranch): http://hg.mozilla.org/releases/mozilla-release/rev/e34c8b3ff887
Assignee | ||
Updated•11 years ago
|
Comment 16•11 years ago
|
||
(In reply to Aaron Train [:aaronmt] from comment #12) > (In reply to lsblakk@mozilla.com from comment #11) > > ... (users would have to uninstall/reinstall) > > That's not true. Just have to quit the browser and re-open it. Ah. I didn't know that I wasn't doing this correctly so based on this it's less urgent and reduces risk to late potential web regressions to just leave this in FF20 for now. If this has a wider impact and seems to be spreading quickly or targeting Firefox specifically we can re-evaluate.
Assignee | ||
Comment 17•11 years ago
|
||
Backed out: beta: https://hg.mozilla.org/releases/mozilla-beta/rev/e19936aa55e6 release (default): http://hg.mozilla.org/releases/mozilla-release/rev/b55444cd0930 release (relbranch): http://hg.mozilla.org/releases/mozilla-release/rev/1d8a8bb252e7
Target Milestone: Firefox 22 → ---
Updated•11 years ago
|
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•