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.
this issue works only if a user disabled the pop-up blocker or allowed pop-ups for this site.
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.
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.
Olli, will this be fixed by your patch in bug 575294?
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 email@example.com 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 firstname.lastname@example.org > with the details encrypted with our key from > http://www.mozilla.org/security/. reported => https://bugzilla.mozilla.org/show_bug.cgi?id=729475
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.
->Core::Widget like bug 575294
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).
Try build (including bug 575294) is green on all platforms. The builds are available for testing here: https://email@example.com/
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.
> 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 !
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.
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.
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
This bug does not have a patch landed on m-c, so clearing the ESR tracking flag for now.
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
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.
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.)
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.