Can Adobe mitigate ‘clipboard hijack’ issue?
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:
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)
[Source: zdnet]
Post a Comment