On BNET: Fix your remote like MacGyver
BNET Business Network:
BNET
TechRepublic
ZDNet

August 20th, 2008

Can Adobe mitigate 'clipboard hijack' issue?

Posted by Ryan Naraine @ 11:17 am

Categories: Adobe, Anti Virus, Arbitrary Code Execution, Botnets, Browsers, Data theft, Exploit code, Firefox, Flash, Java, Malware, Phishing, Spam and Phishing, Spyware and Adware, Vulnerability research

Tags: Adobe Systems Inc., Security, Ryan Naraine

Adobe investigating clipboard hijack attackAdobe’s product security incident response team (PSIRT) says it is investigating possible solutions to the clipboard hijack attacks spotted on Flash-based advertisements on high-profile Web sites.

A barebones note on the PSIRT blog simply acknowledges the issue and promised more information after the investigation but, by mentioning “possible solutions,” it is clear that that Adobe is looking for ways to mitigate the threat.

Here’s an interesting bit from the Flash documentation:

  • The System.setClipboard() method allows a SWF file to replace the contents of the clipboard with a plain-text string of characters. This poses no security risk. To protect against the risk posed by passwords and other sensitive data being cut or copied to clipboards, there is no corresponding “getClipboard” (read) method.

[ SEE: Adobe Flash ads launching clipboard hijack attack ]

I’m not entirely sure why a SWF file would need the ability to write to the clipboard but, now that we know it does present a security risk (see harmless clipboard-takeover demo), Adobe might want to nuke that functionality altogether or at least rewrite the documentation to discuss this threat.

Or, the company can put up a roadblock/warning mechanism whenever a Flash file tries to use the System.setClipboard() method.

[ SEE: Adobe: Beware of fake Flash downloads ]

Adobe already does this when a SWF file attempts to access a user’s camera or microphone using the Camera.get() or Microphone.get() methods — via a Privacy dialog box, in which the user can allow or deny access to their camera and microphone:

Can Adobe mitigate ‘clipboard hijack’ issue?

While Adobe works on a fix (they should, at the very least, provide a warning screen!), end users should start looking for mitigations elsewhere.  I’d start with Firefox and NoScript, a combination that blocks this attack by default.

* Image source: annia316’s Flickr photostream (Creative Commons 2.0)

Ryan NaraineRyan Naraine is a journalist and security evangelist at Kaspersky Lab. He manages Threatpost.com, a security news portal. Here is Ryan's full profile and disclosure of his industry affiliations.


Email Ryan Naraine

For daily updates on Ryan's activities, follow him on Twitter.

Subscribe to Zero Day via Email alerts or RSS.

Related Discussions on TechRepublic

Did you know you can take part in these discussions with your ZDNet membership?

  • Talkback
  • Most Recent of 10 Talkback(s)
Not practical??
How impractical is perusing the internet quicker (no unwanted content taking bandwidth) and safer? A mere click of the mouse allows the user to allow each or all elements on the page be loaded. The benefits outweigh the potential inconvenience(?) by far.... (Read the rest)
Posted by: aussiedawg Posted on: 08/22/08 You are currently: a Guest | | Terms of Use
wrong on noscript  larry@... | 08/20/08
Re: wrong on noscript  Giorgio Maone | 08/20/08
noscript for ie?  ridingthewind | 08/20/08
wrong on wrong on noscript  larry@... | 08/21/08
Not practical??  aussiedawg | 08/22/08
RE: Can Adobe mitigate 'clipboard hijack' issue?  Scott Larson | 08/20/08
FlashBlock is not reliable for security  Giorgio Maone | 08/20/08
RE: Can Adobe mitigate 'clipboard hijack' issue?  Scott Larson | 08/20/08
RE: Can Adobe mitigate 'clipboard hijack' issue?  Scott Larson | 08/20/08
A Manual Fix (Firefox Only)  Oorang | 08/20/08

What do you think?

SponsoredWhite Papers, Webcasts, and Downloads

advertisement

Recent Entries

advertisement

Archives

Favorite Links

ZDNet Blogs

White Papers, Webcasts, and Downloads

SmartPlanet

Click Here