Malicious SWF copying data to computer clipboards... the discussions continue

For those of you interested, there has been a test page set up at this URL - the test page uses an SWF file to copy a URL to a computer's clipboard.  You'll need to close the browser window to regain control of your clipboard's contents:
http://raffon.net/research/flash/cb/test.html

 

I should point out that I am seeing some misinformation out there about what can be done to avoid the problem.  For example, there is this comment by somebody at The Register - he says "Why not just tell IE not to allow access to the clipboard - it's just a tickbox.  I do it on any IE setup since browsers and webpages have no right to my clipboard.  Mine's the one with 'SMUG' pasted on the back"

image

 

The option that Adrian refers to is this one - "Allow Programmatic clipboard access" (note, in earlier versions of IE the option was described as "Allow paste operation via script").

 image

As you can see, my system is set to "prompt".  When I access the above test URL content is silently copied to my clipboard, and this is to be expected.  Why?  The option highlighted is to prevent web pages from accessing (reading) clipboard content.  In other words, it is to stop web pages from COPYING information from the clipboard.  It does not stop data from being written to the clipboard

If the highlighted option is set to "prompt" then you will see this dialogue box if a web page tries to access the clipboard:

image

I have also seen a suggestion that disabling the clipbook service (known as the clipboard service in older operating systems) will avoid the problem - I suspect that that won't work either.  Firstly, the clipbook service doesn't exist in Vista.  Secondly, I am pretty sure that the service is disabled by default once you install XPSP2 or XPSP3.  Thirdly, clipbook/clipboard is used to view and share clipboard contents. I don't think it is the actual service that creates the ability to copy and paste per se.

To be honest I am not sure if it is possible to disable the clipboard so that IE can't write to it - if anybody knows how, please feel free to leave a comment.   Yes, I am aware that we can run Firefox with NoScript installed and running, and we can use adblockers, and that we can disable scripting and whatnot in IE, but I would prefer it if we could avoid the problem *without* breaking web sites (and I've already stated my opinion on the wholesale blocking of advertising - I am against it).

Comments

# re: Malicious SWF copying data to computer clipboards... the discussions continue

Tuesday, August 19, 2008 5:29 PM by Greg

It isn't IE, it's Flash. Flash has a function that lets applets hijack your clipboard and your printscreen key, with no way for you to disable it. Yet another reason to surf without plugins by default.

# re: Malicious SWF copying data to computer clipboards... the discussions continue

Wednesday, August 20, 2008 2:56 AM by Aviv

The IE security setting is for both copy and paste.

The reason my test still works when the IE security setting is set to prompt or disable is that the demo uses the setClipboard function, "kindly" provided by Adobe Flash.

The continuous clipboard hijack is being done by a simple async loop.

# re: Malicious SWF copying data to computer clipboards... the discussions continue

Tuesday, August 26, 2008 5:28 PM by Mark Odell

> Secondly, I am pretty sure that the service is disabled by default once you install XPSP2 or XPSP3.

<A HREF="www.blackviper.com/.../A>

> I would prefer it if we could avoid the problem *without* breaking web sites

Breaking them, or merely discovering that they don't degrade gracefully and thus revealing their pre-existing brokenness? Past that, would you agree that there are <A HREF="msmvps.com/.../1645576.aspx">some web sites</A> which shouldn't work "right"?

> (and I've already stated my opinion on the wholesale blocking of advertising - I am against it).

Your browser, your rules.

Aviv wrote:

> The IE security setting is for both copy and paste.

Thanks, Aviv, good to know.

> The reason my test still works when the IE security setting is set to prompt or disable is that the demo uses the setClipboard function, "kindly" provided by Adobe Flash.

In other words, Flash doesn't truly run in IE's security context, nor obey the "Allow Programmatic clipboard access" setting.