262887 - (SA12712) Secunia background tab security issues (SA12712 - less critical) -

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Daniel Veditz [:dveditz]]

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

Comment 1

[Daniel Veditz [:dveditz]]

Attachment: input_field_stealer

Comment 2

[Daniel Veditz [:dveditz]]

Attachment: javascript_prompt_box

Comment 3

[Daniel Veditz [:dveditz]]

Attachment: download_box

Comment 4

[Jesse Ruderman]

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

Comment 5

[chris hofmann]

think we can get this for 1.0?

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 7

[Jesse Ruderman]

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

Comment 8

[Daniel Veditz [:dveditz]]

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

Comment 9

[Daniel Veditz [:dveditz]]

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

Comment 10

[Daniel Veditz [:dveditz]]

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

Comment 11

[Daniel Veditz [:dveditz]]

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

Comment 12

[Jakub A.T.]

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.

Comment 13

[Johnny Stenback (:jst)]

Attachment: Make modal DOM dialogs show their tab while open.

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.

Comment 14

[chris hofmann]

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

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 16

[chris hofmann]

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

Comment 17

[Johnny Stenback (:jst)]

Attachment: Updated diff, stay at the opening tab when the modal dialog is dismissed.

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 18

[Ben Goodger (use ben at mozilla dot org for email)]

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

r=[e-mail]

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Johnny Stenback (:jst)]

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

Comment 21

[Daniel Veditz [:dveditz]]

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

Comment 22

[Johnny Stenback (:jst)]

(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 23

[chris hofmann]

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

Comment 24

[Johnny Stenback (:jst)]

Fixed on the aviary branch.

Comment 25

[Johnny Stenback (:jst)]

Attachment: Aviary patch that was checked in.

Comment 26

[[e-mail]]

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 27

[Johnny Stenback (:jst)]

Attachment: 1.7 branch diff.

Comment 28

[Mike Kaply [:mkaply]]

Comment on attachment 164295 [details] [diff] [review]
1.7 branch diff.

bleah. It's a security bug, we need it.

Comment 29

[Johnny Stenback (:jst)]

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

Comment 30

[[e-mail]]

Attachment: More advanced version of attachment 161075

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

Comment 31

[Juha-Matti Laurio]

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/

Comment 32

[Daniel Veditz [:dveditz]]

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.

Comment 33

[Arun Nallan]

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/

Comment 34

[Phil Ringnalda (:philor)]

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

Comment 35

[Juha-Matti Laurio]

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.

Comment 36

[HJ]

(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?

Comment 37

[HJ]

Easy fix for attachment 164571 [details] ;)

-            if (browsers[i].contentWindow == event.target) {
+            if (browsers[i].contentWindow == event.target.top) {

Comment 38

[HJ]

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 39

[Johnny Stenback (:jst)]

Attachment: Fix for the more advanced version of the dialog spoof

Comment 40

[Johnny Stenback (:jst)]

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.

Comment 41

[Johnny Stenback (:jst)]

(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.

Comment 42

[HJ]

(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,
[e-mail] 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 43

[HJ]

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

Comment 44

[Aaron Slunt]

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

Comment 45

[Asa Dotzler [:asa]]

1.7.5 has shipped. Moving request to 1.7.6.

Comment 46

[Daniel Veditz [:dveditz]]

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

Comment 47

[Daniel Veditz [:dveditz]]

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 48

[Asa Dotzler [:asa]]

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

Comment 49

[Johnny Stenback (:jst)]

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

Comment 50

[HJ]

(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 51

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Complete patch, backported to 1.4

Comment 52

[Johnny Stenback (:jst)]

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

r=jst

Comment 53

[OstGote!]

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

Comment 54

[Daniel Veditz [:dveditz]]

blocking to make sure the 1.7 branch matches Firefox behavior.

Comment 55

[chris hofmann]

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

Comment 56

[Asa Dotzler [:asa]]

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

Comment 57

[Brian Ryner (not reading)]

checked in on aviary 1.0.1 and 1.7 branches

Comment 58

[Jay Patel [:jay]]

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

Comment 59

[Bart S]

(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. 

Comment 60

[Bart S]

(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(