1000514 - (CVE-2014-1561) Toolkit toolbar dialog customization event spoofing

Status: VERIFIED FIXED

(Toolkit :: Toolbars and Toolbar Customization, defect)

Description

[:Gijs (he/him)]

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

Comment 1

[:Gijs (he/him)]

Attachment: Patch v1.1

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.

Comment 2

[:Gijs (he/him)]

remote:   https://hg.mozilla.org/integration/fx-team/rev/153c60b2b678

Marco, can we add this to this iteration?

Comment 3

[Marco Mucci [:MarcoM]]

Added to Iteration 33.2

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/153c60b2b678

Comment 5

[:Gijs (he/him)]

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

Comment 6

[:Gijs (he/him)]

Attachment: Testcase

This should work to test against seamonkey with the str in comment #0.

Comment 7

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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.

Comment 8

[:Gijs (he/him)]

(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).

Comment 9

[[e-mail]]

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

Comment 10

[:Gijs (he/him)]

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

Comment 11

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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.

Comment 12

[[e-mail]]

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

Comment 13

[:Gijs (he/him)]

(In reply to [e-mail] 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?

Comment 14

[[e-mail]]

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.)

Comment 15

[:Gijs (he/him)]

(In reply to [e-mail] 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 16

[:Gijs (he/him)]

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

Comment 17

[Sylvestre Ledru [:Sylvestre]]

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

Verified, 31 will be an ESR release. Taking it.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ee6dc0c0c2d7
https://hg.mozilla.org/releases/mozilla-beta/rev/068f732a0dc4

Comment 19

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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).

Comment 20

[Robert Kaiser]

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

Comment 21

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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.

Comment 22

[:Gijs (he/him)]

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

Comment 23

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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).