Jakob Balle of Secunia writes us with a collection of vulnerabilities related to background tabs. Assigning to Bryner who recently fixed bug 124750, which appears to fix (or hide?) the input stealing variant described here. The Secunia link in the URL field will be blank until October 20, 2004 The dialog-on-background-tab issues sound dupe-ish to me. I confirm all three symptoms in both Firefox 1.0PR and Mozilla 1.7.3, and that the input-stealing one appears fixed in today's Firefox build. By "minimized" tab I'm pretty sure Jakob means "background"; that's how I tested. - - - - - - Hello, I have found 3 vulnerabilities in the way Mozilla and Mozilla Firefox handles tabbed browsing. The vulnerabilities have been confirmed in: - Mozilla Firefox 0.10.1 on Linux - Mozilla 1.7.3 on Linux 1) It is possible for a "minimised" tab to always gain focus on a form field in the "minimised" tab, even if the user is browsing a completely different website in another tab. This is escalated a bit by the fact that most people do not look at the monitor while typing data into a form field, and therefore might send data to the site in the "minimised" tab, instead of the intended/viewed tab. Demonstration Description: 1. Open a new blank tab, and load the example file called "input_field_stealer.html" 2. Open the displayed link in a new tab and make sure you are viewing the new tab. 3. Try to enter data in e.g. any form field on the newly opened tab, or try to enter data in the address bar. 4. Everything you enter will be listed in the "textarea" in the tab opened in step 1. Demonstration File: input_field_stealer.html 2) It is possible for a "minimised" tab to spawn a JavaScript "Prompt" dialog box, which looks to be originating from the currently viewed tab. It is not possible for the user to see which web-site actually launched the prompt box, and therefore the user could be be lead to believe that it is a genuine prompt box coming from e.g. their bank's web-site. Demonstration Description: 1. Open a new blank tab, og load the example file called "javascript_prompt_box.html" 2. Open the displayed link in a new tab and make sure you are viewing the new tab. 3. Wait about 6 seconds and a JavaScript prompt dialog box will be launched. 4. Everything you enter will be listed in the "textarea" in the tab opened in step 1. Demonstration File: javascript_prompt_box.html 3) It is possible for a "minimised" tab to spawn a download dialog box, which looks to be originating from the currently viewed tab. This could be exploited to trick the user into downloading and running a harmful program. Demonstration Description: 1. Open a new blank tab, og load the example file called "download_box.html" 2. Open the displayed link in a new tab and make sure you are viewing the new tab. 3. Wait about 6 seconds and a download dialog box will be launched. NOTE: This demonstration requests a web page located at Secunia, the only thing this page does is to send the following: Content-Type: application/octet Content-Disposition: attachment; filename="Latest Citibank Netbank Version.exe" ... Demonstration File: download_box.html We have reserved SA12712 for these vulnerabilities and are currently planning to issue the information at 20/10/2004. Let me know if there is anything I may be able to help with. Jakob Balle, Secunia

The problems with dialogs have been discussed in bug 123913, bug 123908, and bug 121209.

think we can get this for 1.0?

I'm going to guess no. From what I've been told we have the focus stealing but but there's no way we can get the per-tab-modality to work before 1.0.

If we can't have per-tab modality for 1.0, how about automatically selecting the tab before displaying the dialog?

Or including the site name in the dialog title, instead of generic things like [Javascript Application]?

Removing confidential flag: Secunia published their advisory today, embargo lifted.

*** Bug 265266 has been marked as a duplicate of this bug. ***

*** Bug 265267 has been marked as a duplicate of this bug. ***

I thing that some solution to this bug SHOULD be found before version 1.0 for marketing reasons otherwise it is easy to imagine, that this can be used AGAINST mozillafirefox. Imagine articles like: "List of security holes in the first release of FIreFox" etc. With a little imagination it would not be hard to write an article which could put uninformed audience to doubt about qualities of FF. Surely it need not to be the most clean solution, but it should work even if it causes some annoyance [like automatically selecting the tab before displaying the dialog] and it could be switched off.

This makes alert/prompt/confirm make the tab in which they're called the current tab while the modal dialog is open. Fixes the prompt and related problems, but doesn't fix the download dialog problem.

if this looks safe we should consider for 1.0. putting back on the radar.

*** Bug 266357 has been marked as a duplicate of this bug. ***

update to patch coming... think we will leave the user at the tab assoicated with the alert.

This makes us do what we discussed yesteday at the aviary meeting, in stead of switching back to the tab where the user was when the before the modal dialog opened, we'll just remain on the tab that opened the modal dialog after the user dismisses the dialog. This also makes the tab switching more correct.

Comment on attachment 163896 [details] [diff] [review] Updated diff, stay at the opening tab when the modal dialog is dismissed. r=ben@mozilla.org

Any chance of making the browser/tabbrowser changes to xpfe as well?

Yeah, I'll make the changes for 1.7 as well once I get to catch my breath...

Comment on attachment 163896 [details] [diff] [review] Updated diff, stay at the opening tab when the modal dialog is dismissed. Sorry for being so slow, I had trouble applying this to my tree (my fault) and it took a while to get it working. This is not only an aviary patch, but firefox-only. Will need additional patching in xpfe for the trunk and 1.7 branches (1.7 because we'll be releasing that after ff-final and need to be able to say this is fixed there, too). >Index: browser/base/content/browser.js >+ if (getBrowser().isHandlingModalDialog) { >+ gURLBar.value = location; >+ SetPageProxyState("valid", aLocation); >+ } else { Won't this also need the hack for 249322? Add a redundant gURLBar.value = ""; // hack for bug 249322 line before setting the location. In accordance with Neil's comments, you can simplify my earlier patch as long as you're here (I did on the trunk) >+ setTimeout(function(loc, aloc) { >+ gURLBar.value = ""; // hack for bug 249322 >+ gURLBar.value = loc; >+ SetPageProxyState("valid", aloc); >+ }, 0, location, aLocation); r=dveditz fwiw, but I think you need the 249322 hack

(In reply to comment #21) > >Index: browser/base/content/browser.js > >+ if (getBrowser().isHandlingModalDialog) { > >+ gURLBar.value = location; > >+ SetPageProxyState("valid", aLocation); > >+ } else { > > Won't this also need the hack for 249322? Add a redundant > gURLBar.value = ""; // hack for bug 249322 > line before setting the location. I don't *think* I need that here as the location being set in all the cases where isHandlingModalSialog (forceSyncURLBarUpdate in the latest diff, and this property and check should ideally go away too as there doesn't seem to be a real need to set the value of the URL bar off of a timer) is true we're setting the location to a value that has already gone through our fixup code etc. I'll add that code just to be on the safe side tho... > In accordance with Neil's comments, you can > simplify my earlier patch as long as you're here (I did on the trunk) Done. Thanks for the feedback!

Comment on attachment 163896 [details] [diff] [review] Updated diff, stay at the opening tab when the modal dialog is dismissed. a=chofmann for the branches

Fixed on the aviary branch.

Comment on attachment 163896 [details] [diff] [review] Updated diff, stay at the opening tab when the modal dialog is dismissed. OK, so what happens if you load attachment 161075 [details] in a frame?

Comment on attachment 164295 [details] [diff] [review] 1.7 branch diff. bleah. It's a security bug, we need it.

Fix for the modal DOM dialog problem landed on the trunk and 1.7 branch too.

This one doesn't trigger the tab switch (yet!)

Secunia has updated it's advisory and marked issues fixed in Firefox 1.0 now (Secunia's page updated on 9th November): "Mozilla Firefox: Update to version 1.0." http://secunia.com/advisories/12712/

Note that we have only partially fixed the "download box" case. As given the download box example also uses the flaw from "javascript prompt box" so it may appear fixed, but you could still use *just* the download prompt. A spoof would be --much-- less convincing without the initial prompt, but it might still be possible to fool some people with a descriptive enough file name.

Hi guys, when i tried testing the input stealing functionality, everything worked fine.. but I guess it needs more work. I tested http://secunia.com/multiple_browsers_form_field_focus_test/ and switched off "Begin finding when you are typing" and for some reason, the Input stealing issue is still pending. Is it fixed yet? I am using version 1.0 Arun (In reply to comment #31) > Secunia has updated it's advisory and marked issues fixed in Firefox 1.0 now > (Secunia's page updated on 9th November): > > "Mozilla Firefox: > Update to version 1.0." > > http://secunia.com/advisories/12712/

*** Bug 272877 has been marked as a duplicate of this bug. ***

Secunia.com advisory was updated again today, it's now containing text "Firefox is still affected by a variant of the first vulnerability. Added 'Firefox 1.x' as vulnerable." (Company's statistics page for Mozilla Firefox 1.x contains now one 'Partial Fix' advisory.) Like mentioned in comment #32, it's fixed only partially.

(In reply to comment #30) > Created an attachment (id=164571) [edit] > More advanced version of attachment 161075 [details] [edit] > > This one doesn't trigger the tab switch (yet!) That's because of that frame I guess? Do we need some additional JS code in tabbrowser.xml to match the tab, or will someone change the C source for this?

Easy fix for attachment 164571 [details] ;) - if (browsers[i].contentWindow == event.target) { + if (browsers[i].contentWindow == event.target.top) {

What about setting a new attribute on the target tab in 'DOMWillOpenModalDialog' because that will enable additional styling for themes. I did something similar already for MultiZilla (see also: http://bugzilla.mozdev.org/attachment.cgi?id=2465&action=view)

Comment on attachment 168913 [details] [diff] [review] Fix for the more advanced version of the dialog spoof This diff is good for aviary and 1.7.5 and trunk, but the xpfe changes don't apply on the aviary branch, but that's ok as that version if tabbrowser.xml is not used there at all.

(In reply to comment #37) > Easy fix for attachment 164571 [details] [edit] ;) > > - if (browsers[i].contentWindow == event.target) { > + if (browsers[i].contentWindow == event.target.top) { HJ, I meant to say here before attaching my diff that this is the right fix, but it needs to ensure that it gets the real 'top', not a user-defined property named 'top'. My patch takes care of that too. As for new attributes etc, that'd be cool (not that I'm one to decide that), but that should be a separate bug.

(In reply to comment #41) > (In reply to comment #37) > > Easy fix for attachment 164571 [details] [edit] [edit] ;) > > > > - if (browsers[i].contentWindow == event.target) { > > + if (browsers[i].contentWindow == event.target.top) { > > HJ, I meant to say here before attaching my diff that this is the right fix, but > it needs to ensure that it gets the real 'top', not a user-defined property > named 'top'. My patch takes care of that too. No problem, and I am fully aware of the security implication of this, in fact I used something similar for MultiZilla weeks ago, but I didn't want to ring other peoples 'bells' before this was fixed (I was blamed for doing so months ago) I was sure that the "Easy" part would trigger some attention, as it did. Hey, neil@parkwaycc.co.uk should remember me asking about XPCNativeWrapper in the newsgroup ;) > As for new attributes etc, that'd be cool (not that I'm one to decide that), but > that should be a separate bug.

Comment on attachment 168913 [details] [diff] [review] Fix for the more advanced version of the dialog spoof Well, why don't I review this patch, because I know tabbrowser.xml very well I think

Is this going to warrant a security patch release, and firefox 1.0.1?

1.7.5 has shipped. Moving request to 1.7.6.

*** Bug 276517 has been marked as a duplicate of this bug. ***

Comment on attachment 168913 [details] [diff] [review] Fix for the more advanced version of the dialog spoof sr=dveditz, a=dveditz for 1.7.6 Should this land on the aviary branch in case of a 1.0.1?

Comment on attachment 168913 [details] [diff] [review] Fix for the more advanced version of the dialog spoof a=asa for 1.8a6 checkin and 1.0.1 checkin in case we end up doing a 1.0.1

Fix landed on trunk. Leaving bug open to track the remaining issues.

(In reply to comment #49) > Fix landed on trunk. Leaving bug open to track the remaining issues. Johnny, thanks for landing this, but what about triggering DOMWillOpenModalDialog for alert/prompt? Will that work for you?

Comment on attachment 172380 [details] [diff] [review] Complete patch, backported to 1.4 r=jst

Patch (attachment 168913 [details] [diff] [review]) has approval1.7.6+ but was still not checked in for the 1.7 branch.

blocking to make sure the 1.7 branch matches Firefox behavior.

sounds like we need to + for 1.0.1 and 1.7.6 and minus for 1.1 since the latest patch is on the trunk... need to get these fixes on the branches

bryner, can you land this whereever it needs landing and add appropriated fixed* keywords? thanks.

checked in on aviary 1.0.1 and 1.7 branches

Verified Fixed. Aviary 1.0.1 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20050218 Firefox/1.0 Mozilla 1.7.6 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050217

(In reply to comment #26) > (From update of attachment 163896 [details] [diff] [review] [edit]) > OK, so what happens if you load attachment 161075 [details] [edit] in a frame? > Status shows FIXED. however with my system : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.6) Gecko/20050321 Firefox/1.0.2 executing attachment 161075 [details] is still popping up a stealer dialog.

(In reply to comment #59) > (In reply to comment #26) > > (From update of attachment 163896 [details] [diff] [review] [edit] [edit]) > > OK, so what happens if you load attachment 161075 [details] [edit] [edit] in a frame? > > > > Status shows FIXED. however with my system : Mozilla/5.0 (Windows; U; Windows NT > 5.1; en-GB; rv:1.7.6) Gecko/20050321 Firefox/1.0.2 > > executing attachment 161075 [details] [edit] is still popping up a stealer dialog. Sorry. I didn't notice the tab-switch :o(