(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

RESOLVED FIXED in Firefox 16

Status

()

defect
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: jordi.chancel, Assigned: mats)

Tracking

({sec-critical})

10 Branch
mozilla16
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox12+ wontfix, firefox13+ wontfix, firefox14+ wontfix, firefox15+ wontfix, firefox16+ fixed, firefox-esr10- wontfix)

Details

(Whiteboard: [sg:critical][advisory-tracking+] cross-browser issue (Chrome, Opera), )

Attachments

(3 attachments, 2 obsolete attachments)

39.21 KB, application/java-archive
Details
167.99 KB, image/png
Details
fix
5.08 KB, patch
smaug
: review+
Details | Diff | Splinter Review
Posted file TESTCASE.ZIP (obsolete) —
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.
this issue works only if a user disabled the pop-up blocker or allowed pop-ups for this site.
Posted image ScreenShot (obsolete) —
Attachment #596280 - Attachment is obsolete: true
Attachment #596272 - Attachment is obsolete: true
Posted file TESTCASE 1.1
Posted image ScreenShot 1.1
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.
This issue works on Opera 11.61 too!
Confirming. This is worth investigating.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: CVE-2012-3984
Whiteboard: [sg:high]
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.
Assignee: nobody → matspal
Status: NEW → ASSIGNED
Olli, will this be fixed by your patch in bug 575294?
I'm the reporter of this vuln but i can't see the attachment 598409 [details]!
confidence reigns!
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
I've found a new way for allow this clickjacking/spoofing attack with document.location (so without window.open).

Can i report this?
(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/.
(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
Duplicate of this bug: 729475
Attachment #596294 - Attachment mime type: application/octet-stream → application/java-archive
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.
Whiteboard: [sg:high] → [sg:critical]
->Core::Widget like bug 575294
Assignee: matspal → nobody
Component: Untriaged → Widget
Product: Firefox → Core
QA Contact: untriaged → general
Assignee: nobody → matspal
Component: Widget → Layout: Form Controls
OS: Windows 7 → All
QA Contact: general → layout.form-controls
Hardware: x86_64 → All
Posted patch fixSplinter Review
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).
Attachment #612672 - Flags: review?(bugs)
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/
fixed for me
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.
Attachment #612672 - Flags: review?(bugs) → review+
> The code around uses // comments.

OK, I'll change it to // for consistency.
It will be fabulous if This bug will be fixed with other of my bug like Bug 687745 and Bug 700080! :)
like three vulnerability of me into the same update 8D !
Whiteboard: [sg:critical] → [sg:critical] cross-browser issue (Chrome, Opera)
Mats, when do we expect this to land?
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.
No longer depends on: CVE-2012-3984
Depends on: CVE-2012-3984
Mats let us know this is likely too risky to get into FF13. Marking 14+ for the ESR.
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.
https://hg.mozilla.org/mozilla-central/rev/6bcea3a628d8
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Blocks: 314939
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This bug does not have a patch landed on m-c, so clearing the ESR tracking flag for now.
https://hg.mozilla.org/integration/mozilla-inbound/rev/cc89df1b08ae
Target Milestone: mozilla15 → mozilla16
when this vulnerability will be fixed on a stable update?
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
Does this patch rely upon bug 575294 to be resolved? If so, we can wontfix for FF15 (it'll land in FF16 first).
Waiting until Mats returns from vacation this coming Monday 8/6 to confirm.
(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.
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.
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...
As mentioned in the status flags in this bug and in bug 575294, these bugs are fixed in Firefox 16.
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.
Whiteboard: [sg:critical] cross-browser issue (Chrome, Opera) → [sg:critical][advisory-tracking+] cross-browser issue (Chrome, Opera)
Summary: 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 active <select> dropdown menu can be used for Spoofing And ClickJacking with XPI using window.open and geolocalisation
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.
(and if we can un-hide this bug, then we can probably un-hide the dupe [bug 729475] as well.)
Flags: needinfo?(dveditz)
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.
Flags: needinfo?(dholbert)
Flags: needinfo?(dveditz)
Flags: needinfo?(dholbert)
Group: core-security
You need to log in before you can comment on or make changes to this bug.