Bug 894736 (CVE-2013-6672)

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

VERIFIED FIXED in Firefox 26

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: Vincent Lefevre, Assigned: Neil Deakin)

Tracking

({csectype-disclosure, regression, sec-low})

22 Branch
mozilla26
x86_64
Linux
csectype-disclosure, regression, sec-low
Points:
---

Firefox Tracking Flags

(firefox22 wontfix, firefox23- wontfix, firefox24- wontfix, firefox25- wontfix, firefox26- verified, firefox-esr17 unaffected, firefox-esr24 wontfix, b2g18 unaffected)

Details

(Whiteboard: [adv-main26+])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

5 years ago
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

5 years ago
(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?
Flags: needinfo?(vincent-moz)
(Reporter)

Comment 2

5 years ago
(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
Flags: needinfo?(vincent-moz)

Comment 3

5 years ago
Ok, thanks for the clarification. Just one thing, do you know if the bug is present in old versions of Firefox?
(Reporter)

Comment 4

5 years ago
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).
(Reporter)

Comment 5

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

Comment 6

5 years ago
(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)
(Reporter)

Comment 8

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

Updated

5 years ago
Blocks: 407983
Status: UNCONFIRMED → NEW
status-firefox22: --- → affected
tracking-firefox23: --- → ?
tracking-firefox24: --- → ?
tracking-firefox25: --- → ?
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Version: 25 Branch → 22 Branch

Updated

5 years ago
Flags: needinfo?(enndeakin)
(Reporter)

Comment 9

5 years ago
Created attachment 777734 [details]
testcase.html

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

Updated

5 years ago
Summary: middle-click in Twitter pastes the contents of the clipboard instead of the primary selection → Under Linux, a script can read clipboard data when PRIMARY selection paste (with middle-click) is used
(Reporter)

Updated

5 years ago
Attachment #777734 - Attachment mime type: text/plain → text/html
(Assignee)

Comment 10

5 years ago
Created attachment 777769 [details] [diff] [review]
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.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)

Updated

5 years ago
Keywords: csec-disclosure, sec-moderate
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.
status-firefox23: --- → affected
status-firefox24: --- → affected
status-firefox25: --- → affected
tracking-firefox23: ? → +
tracking-firefox24: ? → +
tracking-firefox25: ? → +
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.
status-firefox23: affected → wontfix
tracking-firefox23: + → -
tracking-firefox24: + → -
tracking-firefox25: + → -

Comment 13

5 years ago
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.
status-firefox23: wontfix → affected
tracking-firefox23: - → ?
tracking-firefox24: - → ?
tracking-firefox25: - → ?
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.
status-firefox23: affected → wontfix
tracking-firefox23: ? → -
tracking-firefox24: ? → -
tracking-firefox25: ? → -
(Assignee)

Comment 15

5 years ago
Created attachment 782572 [details] [diff] [review]
pasteonlyglobal

This patch passes the clipboard type through to the data transfer.
Attachment #777769 - Attachment is obsolete: true
Attachment #782572 - Flags: review?(ehsan)
(Assignee)

Comment 16

5 years ago
Created attachment 782573 [details] [diff] [review]
pasteonlyglobal

This is the right patch.
Attachment #782572 - Attachment is obsolete: true
Attachment #782572 - Flags: review?(ehsan)
Attachment #782573 - Flags: review?(ehsan)

Comment 17

5 years ago
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.
Attachment #782573 - Flags: review?(ehsan) → review+
Backed out for Android bustage, sorry.

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

Comment 20

5 years ago
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
https://hg.mozilla.org/mozilla-central/rev/6e2d977529e4
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26

Updated

5 years ago
status-firefox26: --- → fixed
tracking-firefox26: --- → ?
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.
tracking-firefox26: ? → -

Comment 23

5 years ago
Verified as fixed on Firefox 26.0b8 and the 11/27 Nightly and Aurora.
Status: RESOLVED → VERIFIED
status-firefox26: fixed → verified
status-firefox22: affected → wontfix
status-firefox24: affected → wontfix
status-firefox25: affected → wontfix
status-firefox-esr24: --- → wontfix
Whiteboard: [adv-main26+]
Alias: CVE-2013-6672
status-b2g18: --- → unaffected
status-firefox-esr17: --- → unaffected
"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.
Keywords: sec-moderate → sec-low
(Reporter)

Comment 25

4 years ago
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

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

Comment 27

4 years ago
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.
You need to log in before you can comment on or make changes to this bug.