Closed Bug 1000514 (CVE-2014-1561) Opened 10 years ago Closed 10 years ago

Toolkit toolbar dialog customization event spoofing

Categories

(Toolkit :: Toolbars and Toolbar Customization, defect)

defect
Not set
normal
Points:
2

Tracking

()

VERIFIED FIXED
mozilla33
Iteration:
33.2
Tracking Status
firefox30 --- wontfix
firefox31 + verified
firefox32 + verified
firefox33 --- verified
firefox-esr24 --- wontfix

People

(Reporter: Gijs, Assigned: Gijs)

References

()

Details

(Keywords: sec-low, Whiteboard: [Australis:P4][qa!][adv-main31+])

Attachments

(2 files)

+++ This bug was initially created as a clone of Bug #910375 +++

It is possible to craft a drag and drop event in content which mimics the behavior of a chrome customization event. This attack is very unlikely as it requires the user to have the customizable page / panel open and then drag and drop from another window to the page. The impact is also very low since all an attacker can do is move icons around. The current chrome code only uses the event to pick an icon to move.

Marking this as security sensitive because bug 910375 was also security sensitive.

STR
1. Open the customize toolbar dialog
2. Open above file in another window or visit
https://people.mozilla.com/~dchan/drag.html
3. Drag the Firefox icon to a toolbar

Result
The Subscribe icon moves

Expected
Icon doesn't move
Summary: New PanelUI / toolbar customization event spoofing → Toolkit toolbar dialog customization event spoofing
Attached patch Patch v1.1Splinter Review
This only accepts the customize window and the gToolboxDocument's window. I verified this works in SeaMonkey to defeat the exploit and still allow cross-window drags between the customize window and the window being customized.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #8445154 - Flags: review?(dao)
Attachment #8445154 - Flags: review?(dao) → review+
remote:   https://hg.mozilla.org/integration/fx-team/rev/153c60b2b678

Marco, can we add this to this iteration?
Iteration: --- → 33.2
Points: --- → 2
Flags: needinfo?(mmucci)
Whiteboard: [Australis:P4] → [Australis:P4][fixed-in-fx-team]
Added to Iteration 33.2
QA Whiteboard: [qa+]
Flags: needinfo?(mmucci)
Flags: firefox-backlog+
https://hg.mozilla.org/mozilla-central/rev/153c60b2b678
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Marco, can you ensure this is on QA's radar? Probably easiest to test with either Thunderbird or SeaMonkey. I'll attach an updated test case in a bit because the existing one relies on a feed-button, which neither has...
Flags: needinfo?(mmucci)
Whiteboard: [Australis:P4][fixed-in-fx-team] → [Australis:P4][qa+]
Attached file Testcase
This should work to test against seamonkey with the str in comment #0.
I was able to reproduce the issue with SeaMonkey Nightly and Aurora builds, using the testcase from comment 6 and steps to reproduce from comment 0. However there don't seem to be any more Nightly builds for Seamonkey since June 19 (I searched for them at ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/). Am I not searching in the right place, or is there a reason for no new Nightly builds in one week?

Note: would verifying this on SeaMonkey be enough to mark the bug verified? The bug has the "status-firefox33: fixed" flag, but I cannot reproduce the problem with Firefox.
Flags: needinfo?(mmucci)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #7)
> I was able to reproduce the issue with SeaMonkey Nightly and Aurora builds,
> using the testcase from comment 6 and steps to reproduce from comment 0.
> However there don't seem to be any more Nightly builds for Seamonkey since
> June 19 (I searched for them at
> ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/). Am I not
> searching in the right place, or is there a reason for no new Nightly builds
> in one week?

I think that is the right place, and I think the reason is that SeaMonkey builds are pretty busted up right now, for various reasons. It took me the best part of a day to get it to build and work on this bug. Neil, do you know if there's an ETA for when there'll be nightlies again?

> Note: would verifying this on SeaMonkey be enough to mark the bug verified?
> The bug has the "status-firefox33: fixed" flag, but I cannot reproduce the
> problem with Firefox.

I'm not aware of any way to reproduce with Firefox directly, but the code lives in toolkit, and we ship it, so that's the flag that would need to be updated (especially as there is no alternative flag).
Flags: needinfo?(neil)
(In reply to Gijs Kruitbosch from comment #8)
> (In reply to Florin Mezei from comment #7)
> > However there don't seem to be any more Nightly builds for Seamonkey since
> > June 19 (I searched for them at
> > ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/). Am I not
> > searching in the right place, or is there a reason for no new Nightly builds
> > in one week?
> 
> I think that is the right place, and I think the reason is that SeaMonkey
> builds are pretty busted up right now, for various reasons. It took me the
> best part of a day to get it to build and work on this bug. Neil, do you
> know if there's an ETA for when there'll be nightlies again?

I think 1027241 is our major stumbling block right now, and it has a patch, but I can't predict how long it will take for it to land.
Flags: needinfo?(neil)
QA Contact: kamiljoz
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #7)
> I was able to reproduce the issue with SeaMonkey Nightly and Aurora builds,
> using the testcase from comment 6 and steps to reproduce from comment 0.
> However there don't seem to be any more Nightly builds for Seamonkey since
> June 19 (I searched for them at
> ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/). Am I not
> searching in the right place, or is there a reason for no new Nightly builds
> in one week?
> 
> Note: would verifying this on SeaMonkey be enough to mark the bug verified?
> The bug has the "status-firefox33: fixed" flag, but I cannot reproduce the
> problem with Firefox.

A mac nightly was produced today: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2014-06-30-00-30-01-comm-central-trunk/ (sadly it seems win32 and linux nightly generation is still broken - but it should be possible to verify this on mac and the problem isn't OS-specific, so that should be OK)
Flags: needinfo?(florin.mezei)
Thanks for the heads up Gijs. I've verified this today on Mac OS X 10.9.3 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30a1). The issue reproduces with SeaMonkey Nightly build from June 19th (BuildID: 20140619003001). The issue no longer reproduces with SeaMonkey Nightly build from June 30th (BuildID: 20140630003001), as the icon from the testcase can no longer be moved to any toolbar, while cross-window drags between the customize window and the window being customized work fine.

Marking as Verified based on comment 10.
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
Flags: needinfo?(florin.mezei)
Whiteboard: [Australis:P4][qa+] → [Australis:P4][qa!]
(In reply to Florin Mezei from comment #11)
> cross-window drags between the customize window and the
> window being customized work fine.

I hate to be a party pooper, but while the lack of drag from content is obviously good news, the OSX customise window uses a sheet, not a separate window.
(In reply to neil@parkwaycc.co.uk from comment #12)
> (In reply to Florin Mezei from comment #11)
> > cross-window drags between the customize window and the
> > window being customized work fine.
> 
> I hate to be a party pooper, but while the lack of drag from content is
> obviously good news, the OSX customise window uses a sheet, not a separate
> window.

Neil, with the situation for Linux and Windows builds being what it is, do you think you'd be able to provide a build for either of those to test with?
Flags: needinfo?(neil)
I asked around and KaiRo said he had a local Linux self-build so I asked him to test toolbar customisation on it and he said it seemed to work properly. (I didn't ask him to try the test case assuming that testing on OSX sufficed.)
Flags: needinfo?(neil)
(In reply to neil@parkwaycc.co.uk from comment #14)
> I asked around and KaiRo said he had a local Linux self-build so I asked him
> to test toolbar customisation on it and he said it seemed to work properly.
> (I didn't ask him to try the test case assuming that testing on OSX
> sufficed.)

\o/

Thanks!
Comment on attachment 8445154 [details] [diff] [review]
Patch v1.1

Approval Request Comment
[Feature/regressing bug #]: n/a
[User impact if declined]: sec-low vulnerability in toolkit apps on branches/esr
[Describe test coverage new/current, TBPL]: none, none, had manual testing
[Risks and why]: low, manual testing revealed no issues, have employed a similar patch for Firefox for a long time.
[String/UUID change made/needed]: none
Attachment #8445154 - Flags: approval-mozilla-beta?
Attachment #8445154 - Flags: approval-mozilla-aurora?
Comment on attachment 8445154 [details] [diff] [review]
Patch v1.1

Verified, 31 will be an ESR release. Taking it.
Attachment #8445154 - Flags: approval-mozilla-beta?
Attachment #8445154 - Flags: approval-mozilla-beta+
Attachment #8445154 - Flags: approval-mozilla-aurora?
Attachment #8445154 - Flags: approval-mozilla-aurora+
Setting back [qa+] for verification in Aurora and Beta. I'm not sure though about build availability for testing this on Beta (Aurora should have Windows builds available judging by the latest versions).
QA Whiteboard: [qa!] → [qa+]
Whiteboard: [Australis:P4][qa!] → [Australis:P4][qa+]
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #19)
> Setting back [qa+] for verification in Aurora and Beta. I'm not sure though
> about build availability for testing this on Beta (Aurora should have
> Windows builds available judging by the latest versions).

There are some issues with the SeaMonkey build machines, from what the team tells me, but IIRC, Aurora and Beta should have Windows building fine with the current machines.
Verified as fixed on Windows 7 x64, using SeaMonkey 2.29a2 Aurora build from July 2nd (BuildID: 20140702013001), as the icon from the testcase can no longer be moved to any toolbar, while cross-window drags between the customize window and the window being customized work fine.

I could not find any SeaMonkey 2.28 Beta builds yet... I'll keep an eye out for them so I can also verify this on Beta.
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #21)
> Verified as fixed on Windows 7 x64, using SeaMonkey 2.29a2 Aurora build from
> July 2nd (BuildID: 20140702013001), as the icon from the testcase can no
> longer be moved to any toolbar, while cross-window drags between the
> customize window and the window being customized work fine.
> 
> I could not find any SeaMonkey 2.28 Beta builds yet... I'll keep an eye out
> for them so I can also verify this on Beta.

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-beta-win32/1404258121/

(I don't know why there are neither nightlies nor betas listed in the right directories on the ftp server, but this build is from today, so I would expect it to have the required changes)
Thanks Gijs, the fix looks fine on this SeaMonkey 2.28 Beta build (BuildID: 20140701164201), on Windows 7 x64 (User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 SeaMonkey/2.28).
QA Whiteboard: [qa+] → [qa!]
Whiteboard: [Australis:P4][qa+] → [Australis:P4][qa!]
Depends on: 1033568
See Also: → 1033568
See Also: 1033568
Whiteboard: [Australis:P4][qa!] → [Australis:P4][qa!][adv-main31+]
Alias: CVE-2014-1561
Group: core-security
You need to log in before you can comment on or make changes to this bug.