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

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Jordi Chancel]

Attachment: 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]

this issue works only if a user disabled the pop-up blocker or allowed pop-ups for this site.

Comment 2

[Jordi Chancel]

Attachment: ScreenShot

Comment 3

[Jordi Chancel]

Attachment: TESTCASE 1.1

Comment 4

[Jordi Chancel]

Attachment: ScreenShot 1.1

Comment 5

[Jordi Chancel]

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]

This issue works on Opera 11.61 too!

Comment 7

[Al Billings [:abillings - ex-MoCo]]

Confirming. This is worth investigating.

Comment 8

[Jet Villegas (inactive)]

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 (inactive)]

Olli, will this be fixed by your patch in bug 575294?

Comment 10

[Daniel Veditz [:dveditz]]

Attachment: Bug Bounty non-qual

Comment 11

[Jordi Chancel]

I'm the reporter of this vuln but i can't see the attachment 598409 [details]!

Comment 12

[Jordi Chancel]

confidence reigns!

Comment 13

[Jesse Ruderman]

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]

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 - ex-MoCo]]

(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 [e-mail] with the details encrypted with our key from http://www.mozilla.org/security/.

Comment 16

[Jordi Chancel]

(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 [e-mail]
> with the details encrypted with our key from
> http://www.mozilla.org/security/.

reported => https://bugzilla.mozilla.org/show_bug.cgi?id=729475

Comment 19

[Daniel Veditz [:dveditz]]

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

->Core::Widget like bug 575294

Comment 21

[Mats Palmgren (inactive)]

Attachment: 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 (inactive)]

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/[e-mail]-748972c39205/

Comment 23

[Jordi Chancel]

fixed for me

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

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 (inactive)]

> The code around uses // comments.

OK, I'll change it to // for consistency.

Comment 26

[Jordi Chancel]

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]

like three vulnerability of me into the same update 8D !

Comment 28

[Al Billings [:abillings - ex-MoCo]]

Mats, when do we expect this to land?

Comment 29

[Mats Palmgren (inactive)]

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

Mats let us know this is likely too risky to get into FF13. Marking 14+ for the ESR.

Comment 32

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5ba42170426e

Comment 33

[Phil Ringnalda (:philor)]

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 34

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6bcea3a628d8

Comment 35

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/6bcea3a628d8

Comment 36

[Mats Palmgren (inactive)]

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

This bug does not have a patch landed on m-c, so clearing the ESR tracking flag for now.

Comment 38

[Mats Palmgren (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cc89df1b08ae

Comment 39

[Mats Palmgren (inactive)]

https://hg.mozilla.org/mozilla-central/rev/e3676fde39a8
https://hg.mozilla.org/mozilla-central/rev/23f5c88adb8f
https://hg.mozilla.org/mozilla-central/rev/612ee5c6300d
https://hg.mozilla.org/mozilla-central/rev/b47364c051d2
https://hg.mozilla.org/mozilla-central/rev/b2e5b06b0c24

Comment 40

[Jordi Chancel]

when this vulnerability will be fixed on a stable update?

Comment 41

[Mats Palmgren (inactive)]

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

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]

Waiting until Mats returns from vacation this coming Monday 8/6 to confirm.

Comment 44

[Mats Palmgren (inactive)]

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

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]

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: [e-mail]]]

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

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

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

(and if we can un-hide this bug, then we can probably un-hide the dupe [bug 729475] as well.)

Comment 51

[Jordi Chancel]

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.