894736 - (CVE-2013-6672) Under Linux, a script can read clipboard data when PRIMARY selection paste (with middle-click) is used

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Vincent Lefevre]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20130715 Firefox/25.0 (Nightly/Aurora)
Build ID: 20130715100109

Steps to reproduce:

1. Open https://twitter.com/ and log in.
2. Open some other page in a new tab, e.g. https://bugzilla.mozilla.org/
3. From this page, selects some text, e.g. "Bugzilla@Mozilla", and type Ctrl-C to copy the text to the clipboard.
4. Select some other text, e.g. "Main Page".
5. Go back to the Twitter tab and click with the middle button in the "Compose new Tweet..." area.


Actual results:

"Bugzilla@Mozilla" is pasted.


Expected results:

"Main Page" should have been pasted, i.e. the contents of the PRIMARY selection, not the contents of the clipboard.

This is potentially a security problem, as the contents of the clipboard may not be intended to be made public, which can occur due to this bug if the user doesn't take care of what has really been pasted.

If the pasted contents are directly available to the web site (without further action such as clicking on the "Tweet" button), this would be even worse...

Comment 1

[Loic]

(In reply to Vincent Lefevre from comment #0)
> 5. Go back to the Twitter tab and click with the middle button in the
> "Compose new Tweet..." area.

Sorry but on Win 7, middle click on the area to compose a new tweet doesn't paste content, it expands the text area and makes the scrolling icon appear.

Any better STR?

Comment 2

[Vincent Lefevre]

(In reply to Loic from comment #1)
> Sorry but on Win 7, middle click on the area to compose a new tweet doesn't
> paste content, it expands the text area and makes the scrolling icon appear.

Clipboard / selection is OS-specific, in particular the concept of paste-with-middle-click and PRIMARY selection. You can consider this as a Linux/Xorg-only bug, but similar systems might have the same bug (e.g. the Xorg version of Firefox under Mac OS X?).

Note that on the same machine, Chromium doesn't have this problem. So, it is not a system bug.

I can reproduce the problem with Iceweasel (Debian's Firefox) on another machine, but I haven't tried Nightly on this one.

For more information about Clipboard / selection under Xorg:
  http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt

Comment 3

[Loic]

Ok, thanks for the clarification. Just one thing, do you know if the bug is present in old versions of Firefox?

Comment 4

[Vincent Lefevre]

I can't reproduce the problem with Firefox 17.0.7 (French version) on a third Linux machine. It is run remotely; I don't know whether this matters (I think it doesn't as the clipboard was working normally).

Comment 5

[Vincent Lefevre]

And I forgot... the problem occurs with Iceweasel 22 (thus based on Firefox 22) on the first two Linux machines.

Comment 6

[Loic]

(In reply to Vincent Lefevre from comment #4)
> I can't reproduce the problem with Firefox 17.0.7 (French version) on a
> third Linux machine.

Maybe there is a regression since FF17 (or later).

Could you try to use mozregression to find a possible regression range, please.
See http://harthur.github.io/mozregression/ for details.
You can use a dedicated profile to bisect, it's faster.

For the record, FF17 nightlies started in July 2012 (mozregression --good=2012-07-01)

Comment 7

[Vincent Lefevre]

I get:

Last good nightly: 2013-03-11
First bad nightly: 2013-03-12

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eccf45749400&tochange=7433bc4545c9

The cause may be the fix of bug 407983.
  http://hg.mozilla.org/mozilla-central/rev/1cc899b40731
  http://hg.mozilla.org/mozilla-central/rev/b123c8210d41

Comment 8

[Vincent Lefevre]

Note that if I toggle dom.event.clipboardevents.enabled to false, the problem disappears.

Comment 9

[Vincent Lefevre]

Attachment: testcase.html

I've attached a testcase showing the bug, based on the testcase from bug 407983.

Comment 10

[Neil Deakin]

Attachment: pasteonlyglobal

The simpler fix is to disable paste events for the selection clipboard. The more complex fix is to allow them but use the right data. This will involve passing which clipboard to use through to FireClipboardEvent and to the data transfer.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Will track since this is a regression from FF22 and if the simpler fix from comment 10 is possible to uplift to beta with minimal risk (we're entering our second-to-last week of Beta for FF23) we can take that but the larger fix is too late for beta uplift given where we're at.

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Since there's not a lot of dupes or indications this is being hit a lot, I'm revising this and untracking but if a low risk fix is available please nominate for uplift when ready.  It's now too late for FF23.

Comment 13

[Jesse Ruderman]

Uhh, what?  We do not evaluate security holes based on how many dups they get or how often they are hit in non-attack cases.

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

Nor do we take fixes for sec-moderate issues this late in the cycle since we're looking to take as little churn as possible.  It's present in FF22 as well, we didn't fix it there, this can be nominated for uplift when ready but it's not going to be a block to shipping.

Comment 15

[Neil Deakin]

Attachment: pasteonlyglobal

This patch passes the clipboard type through to the data transfer.

Comment 16

[Neil Deakin]

Attachment: pasteonlyglobal

This is the right patch.

Comment 17

[(no longer active)]

Comment on attachment 782573 [details] [diff] [review]
pasteonlyglobal

Review of attachment 782573 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/base/public/nsCopySupport.h
@@ +85,4 @@
>       * If the event is cancelled or an error occurs, false will be returned.
>       */
>      static bool FireClipboardEvent(int32_t aType,
> +                                   int32_t aClipboardType, 

Nit: trailing space!

::: content/events/src/nsDOMDataTransfer.h
@@ +83,5 @@
>    // paste or a drag that was started without using a data transfer. The
>    // latter will occur when an external drag occurs, that is, a drag where the
>    // source is another application, or a drag is started by calling the drag
> +  // service directly. For clipboard operations, aClipboardType indicates
> +  // which clipboard to use, from nsIClipboard.

Please document negative values here as well.

Comment 18

[Justin Lebar (not reading bugmail)]

Backed out for Android bustage, sorry.

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

Comment 19

[Ryan VanderMeulen [:RyanVM]]

And B2G. Logs:
https://tbpl.mozilla.org/php/getParsedLog.php?id=26082538&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=26081212&tree=Mozilla-Inbound

Comment 20

[Neil Deakin]

Pushed a fix for the failures by adjusting the test to check the middlemouse.paste preference. https://hg.mozilla.org/integration/mozilla-inbound/rev/6e2d977529e4

Try log: https://tbpl.mozilla.org/?tree=Try&rev=16a602d09cd3

Comment 21

[Carsten Book [:Tomcat]]

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

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

As mentioned before, we don't need to track this but if the fix is low risk please go ahead with an uplift nomination so we can close up on more channels prior to release.

Comment 23

[Ioana (away)]

Verified as fixed on Firefox 26.0b8 and the 11/27 Nightly and Aurora.

Comment 24

[Daniel Veditz [:dveditz]]

"sec-moderate" seems overstated. A user could accidentally leak private information from the clipboard, but this isn't something a web site could make happen as plausible attack nor could they really know that the data that just showed up was unintentionally copied from the clipboard vs. intentionally.

Comment 25

[Vincent Lefevre]

I disagree. I think that an attack is quite easy in the form of a CAPTCHA. For instance, as a CAPTCHA, a malicious web site could say: enter the word "wligtijwdvifjo" (which could have been generated with Javascript) in the form below. A user could select the word and paste with the middle button (this is what I would obviously do): that's the fastest way to enter the word. At this time, the web site can retrieve the contents of the clipboard. Whether these data are exploitable or not is another matter, but there's still a risk for the user.

Comment 26

[Jesse Ruderman]

fwiw, bug 363132 (a similar problem with ctrl+c) is also marked as sec-low.

Comment 27

[Vincent Lefevre]

Well, bug 363132 is different, because the user does a ctrl-v, which has the effect to paste the clipboard, while this bug here doesn't involve any clipboard operation.

It seems that the problem in bug 363132 is that the user trusts selection made in Firefox. But this can have much more critical issues than reading the clipboard if what the user thinks to paste (in an arbitrary application) is not what is pasted. For instance, if the user pastes the fake selection in a terminal running a shell, the machine can get compromised. See bug 637895.