Last Comment Bug 726264 - (CVE-2012-3984) Firefox 10.0.1 : Navigation away from a page with multiple active <select> dropdown menu can be used for Spoofing And ClickJacking with XPI using window.open and geolocalisation
: (CVE-2012-3984) Firefox 10.0.1 : Navigation away from a page with multiple ac...
Status: RESOLVED FIXED
[sg:critical][advisory-tracking+] cro...
: sec-critical
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: 10 Branch
: All All
: -- normal (vote)
: mozilla16
Assigned To: Mats Palmgren (:mats)
:
Mentors:
http://www.alternativ-testing.fr/Rese...
: 729475 (view as bug list)
Depends on: CVE-2012-3984
Blocks: 314939
  Show dependency treegraph
 
Reported: 2012-02-10 22:43 PST by Jordi Chancel
Modified: 2015-07-29 15:11 PDT (History)
21 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
wontfix
+
wontfix
+
wontfix
+
wontfix
+
fixed
-
wontfix


Attachments
TESTCASE.ZIP (39.41 KB, application/octet-stream)
2012-02-10 22:43 PST, Jordi Chancel
no flags Details
ScreenShot (158.11 KB, image/png)
2012-02-11 00:53 PST, Jordi Chancel
no flags Details
TESTCASE 1.1 (39.21 KB, application/java-archive)
2012-02-11 02:53 PST, Jordi Chancel
no flags Details
ScreenShot 1.1 (167.99 KB, image/png)
2012-02-11 02:57 PST, Jordi Chancel
no flags Details
fix (5.08 KB, patch)
2012-04-05 13:33 PDT, Mats Palmgren (:mats)
bugs: review+
Details | Diff | Review

Description Jordi Chancel 2012-02-10 22:43:16 PST
Created attachment 596272 [details]
TESTCASE.ZIP

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Build ID: 20120208060813

Steps to reproduce:

Like bug 575294 , Firefox 10.0.1 shows the dropdown menu for <select> elements as an always-on-top chromeless window. It also allows arbitrary HTML content to be rendered in the <option> elements within the <select>.




Actual results:

This bug demonstrates than an attacker can cover a  XPI for evil.

I think this issue is critical.
Comment 1 Jordi Chancel 2012-02-10 23:44:43 PST
this issue works only if a user disabled the pop-up blocker or allowed pop-ups for this site.
Comment 2 Jordi Chancel 2012-02-11 00:53:11 PST
Created attachment 596280 [details]
ScreenShot
Comment 3 Jordi Chancel 2012-02-11 02:53:54 PST
Created attachment 596294 [details]
TESTCASE 1.1
Comment 4 Jordi Chancel 2012-02-11 02:57:23 PST
Created attachment 596295 [details]
ScreenShot 1.1
Comment 5 Jordi Chancel 2012-02-11 04:16:25 PST
With an additional vulnerability like bug 645699 (Non-whitelisted site can trigger xpinstall) this vulnerability don't requiere to click on the XPI dialog pre-loading.
Comment 6 Jordi Chancel 2012-02-11 07:43:36 PST
This issue works on Opera 11.61 too!
Comment 7 Al Billings [:abillings] 2012-02-16 17:47:26 PST
Confirming. This is worth investigating.
Comment 8 Jet Villegas (:jet) 2012-02-17 10:50:45 PST
Mats: can you take a look at this and add your findings? It seems we should ensure that we destroy any floating <select> widgets when the doc has gone out of focus.
Comment 9 Mats Palmgren (:mats) 2012-02-17 11:13:42 PST
Olli, will this be fixed by your patch in bug 575294?
Comment 10 Daniel Veditz [:dveditz] 2012-02-17 15:52:04 PST
Created attachment 598409 [details]
Bug Bounty non-qual
Comment 11 Jordi Chancel 2012-02-17 22:38:46 PST
I'm the reporter of this vuln but i can't see the attachment 598409 [details]!
Comment 12 Jordi Chancel 2012-02-17 22:39:02 PST
confidence reigns!
Comment 13 Jesse Ruderman 2012-02-17 23:41:47 PST
The attachment you can't see is a placeholder related to the bug bounty. Its contents are "Security Bug Bounty nomination placeholder". It's a kludge to work around a missing Bugzilla feature.

http://www.mozilla.org/security/bug-bounty.html
Comment 14 Jordi Chancel 2012-02-20 05:37:33 PST
I've found a new way for allow this clickjacking/spoofing attack with document.location (so without window.open).

Can i report this?
Comment 15 Al Billings [:abillings] 2012-02-21 16:48:45 PST
(In reply to Jordi Chancel from comment #14)
> I've found a new way for allow this clickjacking/spoofing attack with
> document.location (so without window.open).
> 
> Can i report this?

Feel free to open an additional security bug or e-mail security@mozilla.org with the details encrypted with our key from http://www.mozilla.org/security/.
Comment 16 Jordi Chancel 2012-02-22 04:24:33 PST
(In reply to Al Billings [:abillings] from comment #15)
> (In reply to Jordi Chancel from comment #14)
> > I've found a new way for allow this clickjacking/spoofing attack with
> > document.location (so without window.open).
> > 
> > Can i report this?
> 
> Feel free to open an additional security bug or e-mail security@mozilla.org
> with the details encrypted with our key from
> http://www.mozilla.org/security/.

reported => https://bugzilla.mozilla.org/show_bug.cgi?id=729475
Comment 17 Daniel Veditz [:dveditz] 2012-02-22 16:24:45 PST
*** Bug 729475 has been marked as a duplicate of this bug. ***
Comment 19 Daniel Veditz [:dveditz] 2012-03-15 15:40:49 PDT
For bounty purposes this appears to be essentially the same as bug 691014, a specific example that proved bug 575294 is critically dangerous. We still need to fix bug 575294 and when we do this problem will also be fixed.
Comment 20 Johnathan Nightingale [:johnath] 2012-03-26 06:24:37 PDT
->Core::Widget like bug 575294
Comment 21 Mats Palmgren (:mats) 2012-04-05 13:33:57 PDT
Created attachment 612672 [details] [diff] [review]
fix

This issue is orthogonal to bug 575294.
The problem here is that we open the dropdown menu before the
control has focus so we never get a blur which would close it.

The suggested fix is to delay opening the menu until we get
focus -- and if we never get it the focus has moved somewhere
else (as is the case when opening a new window from onmousedown)
and there's no need to open it (we normally close it on blur).
Comment 22 Mats Palmgren (:mats) 2012-04-05 13:52:33 PDT
Try build (including bug 575294) is green on all platforms.
The builds are available for testing here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mpalmgren@mozilla.com-748972c39205/
Comment 23 Jordi Chancel 2012-04-05 15:53:17 PDT
fixed for me
Comment 24 Olli Pettay [:smaug] 2012-04-06 02:11:24 PDT
Comment on attachment 612672 [details] [diff] [review]
fix


> 
>+  /** Current state of the dropdown list, true is dropped down. */
>+  bool                  mDroppedDown;
>+  /** See comment in HandleRedisplayTextEvent(). */
>+  bool                  mInRedisplayText;
>+  /** Acting on ShowDropDown(true) is delayed until we're focused. */
>+  bool                  mDelayedShowDropDown;
>+
The code around uses // comments.
Comment 25 Mats Palmgren (:mats) 2012-04-06 06:42:47 PDT
> The code around uses // comments.

OK, I'll change it to // for consistency.
Comment 26 Jordi Chancel 2012-04-06 10:08:42 PDT
It will be fabulous if This bug will be fixed with other of my bug like Bug 687745 and Bug 700080! :)
Comment 27 Jordi Chancel 2012-04-06 10:09:57 PDT
like three vulnerability of me into the same update 8D !
Comment 28 Al Billings [:abillings] 2012-04-12 16:33:17 PDT
Mats, when do we expect this to land?
Comment 29 Mats Palmgren (:mats) 2012-04-12 16:47:24 PDT
I'm waiting for review in bug 575294.  I'd like to push them together since that's
the combination I've tested, and also to not draw unnecessary attention to <select>
before both lands.
Comment 31 Alex Keybl [:akeybl] 2012-05-21 10:41:39 PDT
Mats let us know this is likely too risky to get into FF13. Marking 14+ for the ESR.
Comment 33 Phil Ringnalda (:philor) 2012-05-28 22:54:19 PDT
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/8a8c0d8b1ac7 - something in that push caused bug 759243, where test_hiddenitems.xul failed every run but didn't get counted as a failure unless something else in the run failed.
Comment 35 :Ehsan Akhgari (busy, don't ask for review please) 2012-06-02 12:19:43 PDT
https://hg.mozilla.org/mozilla-central/rev/6bcea3a628d8
Comment 36 Mats Palmgren (:mats) 2012-06-03 09:13:23 PDT
The patch here is fine, but it was backed out since it was in the same
range as bug 575294 that got backed out:

Backed out bug 575294 and bug 726264:
https://tbpl.mozilla.org/?usebuildbot=1&rev=e7ca047b71b2
Comment 37 Alex Keybl [:akeybl] 2012-06-22 13:42:01 PDT
This bug does not have a patch landed on m-c, so clearing the ESR tracking flag for now.
Comment 40 Jordi Chancel 2012-06-23 09:27:19 PDT
when this vulnerability will be fixed on a stable update?
Comment 41 Mats Palmgren (:mats) 2012-06-23 09:27:55 PDT
Correction: the changesets in comment 39 were for bug 575294.
This is the one for this bug:
https://hg.mozilla.org/mozilla-central/rev/cc89df1b08ae
Comment 42 Alex Keybl [:akeybl] 2012-07-26 16:53:07 PDT
Does this patch rely upon bug 575294 to be resolved? If so, we can wontfix for FF15 (it'll land in FF16 first).
Comment 43 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-02 16:15:38 PDT
Waiting until Mats returns from vacation this coming Monday 8/6 to confirm.
Comment 44 Mats Palmgren (:mats) 2012-08-12 08:42:02 PDT
(In reply to Alex Keybl [:akeybl] from comment #42)
> Does this patch rely upon bug 575294 to be resolved? If so, we can wontfix
> for FF15 (it'll land in FF16 first).

Yeah, I don't think we should take this patch without bug 575294.
It's unclear how well this patch alone would work and this code
is rather error prone, so I wouldn't want to bake this on beta.
Comment 45 Lukas Blakk [:lsblakk] use ?needinfo 2012-08-16 16:23:54 PDT
Thanks Mats, we'll wontfix this for Beta then and please nominate for esr10 landing which we can approve after merge/esr10.0.7 release.
Comment 46 Jordi Chancel 2012-09-11 07:11:07 PDT
Firefox 15.0.1 don't fixe this vulnerability. 

I have reported a critical way of this vuln last year ...

PLEASE UPDATE to Fix this vulnerability ... it's too long...
Comment 47 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-09-11 07:29:57 PDT
As mentioned in the status flags in this bug and in bug 575294, these bugs are fixed in Firefox 16.
Comment 48 Alex Keybl [:akeybl] 2012-09-27 09:49:04 PDT
Similar to bug 575294, Mats and Release Management have agreed that we can wontfix for ESR based upon the risk profile here and instead get it fixed in the first ESR17 release.
Comment 49 Daniel Holbert [:dholbert] 2015-07-22 12:58:39 PDT
Does this bug still need to be hidden?

I'm guessing the reason we didn't un-hide it long ago is that this was a cross-browser issue (as noted in whiteboard field). But I'd hope the other affected browsers have shipped fixes now.
Comment 50 Daniel Holbert [:dholbert] 2015-07-22 13:02:51 PDT
(and if we can un-hide this bug, then we can probably un-hide the dupe [bug 729475] as well.)
Comment 51 Jordi Chancel 2015-07-22 14:04:23 PDT
no it's a bad idea, 
don't un-hide this bug please because others very similare vulnerabilities bugs are unpatched like bug 884488 ; bug 941482 ; bug 952951 (and others).

so please let this bug private until other similare bug are patched .

Thanks.

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