Open Bug 363132 Opened 18 years ago Updated 2 years ago

By making Cut/Copy shortcut fail, a site can see your clipboard with little cooperation

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: csectype-spoof, sec-low)

Attachments

(1 file, 1 obsolete file)

a hacky PoC without copy event handler 1.1: now it does not require even paste handler
2.12 KB, text/html
Details 
A malicious site can see what's on your clipboard by:

1. Convincing you to copy & paste within the page.  (This might look something like the attachment in bug 57770.)

2. Preventing Cmd+C from working, perhaps by making the selection fake.

When you press Cmd+V to paste, you end up pasting whatever was in your clipboard *before* you visited the site.

If the malicious site is one associated with an eBay auction, it has a pretty good chance of getting some users' eBay passwords.


Can we do anything about this?  Here are some ideas:

A) Make a failed Cut/Copy shortcut clear the clipboard.  This solution would be the opposite of the second bug I filed, bug 27655 and would create inconstency with platforms.  It might cause dataloss if someone accidentally presses Cmd+C when meaning to press Cmd+V.  This only solves the problem for the keyboard shortcut; context menus will probably reamin spoofable.

B) When a Cut/Copy shortcut fails, show a dialog or dialog-like thing that says "Can't copy - no text selected".  (By "dialog-like thing" I mean one of those things that appears in the middle of the screen and fades away after a second, like the one that appears when you change the volume on a PowerBook, or the one that appears when your search wraps around in TextWrangler.)

C) Bring the Mac behavior of beeping on a failed Cut/Copy shortcut to Windows.  I don't think this beep is very effective -- it's a common sound without an obvious meaning in context, and it doesn't help when sound is off or you're listening to loud music.

D) Automatically clear the clipboard when I paste something into a password field.  Then attacker won't get my eBay password, at least, because it won't be in my clipboard when I go to the site.  But an attacker might get something else juicy from my clipboard.  This could also cause dataloss, e.g. if someone assumes they'll be able to paste a psasword into a Notepad window after using it to log into a web site.
I first mentioned this issue in bug 280959 comment 5.
(In reply to comment #0)

> A) Make a failed Cut/Copy shortcut clear the clipboard.
...
> D) Automatically clear the clipboard when I paste something into a password
> field.

Creating dataloss to prevent what seems like a very unlikely and fairly weak attack vector doesn't strike me as a good idea.

> B) When a Cut/Copy shortcut fails, show a dialog or dialog-like thing that says
> "Can't copy - no text selected".

If every time I accidently screwed up copying something popped up in front of what I was doing I would either a) give up on the browser or b) learn to ignore it very quickly, since 99.999% of the time it would have no security implications.

> C) Bring the Mac behavior of beeping on a failed Cut/Copy shortcut to Windows. 

Under what circumstances does it not already do this? Maybe I'm not understanding what "Preventing Cmd+C from working means"; if it means making the menu not valid, then the menu won't flash and the system will beep when you try to use the shortcut. Are there ways to make a Copy appear to Firefox to happen but not actually do anything to the clipboard?  If so, that sounds like it should be a bug.
>> C) Bring the Mac behavior of beeping on a failed Cut/Copy shortcut to Windows. 
> Under what circumstances does it not already do this?

If you focus an empty textbox and press Cmd+C on Mac, it beeps.  If you do the same on Windows (with Ctrl+C), it doesn't beep.
(In reply to comment #3)
> >> C) Bring the Mac behavior of beeping on a failed Cut/Copy shortcut to Windows. 
> > Under what circumstances does it not already do this?
> 
> If you focus an empty textbox and press Cmd+C on Mac, it beeps.  If you do the
> same on Windows (with Ctrl+C), it doesn't beep.

My apologies; I read that backwards since this is currently in Mac/10.4 and thus showed up in my Mac-specific bug query. It sounds like this should be in All/All.
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
(In reply to comment #0)
> If the malicious site is one associated with an eBay auction, it has a pretty
> good chance of getting some users' eBay passwords.

Why would eBay passwords be on the clipboard?
(In reply to comment #5)

> Why would eBay passwords be on the clipboard?

Bug 360493 comment #242 explains why.
Because when password manager can't store a password (whether because you're using multiple browsers, or the site decided to disallow use of password manager, or you are paranoid about XSS and don't want your browser filling in passwords at all), many users store the passwords elsewhere on their computer and paste them in.
QA Contact: editor
Keywords: csec-spoof, sec-low
See also bug 894736, a similar problem with middle-click paste on Linux.
IMHO the suggested remedies are worse than the potential harm. (Though I agree there is a potential for harm, I think it's quite a far-fetched scenario).

I vote for wontfixing this - unless someone comes up with a very clever and implementable hack to handle it.
I don't think that something specific to the clipboard shortcuts should be done. I mean that overriding other shortcuts can also have annoying and/or security/privacy issues, and that this is the general bug 380637. Perhaps it should be closed as a dup of this bug.
This should not be marked as a dup of bug 380637. First, that bug is a messy metabug with a question mark in its summary. Second, clipboard-shortcut restrictions will be special because of clipboard events (see bug 1052569 comment 21). Third, the browser's own implementation of "Copy" does nothing when the browser believes nothing is selected (see comment 0).
IMHO at this point we should not worry a lot about sites annoying their users - sites that do will die because users will leave, period. ;)

With clipboard events, scripts do not need to do hacks with selections to make a copy fail - all it takes is 

document.addEventListener('copy', function(e){e.preventDefault()})

and no content will be copied / clipboard won't be modified.

If we really want to do something to prevent social engineering attacks tricking people into pasting unexpected content from the clipboard, we need to implement a special "attempted copy did not modify clipboard" mode. Whenever a user has triggered a cut/copy action through the browser UI (or attempted to.. as in doing ctrl-c when there is no selection and the command is disabled), we enter this special mode. If a copy action does update the clipboard, we leave it (including if the clipboard is updated by a script in response to a copy/cut event). While the special mode is enabled, triggering a paste action will cause a prompt showing some of the data on the clipboard:

"Are you sure you want to paste 'eBay pw: cuoxcbt' into a document from example.com?"

I sort of think this is overkill..but I'd like to hear what others think and whether there are other proposals.
(In reply to Hallvord R. M. Steen [:hallvors] from comment #12)
> IMHO at this point we should not worry a lot about sites annoying their
> users - sites that do will die because users will leave, period. ;)

Different users have different habits. A site could make some choice that annoys some of its users and won't die because most users aren't affected. Facebook has not died after all.

> With clipboard events, scripts do not need to do hacks with selections to
> make a copy fail - all it takes is 
> 
> document.addEventListener('copy', function(e){e.preventDefault()})
> 
> and no content will be copied / clipboard won't be modified.

According to the bug summary and comment 0, this bug is about the shortcuts, not the events.

I suppose (and hope) that disabling clipboard events (as already possible[*]) would prevent this hack from working, for instance. But there's still the problem that shortcuts can be overridden because the webmaster thinks that his users generally use the mouse for copy/paste and that some shortcuts may be useful for some specific purpose (in particular if different OS use different shortcuts for copy/paste).

[*] dom.event.clipboardevents.enabled set to false. I do that for privacy reasons, but with some drawbacks (it is no longer possible to paste in Facebook comments).
(In reply to Vincent Lefevre from comment #13)
> (In reply to Hallvord R. M. Steen [:hallvors] from comment #12)
> > IMHO at this point we should not worry a lot about sites annoying their
> > users - sites that do will die because users will leave, period. ;)
> 
> Different users have different habits. A site could make some choice that
> annoys some of its users and won't die because most users aren't affected.
> Facebook has not died after all.

While that is certainly true, it doesn't necessarily follow that we should avoid empowering web developers with new and improved features because some of them might use said features and power to annoy a subset of users ;) The minority can lobby for preferences or (even better IMHO) write extensions  that solve the problem.


> > With clipboard events, scripts do not need to do hacks with selections to
> > make a copy fail - all it takes is 
> > 
> > document.addEventListener('copy', function(e){e.preventDefault()})
> > 
> > and no content will be copied / clipboard won't be modified.
> 
> According to the bug summary and comment 0, this bug is about the shortcuts,
> not the events.

But most users will have the clipboard events enabled.

> I suppose (and hope) that disabling clipboard events (as already
> possible[*]) would prevent this hack from working, for instance.

Not really (given that sites can intercept the key instead). It's a little less solid given the numerous UI methods for copy/paste, but still a possible "attack".

> [*] dom.event.clipboardevents.enabled set to false. I do that for privacy
> reasons, but with some drawbacks (it is no longer possible to paste in
> Facebook comments).

(See bug 1140351 - sounds like you need an extension or a pref that disables keyboard events too..)
(In reply to Hallvord R. M. Steen [:hallvors] from comment #14)
> While that is certainly true, it doesn't necessarily follow that we should
> avoid empowering web developers with new and improved features because some
> of them might use said features and power to annoy a subset of users ;) The
> minority can lobby for preferences or (even better IMHO) write extensions 
> that solve the problem.

I agree that it should be solved by a preference (as already discussed in bug 380637).

> > > With clipboard events, scripts do not need to do hacks with selections to
> > > make a copy fail - all it takes is 
> > > 
> > > document.addEventListener('copy', function(e){e.preventDefault()})
> > > 
> > > and no content will be copied / clipboard won't be modified.
> > 
> > According to the bug summary and comment 0, this bug is about the shortcuts,
> > not the events.
> 
> But most users will have the clipboard events enabled.

We are talking about the users who want to have this clipboard problem solved. And to solve it, it is necessary (but not sufficient) to disable clipboard events, as you noted above.

> > I suppose (and hope) that disabling clipboard events (as already
> > possible[*]) would prevent this hack from working, for instance.
> 
> Not really (given that sites can intercept the key instead).

The issue with the key interception is the purpose of this bug.
Attached file a hacky PoC without copy event handler (obsolete) — 
Note that disabling copy event does not mitigate such attacks. It just mitigate the likely easiest way. However, when the user presses Ctrl+C and no text is actually selected, it also leaves the clipboard untouched. The text selection can be emulated by canvas, CSS or something similar. Of one wants to write a canvas PoC, modifying pdf.js might be an easy way.

I've written a very hacky PoC without using copy event. It has many edge cases, but I don't think that solving these edge cases is important in the PoC. Most of them can obviously be solved.

Before user tries to copy a text, a button is focused, so no copy event is generated at all. The Ctrl+C keypress event is caught in order to simulate copy event through page-internal clipboard, but it is not strictly needed.

It uses two textareas, one of them is hidden. When an user pastes a text in the shown textarea, it uses some hacks to simulate the paste operation in the second textarea (from page-internal clipboard) and swaps these textareas. As a result, the text is pasted in a hidden textarea and user has no idea there is something wrong. (Well, there are some cursor position issues, but it's caused just by my laziness, not by a technical limitation.)

The only proper way to mitigate such attacks from keyboard (i.e. Ctrl+C/Ctrl+V) seems to be forcing original clipboard content loss any time the Ctrl+C is pressed, even outside text inputs. This should be just a little hard to user experience (maybe some annoyance in terminal emulator in webbrowser?).

Note that similar attacks might be done for graphical copy&paste, e.g. through context menu or touch GUI on Android. They probably can't be mitigated on the copy side, but they can be mitigated by providing some feedback when pasting, e.g. quoting the text to be pasted in the menu. This is not a perfect mitigation is some special scenarios, but it should cover most of them.
(In reply to Vít Šesták 'v6ak' from comment #16)
> Created attachment 8616374 [details]
> a hacky PoC without copy event handler

A paste handler is used, so that if dom.event.clipboardevents.enabled is set to false, this doesn't work completely: the original clipboard content is pasted (which is bad), but at least, one can easily notice it. Wouldn't it be possible to make it work without the paste handler by catching Ctrl-V too?
(In reply to Vincent Lefevre from comment #17)
> Wouldn't it be possible to make it work without the paste handler by catching Ctrl-V too?

It probably would. I've also some idea about monitoring textarea content and detecting large changes (those are probably caused by a paste operation and not by typing).

But I did not care, as the essential part of the attack is preventing the copy operation, which is what I focused on.
(In reply to Vincent Lefevre from comment #17)
OK, I've uploaded a new version that does not use even onpaste. It was a rather trivial modification. It now uses just purely keydown/keypress handlers.
Attachment #8616374 - Attachment is obsolete: true
> I agree that it should be solved by a preference (as already discussed in
> bug 380637).

And I respectfully disagree. Too many preferences makes software harder to use, test and debug. If we consider this problem serious enough and can find a solution that works for all, we should implement that solution - adding a pref is a failure to really solve the problem.

(In reply to Vít Šesták 'v6ak' from comment #16)
> The only proper way to mitigate such attacks from keyboard (i.e.
> Ctrl+C/Ctrl+V) seems to be forcing original clipboard content loss any time
> the Ctrl+C is pressed, even outside text inputs.

Data loss. Very annoying. But what do you think of my proposal in comment #12?
Well, when I press Ctrl+C, I usually expect I will lose my previous data from the clipboard. So I don't consider this to be annoying. As I have noted, there are very few exceptions like terminal emulator in webbrowser, where Ctrl+C might have some different meaning, but those will affect very minority of users. Moreover, this minority is much more likely to understand the reason of such security countermeasure.

I originally read the discussion rather quickly and did not notice your comment #12 much.

First, I also don't think there will be many sites doing such attack for the same reason – they can't afford it. However, consider network spoofs on local WiFi or TOR. An adversary might just modify a page that is loaded over plain HTTP. (I understand there are some limitations, but they aren't a blocker.) Moreover, consider visiting some less known pages or Wodpress worms. So, I think that this problem is worth of mitigating.

Second, your countermeasure focuses only on intra-application attacks, not on inter-application attacks. I am not sure if there is some plausible inter-application attack scenario, it would have to be analyzed.

Third, your countermeasure potentially adds some complexity for the user, which is something I'd like to prevent if possible. Before implementing such countermeasure, it should be well understood if such warning it well understood and perceived by users. This is non-trivial. Imagine an user that accidentally presses Ctrl+C and he is annoyed by some warning message later. I would not expect even many IT specialist to understand the purpose of such security question. Which would be a huge problem, as misunderstood annoying security warnings are likely to be the next time accepted without reading.

BTW, the HCI (Human-Computer Interaction) aspect seems to be important in security. If we have security warnings that are misunderstood, we might have theoretically fully secure software, but no users that are able to use it in a secure manner. Do you remember changes in SSL certificate warnings? I hope that there comes from some serious HCI researches.

Moreover, assuming that legitimate scenarios are much more frequent than attacks, such warnings are likely to be shown much more in legitimate scenarios than during attacks even if false-positive rate is low. (This is due to the Bayes' theorem, see https://en.wikipedia.org/wiki/Bayes%27_theorem#Drug_testing for more details.)

From this perspective, I see to be accidental data loss on unwanted Ctrl+C (which is always possible, as you might have some text selected) might be much less bad than a security warning in those cases.
(In reply to Vít Šesták 'v6ak' from comment #21)
> Well, when I press Ctrl+C, I usually expect I will lose my previous data
> from the clipboard. So I don't consider this to be annoying.

Good point, but I relatively often press ctrl-c when I intend to press ctrl-v. I'm slightly annoyed by the Sublime Text feature that copies the entire line by default if there is no selection - unlike other software, a ctrl-c mistake w/o selection does cause me data loss in SublimeText.

> First, I also don't think there will be many sites doing such attack for the
> same reason – they can't afford it.

Yes - also, it's pretty hard to distinguish data that would be useful to a hacker (like my eBay PW) from other random junk and data that might be on the clipboard.

> I think that this problem is worth of mitigating.

I'm undecided, but a good quality mitigation strategy might help ;)

> Second, your countermeasure focuses only on intra-application attacks, not
> on inter-application attacks. I am not sure if there is some plausible
> inter-application attack scenario, it would have to be analyzed.

I'm not entirely sure what you mean by that. Presumably any application or website already know what the user is selecting and copying within the site, there's no need to  do JS/clipboard acrobatics to figure that out.

> Third, your countermeasure potentially adds some complexity for the user,
> which is something I'd like to prevent if possible. Before implementing such
> countermeasure, it should be well understood if such warning it well
> understood and perceived by users. This is non-trivial. Imagine an user that
> accidentally presses Ctrl+C and he is annoyed by some warning message later.

Yes, it's a challenge to make sure the warning is understandable and not over-used. Some "mitigation mitigation strategies" might be:

The warning is only shown if 
  * JS intercepted a copy/cut event, prevented the default action, and wrote nothing to the clipboard AND the clipboard had text content when the event occurred
  * JS intercepted a keydown normally bound to 'copy' AND page has a selection, or a keydown normally bound to 'cut' AND there is a selection in an editable context AND the clipboard had text content when the event occurred
  * JS changed selection from a keydown or keypress bound to copy/cut so that nothing ended up on the keyboard
* Don't show the warning if clipboard contents changed between the user action that could have caused a copy/cut and the paste action.
* Consider showing the warning only once per site

> I would not expect even many IT specialist to understand the purpose of such
> security question.

This is also something I'd disagree with - on the contrary, I think 
"Are you sure you want to paste data 'xxx' into page 'yyy'?"
is a question which is pretty easy to understand. It's not a "warning" in the same class as "insecure connection!" is a warning.

> Moreover, assuming that legitimate scenarios are much more frequent than
> attacks, such warnings are likely to be shown much more in legitimate
> scenarios than during attacks even if false-positive rate is low.

The known unknown question is: How many sites have a legitimate use case for preventing copy/cut and do it in a way that trigger our heuristics? Some (e.g. Google spreadsheets) have legitimate use cases for changing selection on keypresses that trigger copy/cut, but the purpose is data ending up on the clipboard, so these heuristics still work. The real use case is about preventing selections in UI like web pages, and that's handled with 'unselectable' attributes or CSS. I don't see any use case for respectable sites messing with clipboard functionality, so I doubt respectable sites would end up with warnings..

> From this perspective, I see to be accidental data loss on unwanted Ctrl+C
> (which is always possible, as you might have some text selected) might be
> much less bad than a security warning in those cases.

Maybe..
See Also: → 1680892
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: