Closed Bug 894736 (CVE-2013-6672) Opened 7 years ago Closed 7 years ago

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

Categories

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

22 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla26
Tracking Status
firefox22 --- wontfix
firefox23 - wontfix
firefox24 - wontfix
firefox25 - wontfix
firefox26 - verified
firefox-esr17 --- unaffected
firefox-esr24 --- wontfix
b2g18 --- unaffected

People

(Reporter: vincent-moz, Assigned: enndeakin)

References

Details

(Keywords: csectype-disclosure, regression, sec-low, Whiteboard: [adv-main26+])

Attachments

(2 files, 2 obsolete files)

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...
(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)
(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)
Ok, thanks for the clarification. Just one thing, do you know if the bug is present in old versions of Firefox?
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).
And I forgot... the problem occurs with Iceweasel 22 (thus based on Firefox 22) on the first two Linux machines.
(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)
Note that if I toggle dom.event.clipboardevents.enabled to false, the problem disappears.
Blocks: 407983
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM: Core & HTML
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Version: 25 Branch → 22 Branch
Flags: needinfo?(enndeakin)
Attached file testcase.html
I've attached a testcase showing the bug, based on the testcase from bug 407983.
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
Attachment #777734 - Attachment mime type: text/plain → text/html
Attached patch pasteonlyglobal (obsolete) — Splinter Review
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)
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.
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.
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.
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.
Attached patch pasteonlyglobal (obsolete) — Splinter Review
This patch passes the clipboard type through to the data transfer.
Attachment #777769 - Attachment is obsolete: true
Attachment #782572 - Flags: review?(ehsan)
Attached patch pasteonlyglobalSplinter Review
This is the right patch.
Attachment #782572 - Attachment is obsolete: true
Attachment #782572 - Flags: review?(ehsan)
Attachment #782573 - Flags: review?(ehsan)
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+
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
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
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.
Verified as fixed on Firefox 26.0b8 and the 11/27 Nightly and Aurora.
Status: RESOLVED → VERIFIED
Alias: CVE-2013-6672
"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-moderatesec-low
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.
fwiw, bug 363132 (a similar problem with ctrl+c) is also marked as sec-low.
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.