Closed Bug 262887 (SA12712) Opened 16 years ago Closed 16 years ago

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

Categories

(SeaMonkey :: Tabbed Browser, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dveditz, Assigned: bryner)

References

(Depends on 1 open bug, )

Details

(4 keywords, Whiteboard: http://secunia.com/advisories/12712/ have patch - need to land)

Attachments

(9 files, 1 obsolete file)

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
Attached file input_field_stealer
Attached file javascript_prompt_box
Attached file download_box
Depends on: 124750
The problems with dialogs have been discussed in bug 123913, bug 123908, and bug
121209.
Depends on: 121209, 123908, 123913
Keywords: meta
Flags: blocking1.7.x?
Flags: blocking-aviary1.0?
think we can get this for 1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.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. 
Flags: blocking-aviary1.0+ → blocking-aviary1.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.
Whiteboard: http://secunia.com/advisories/12712/
Alias: SA12712
*** Bug 265266 has been marked as a duplicate of this bug. ***
Group: security
*** Bug 265267 has been marked as a duplicate of this bug. ***
Summary: Secunia background tab security issues → Secunia background tab security issues (SA12712)
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.
Attachment #163615 - Flags: superreview?(bryner)
Attachment #163615 - Flags: review?(dveditz)
if this looks safe we should consider for 1.0.  putting back on the radar.
Flags: blocking-aviary1.0- → blocking-aviary1.0+
*** 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.
Attachment #163615 - Attachment is obsolete: true
Attachment #163896 - Flags: superreview?(bryner)
Attachment #163896 - Flags: review?(bugs)
Attachment #163615 - Flags: superreview?(bryner)
Attachment #163615 - Flags: review?(dveditz)
Comment on attachment 163896 [details] [diff] [review]
Updated diff, stay at the opening tab when the modal dialog is dismissed.

r=ben@mozilla.org
Attachment #163896 - Flags: review?(bugs) → review+
Attachment #163896 - Flags: superreview?(bryner) → superreview+
Attachment #163896 - Flags: approval-aviary?
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
Attachment #163896 - Flags: approval-aviary? → approval-aviary+
Fixed on the aviary branch.
Keywords: fixed-aviary1.0
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?
Attachment #164295 - Flags: approval1.7.x?
Comment on attachment 164295 [details] [diff] [review]
1.7 branch diff.

bleah. It's a security bug, we need it.
Attachment #164295 - Flags: approval1.7.x? → approval1.7.x-
Attachment #164295 - Flags: approval1.7.x- → approval1.7.x+
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)
Attachment #168913 - Flags: superreview?(dveditz)
Attachment #168913 - Flags: review?(caillon)
Attachment #168913 - Flags: approval1.7.5?
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.
Attachment #168913 - Flags: approval1.7.5? → approval1.7.6?
(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
Attachment #168913 - Flags: review?(caillon) → review+
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.
Flags: blocking1.7.5? → blocking1.7.6?
Blocks: sa13599
*** 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?
Attachment #168913 - Flags: superreview?(dveditz)
Attachment #168913 - Flags: superreview+
Attachment #168913 - Flags: approval1.7.6?
Attachment #168913 - Flags: approval1.7.6+
Attachment #168913 - Flags: approval1.8a6?
Attachment #168913 - Flags: approval-aviary1.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
Attachment #168913 - Flags: approval1.8a6?
Attachment #168913 - Flags: approval1.8a6+
Attachment #168913 - Flags: approval-aviary1.0.1?
Attachment #168913 - Flags: approval-aviary1.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
Attachment #172380 - Flags: review?(jst) → review+
Patch (attachment 168913 [details] [diff] [review]) has approval1.7.6+ but was still not checked in for
the 1.7 branch.
Flags: blocking-aviary1.1?
blocking to make sure the 1.7 branch matches Firefox behavior.
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1+
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
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
Flags: blocking-aviary1.0.1+
bryner, can you land this whereever it needs landing and add appropriated fixed*
keywords? thanks.
Whiteboard: http://secunia.com/advisories/12712/ → http://secunia.com/advisories/12712/ have patch - need to land
checked in on aviary 1.0.1 and 1.7 branches
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Summary: Secunia background tab security issues (SA12712) → Secunia background tab security issues (SA12712 - less critical) -
(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(
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.