1515783 - Paste listener should not fire on middle-click; can silently leak clipboard data on routine user actions

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[CoJaBo]

Attachment: Minimal testcase

Reporting this as security bug out of caution, since it can't really be flagged later. The homepage of a very popular website currently uses this in a way that accidentally sends random user clipboard data to their servers, so this could be widely-known by now. A narrower click-jacking version of this as a security issue was already reported (and was declined to be fixed) as Bug 405620. This is not a duplicate, however, as this bug involves apparently nonsensical behavior (translation of any middle-click into a paste event with a new API).

Brief testing shows this doesn't appear to work for files or clipboard content other than text, despite the underlying API having that function; I don't expect there would be a way to paste a file via middle-click.

This impacts Firefox running under Linux. I have not tested other browsers or OSes at this time. It almost certainly does not impact Windows, which generally lacks paste on middle-click.

Disabling either the prefs "dom.event.clipboardevents.enabled" or "middlemouse.paste" has the expected result of preventing this.


Repro steps:

See attached HTML. Basically, middle-click the link (or really, anywhere), and it will insert your current clipboard contents into the page.


Suggested fix:

This event should almost certainly not be firing on a middle-click "paste", especially not for elements that wouldn't normally accept text. This occurrence on a popular website demonstrates that, even if this isn't considered a security risk, websites aren't expecting this functionality; it turns any middle-click event into a paste event, unintuitive behavior which can easily be missed if not testing on Linux.

Note that restricting it to fire only in text-areas would allow this to be intentionally exploited by overlaying a textarea if the user can be convinced to middle-click. This form was reported as Bug 405620, which has some discussion of other issues involved in fixing this for textareas.

I am actually not certain if the ability to paste via a site-controlled button is intended here; this used to be present in various rich editors, tho doesn't seem to work for me today. If such functionality is intended, the clipboard leak could trivially be done via that route instead, even on non-Linux OSes.

I should end this with the note that I became aware of this issue via an exfiltration proxy alert. So this is causing actual sensitive data leaks in real-world environments. It might be worth revisiting the decisions behind some of the default prefs here, as the prior bugs are now many years old, and at least some "unfixable" history leaks have since been fixed.

Comment 1

[:Gijs (he/him)]

(In reply to CoJaBo from comment #0)
> Created attachment 9032800 [details]
> Minimal testcase
> 
> Reporting this as security bug out of caution, since it can't really be
> flagged later. The homepage of a very popular website currently uses this in
> a way that accidentally sends random user clipboard data to their servers,
> so this could be widely-known by now. 

Which "very popular website"? Have you reported it to them?

Comment 2

[CoJaBo]

(In reply to :Gijs (he/him) from comment #1)
> 
> Which "very popular website"? Have you reported it to them?

I have. I'm going to wait for that issue to close first before considering disclosing the site name, in case they do consider this a severe issue on their end, especially as I don't know if this may be made public before they see it (as, from a security standpoint, it's just a new way to exploit an already-reported and WONTFIX'd issue).

Comment 3

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

I think we might want to have UX to weigh in with the re-consideration of overall linux behavior and population.

Comment 5

[:Gijs (he/him)]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3)

I think we might want to have UX to weigh in with the re-consideration of
overall linux behavior and population.

Because just restricting to textarea/input/contenteditable doesn't really work to prevent active attacks (see discussion in bug 405620 referenced from comment #0) I think flipping the default of middlemouse.paste is the only realistic option to fully remedy this.

Note that although comment #0 says it's not in wide use, I can still use middle click to paste in gedit, gnome-terminal, as well as chromium, so doing so would be a significant compat/UX risk. (To be clear, I personally don't care about this and would flip the pref, but I'm aware from reviewing the fix for bug 366945 that changing this functionality to default to off will break a bunch of people's workflows and cause a significant number of complaints, esp. considering other browsers haven't bothered to make changes here.)

(In reply to CoJaBo from comment #0)

A narrower click-jacking version of
this as a security issue was already reported (and was declined to be fixed)
as Bug 405620. This is not a duplicate, however, as this bug involves
apparently nonsensical behavior (translation of any middle-click into a
paste event with a new API).

If we don't want to change the pref's default, we could attempt to align with other browsers and not send the paste event unless we're actually in a textarea/input/contenteditable. That wouldn't defeat an active attacker (for which, again, there is no real solution but to turn off middle-click pasting or clipboard events), but it might fix accidental driveby stuff like what comment #0 is referring to.

I think given this is sec-low we should open it up, so people concerned about this vector can flip the pref themselves, and perhaps we can attract contributors who might be interested in fixing this. Dan, does that sound OK?

Comment 6

[CoJaBo]

As noted in Comment #5, there's 2 main issues to consider-

First is turning off middlemouse.paste by default, which I also do feel is warranted, given the security risk. Documentation should also be updated to mention the security impact of this pref, as it may not be readily obvious. If there is debate on that, it might be worth splitting off another bug (or reopening an appropriate closed one) for that discussion.

And the second is reviewing when the paste listener should actually fire. As of Firefox 65.0.2 (possibly earlier, I only tested the latest version), it no longer fires on middle-clicking hyperlinks, which was the main aspect of this that was breaking sites. The test-case reflects this, with the paste listener now only firing when middle-clicking the area outside the link. The issue is much less severe now, but I still think the paste listener shouldn't be firing on middle-click outside of clearly text-related elements, especially if other browsers don't do that. I haven't actually gotten around to seeing which browsers, if any, have this functionality, but the test-case would be useful if anyone wants to try and report back.

I have no objection to flipping this to public if you feel it's warranted; deciding if there's still more to fix here would require discussion. An alternative route to consider would be to switch off middlemouse.paste to mitigate this before opening it up.

I've reported it to a major site impacted by this, but they don't consider it a site issue; that report has been closed, so presumably they have no objection either.

The site this issue was discovered on is Imgur.com; I see no reason not to note that now, as once this bug is made public, it will be discovered immediately. It also gives a good real-world example of a site that uses the paste listener for core functionality. At present, they've partly resolved the issue anyway as it only impacts the "old" version of the site; the beta (which was never affected, as it better validates pasted input) has been made the default for most users since this issue was filed. The site breakage and most of the risk of accidentally leaking data here has also been resolved by Firefox not firing the paste event on links anymore; it's only present if the user accidentally middle-clicks somewhere else on the page, which does still result in raw clipboard data being sent to the server.

Comment 7

[Daniel Veditz [:dveditz]]

Looks like this was reported again in public as bug 1521396, based on observed imgur behavior https://old.reddit.com/r/firefox/comments/ahwtpq/firefox_allows_sites_to_hijack_middle_clicks_and/

That bug claimed to have been a regression introduced in Firefox 64 from bug 1461708, and apparently fixed in Firefox 65. The regression was fixed, but the bit you note in comment 6 is the original WONFIXED bug 405620 behavior (bug 1521396 comment 13).

This doesn't need to be hidden: it's been rediscovered multiple times and discussed in public elsewhere. We probably should dupe it forward to bug 1521396 where it was patched, though if we wanted to argue we should reconsid the wontfix on bug 405620 we could do it here rather than reopen that ancient bug.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

First is turning off middlemouse.paste by default, which I also do feel is warranted, given the security risk.

I don't think that it's good thing for Linux users because it emulates usual behavior on Linux. (And of course, it's disabled by default on the other platforms.)

but I still think the paste listener shouldn't be firing on middle-click outside of clearly text-related elements, especially if other browsers don't do that.

Unfortunately, the behavior change was necessary for better compatibility with Chrome/Chromium on Linux.

This doesn't need to be hidden: it's been rediscovered multiple times and discussed in public elsewhere.

I agree.

We probably should dupe it forward to bug 1521396 where it was patched, though if we wanted to argue we should reconsid the wontfix on bug 405620 we could do it here rather than reopen that ancient bug.

If we had some ways to avoid the risk, we should do that. But I have no idea. With any small changes, attackers must be able to find the way to listen to "paste" events. For example, creating completely transparent <textarea> or something.