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)

ARM
Android
defect
Not set
critical

Tracking

(firefox19 wontfix, firefox20 affected, firefox21 fixed, firefox22 fixed)

VERIFIED FIXED
Firefox 22
Tracking Status
firefox19 --- wontfix
firefox20 --- affected
firefox21 --- fixed
firefox22 --- fixed

People

(Reporter: masayuki, Assigned: mfinkle)

References

()

Details

(Whiteboard: [parity-Chrome][parity-Opera][parity-Stock])

Attachments

(1 file)

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.
FYI: Google Chrome for Android shows checkbox for stopping the attack.
Do you know who should take this?
Flags: needinfo?(mbrubeck)
Assigning to Wes
Assignee: nobody → wjohnston
Flags: needinfo?(mbrubeck)
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
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: wjohnston → mark.finkle
Attached patch patchSplinter Review
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 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+
Thank you for the quick fix.

I'd like drivers to decide which release should take this.
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?
Summary: Firefox for Android cannot against loop + alert attack → Firefox for Android cannot break out of a loop + alert attack
Whiteboard: [parity-Chrome] → [parity-Chrome][parity-Opera][parity-Stock]
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+
(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.
https://hg.mozilla.org/mozilla-central/rev/797fdffba764
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
QA Contact: aaron.train
Verified fixed on latest m-c
Status: RESOLVED → VERIFIED
(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.
Not backed out from Aurora 21.
Target Milestone: --- → Firefox 22
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: