Last Comment Bug 262887 - (SA12712) Secunia background tab security issues (SA12712 - less critical) -
(SA12712)
: Secunia background tab security issues (SA12712 - less critical) -
Status: VERIFIED FIXED
http://secunia.com/advisories/12712/ ...
: fixed-aviary1.0.1, fixed1.4.4, fixed1.7.6, meta
Product: SeaMonkey
Classification: Client Software
Component: Tabbed Browser (show other bugs)
: Trunk
: All All
: -- major with 6 votes (vote)
: ---
Assigned To: Brian Ryner (not reading)
:
Mentors:
http://secunia.com/advisories/12712
: 265266 265267 266357 272877 276517 (view as bug list)
Depends on: 121209 123908 123913 124750
Blocks: sa13599
  Show dependency treegraph
 
Reported: 2004-10-04 13:55 PDT by Daniel Veditz [:dveditz]
Modified: 2014-04-26 03:21 PDT (History)
38 users (show)
dveditz: blocking1.7.6+
chofmann: blocking‑aviary1.0+
dveditz: blocking‑aviary1.0.1+
chofmann: blocking‑aviary1.0.1+
chofmann: blocking‑aviary1.5-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
input_field_stealer (406 bytes, text/html)
2004-10-04 13:56 PDT, Daniel Veditz [:dveditz]
no flags Details
javascript_prompt_box (680 bytes, text/html)
2004-10-04 13:56 PDT, Daniel Veditz [:dveditz]
no flags Details
download_box (607 bytes, text/html)
2004-10-04 13:57 PDT, Daniel Veditz [:dveditz]
no flags Details
Make modal DOM dialogs show their tab while open. (17.14 KB, patch)
2004-10-27 11:50 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Review
Updated diff, stay at the opening tab when the modal dialog is dismissed. (17.39 KB, patch)
2004-10-29 14:42 PDT, Johnny Stenback (:jst, jst@mozilla.com)
bugs: review+
bryner: superreview+
chofmann: approval‑aviary+
Details | Diff | Review
Aviary patch that was checked in. (17.24 KB, patch)
2004-10-29 23:01 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Review
1.7 branch diff. (18.33 KB, patch)
2004-11-02 10:45 PST, Johnny Stenback (:jst, jst@mozilla.com)
mozilla: approval1.7.5+
Details | Diff | Review
More advanced version of attachment 161075 (168 bytes, text/html)
2004-11-04 06:27 PST, neil@parkwaycc.co.uk
no flags Details
Fix for the more advanced version of the dialog spoof (2.35 KB, patch)
2004-12-16 17:06 PST, Johnny Stenback (:jst, jst@mozilla.com)
bugs4hj: review+
dveditz: superreview+
asa: approval‑aviary1.0.1+
dveditz: approval1.7.6+
asa: approval1.8a6+
Details | Diff | Review
Complete patch, backported to 1.4 (8.67 KB, patch)
2005-01-25 12:30 PST, Christopher Aillon (sabbatical, not receiving bugmail)
jst: review+
Details | Diff | Review

Description Daniel Veditz [:dveditz] 2004-10-04 13:55:11 PDT
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] 2004-10-04 13:56:09 PDT
Created attachment 161074 [details]
input_field_stealer
Comment 2 Daniel Veditz [:dveditz] 2004-10-04 13:56:39 PDT
Created attachment 161075 [details]
javascript_prompt_box
Comment 3 Daniel Veditz [:dveditz] 2004-10-04 13:57:12 PDT
Created attachment 161076 [details]
download_box
Comment 4 Jesse Ruderman 2004-10-04 15:34:12 PDT
The problems with dialogs have been discussed in bug 123913, bug 123908, and bug
121209.
Comment 5 chris hofmann 2004-10-05 17:51:25 PDT
think we can get this for 1.0?
Comment 6 Ben Goodger (use ben at mozilla dot org for email) 2004-10-05 20:39:11 PDT
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 2004-10-05 21:31:12 PDT
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] 2004-10-05 23:50:10 PDT
Or including the site name in the dialog title, instead of generic things like
[Javascript Application]?
Comment 9 Daniel Veditz [:dveditz] 2004-10-20 13:36:40 PDT
Removing confidential flag: Secunia published their advisory today, embargo lifted.
Comment 10 Daniel Veditz [:dveditz] 2004-10-20 13:38:33 PDT
*** Bug 265266 has been marked as a duplicate of this bug. ***
Comment 11 Daniel Veditz [:dveditz] 2004-10-20 13:39:43 PDT
*** Bug 265267 has been marked as a duplicate of this bug. ***
Comment 12 Jakub A.T. 2004-10-26 01:30:46 PDT
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, jst@mozilla.com) 2004-10-27 11:50:13 PDT
Created attachment 163615 [details] [diff] [review]
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 2004-10-27 13:59:57 PDT
if this looks safe we should consider for 1.0.  putting back on the radar.
Comment 15 Henrik Skupin (:whimboo) 2004-10-28 01:01:07 PDT
*** Bug 266357 has been marked as a duplicate of this bug. ***
Comment 16 chris hofmann 2004-10-28 16:23:54 PDT
update to patch coming...  think we will leave the user at the tab assoicated
with the alert.
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-29 14:42:46 PDT
Created attachment 163896 [details] [diff] [review]
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) 2004-10-29 14:44:54 PDT
Comment on attachment 163896 [details] [diff] [review]
Updated diff, stay at the opening tab when the modal dialog is dismissed.

r=ben@mozilla.org
Comment 19 Boris Zbarsky [:bz] (Out June 25-July 6) 2004-10-29 14:57:09 PDT
Any chance of making the browser/tabbrowser changes to xpfe as well?
Comment 20 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-29 15:36:31 PDT
Yeah, I'll make the changes for 1.7 as well once I get to catch my breath...
Comment 21 Daniel Veditz [:dveditz] 2004-10-29 15:53:14 PDT
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, jst@mozilla.com) 2004-10-29 16:13:11 PDT
(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 2004-10-29 16:28:04 PDT
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, jst@mozilla.com) 2004-10-29 22:58:46 PDT
Fixed on the aviary branch.
Comment 25 Johnny Stenback (:jst, jst@mozilla.com) 2004-10-29 23:01:05 PDT
Created attachment 163936 [details] [diff] [review]
Aviary patch that was checked in.
Comment 26 neil@parkwaycc.co.uk 2004-10-30 04:08:20 PDT
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, jst@mozilla.com) 2004-11-02 10:45:15 PST
Created attachment 164295 [details] [diff] [review]
1.7 branch diff.
Comment 28 Mike Kaply [:mkaply] (Out June 27-July 5) 2004-11-02 12:02:09 PST
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, jst@mozilla.com) 2004-11-03 09:51:19 PST
Fix for the modal DOM dialog problem landed on the trunk and 1.7 branch too.
Comment 30 neil@parkwaycc.co.uk 2004-11-04 06:27:54 PST
Created attachment 164571 [details]
More advanced version of attachment 161075 [details]

This one doesn't trigger the tab switch (yet!)
Comment 31 Juha-Matti Laurio 2004-11-10 07:21:29 PST
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] 2004-11-10 16:50:49 PST
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 2004-11-14 07:10:45 PST
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) 2004-12-02 21:53:32 PST
*** Bug 272877 has been marked as a duplicate of this bug. ***
Comment 35 Juha-Matti Laurio 2004-12-06 06:26:26 PST
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 2004-12-15 16:35:49 PST
(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 2004-12-15 16:50:33 PST
Easy fix for attachment 164571 [details] ;)

-            if (browsers[i].contentWindow == event.target) {
+            if (browsers[i].contentWindow == event.target.top) {
Comment 38 HJ 2004-12-15 17:07:05 PST
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, jst@mozilla.com) 2004-12-16 17:06:57 PST
Created attachment 168913 [details] [diff] [review]
Fix for the more advanced version of the dialog spoof
Comment 40 Johnny Stenback (:jst, jst@mozilla.com) 2004-12-16 17:10:24 PST
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, jst@mozilla.com) 2004-12-16 17:33:50 PST
(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 2004-12-16 17:52:41 PST
(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 43 HJ 2004-12-17 05:14:02 PST
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 2004-12-17 13:57:18 PST
Is this going to warrant a security patch release, and firefox 1.0.1?
Comment 45 Asa Dotzler [:asa] 2004-12-18 11:56:16 PST
1.7.5 has shipped. Moving request to 1.7.6.
Comment 46 Daniel Veditz [:dveditz] 2005-01-03 10:26:47 PST
*** Bug 276517 has been marked as a duplicate of this bug. ***
Comment 47 Daniel Veditz [:dveditz] 2005-01-03 10:30:59 PST
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] 2005-01-06 08:10:07 PST
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, jst@mozilla.com) 2005-01-06 08:15:59 PST
Fix landed on trunk. Leaving bug open to track the remaining issues.
Comment 50 HJ 2005-01-08 19:58:18 PST
(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) 2005-01-25 12:30:01 PST
Created attachment 172380 [details] [diff] [review]
Complete patch, backported to 1.4
Comment 52 Johnny Stenback (:jst, jst@mozilla.com) 2005-01-25 15:39:27 PST
Comment on attachment 172380 [details] [diff] [review]
Complete patch, backported to 1.4

r=jst
Comment 53 OstGote! 2005-01-26 03:36:34 PST
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] 2005-02-04 12:56:00 PST
blocking to make sure the 1.7 branch matches Firefox behavior.
Comment 55 chris hofmann 2005-02-04 12:58:40 PST
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] 2005-02-10 13:03:05 PST
bryner, can you land this whereever it needs landing and add appropriated fixed*
keywords? thanks.
Comment 57 Brian Ryner (not reading) 2005-02-10 13:52:06 PST
checked in on aviary 1.0.1 and 1.7 branches
Comment 58 Jay Patel [:jay] 2005-02-19 14:53:50 PST
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 2005-03-27 22:24:50 PST
(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 2005-03-27 22:29:20 PST
(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(

Note You need to log in before you can comment on or make changes to this bug.