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
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?
(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
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)
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
Note that if I toggle dom.event.clipboardevents.enabled to false, the problem disappears.
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
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
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.
This patch passes the clipboard type through to the data transfer.
This is the right patch.
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
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
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.
"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.
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.