quote:

---

Adobe moves to nuke ‘clipboard hijack’ attacks

Adobe has announced plans to modify the next version of its Flash Player to use an “allow/deny” system to mitigate clipboard hijack attacks.

The change will be fitted into the final version of Flash Player 10 to demand user interaction when a Shockwave (.swf) file attempts to set data on a user’s clipboard. It follows news that malicious hackers are using booby-trapped Flash banner ads to hijack clipboards for use in rogue security software attacks.

(See Aviv Raff’s proof-of-concept demo to show how easy it is to use Flash with ActionScript code to persistently load a malicious URL into a target clipboard).

Here’s the skinny on the Flash Player 10 changes:

In Flash Player 9, ActionScript could set data on the system Clipboard at any time. With Flash Player 10 beta, the System.setClipboard() method may be successfully called only through ActionScript that originates from user interaction. This includes actions such as clicking the mouse or using the keyboard. This user interaction requirement also applies to the new ActionScript 3.0 Clipboard.generalClipboard.setData() and Clipboard.generalClipboard.setDataHandler() methods.

This change can potentially affect any SWF file that makes use of the System.setClipboard() method. This change affects SWF files of all versions played in Flash Player 10 beta and later. This change affects all non-application content in Adobe AIR—however, AIR application content itself is unaffected.

Any existing content that sets data on the system Clipboard using the System.setClipboard() method outside of an event triggered by user interaction will need to be updated. Setting the Clipboard will now have to be invoked through a button, keyboard shortcut, or some other event initiated by the user.

Adobe already uses an allow/deny mechanism when a SWF file attempts to access a user’s camera or microphone using the Camera.get() or Microphone.get() methods.

---

quote:

---

In a nutshell, it’s when you visit a malicious website and the attacker is able to take control of the links that your browser visits. The problem affects all of the different browsers except something like lynx. The issue has nothing to do with JavaScript so turning JavaScript off in your browser will not help you. It’s a fundamental flaw with the way your browser works and cannot be fixed with a simple patch. With this exploit, once you’re on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.

---

quote:

---

In response to my story earlier on the cross-browser Clickjacking exploit/threat, I received the following e-mail from Giorgio Maone, creator of the popular Firefox NoScript plug-in:

Hi Ryan,

I’ve seen a lot of speculation and confusion in the comments to your Clickjacking article about NoScript not being able to mitigate [the issue].

I had access to detailed information about how this attack works and I can tell you the following:

1. It’s really scary
2. NoScript in its default configuration can defeat most of the possible attack scenarios (i.e. the most practical, effective and dangerous) — see this comment by Jeremiah Grossman himself.
3. For 100% protection by NoScript, you need to check the "Plugins|Forbid [IFRAME]" option..

Cheers,
Giorgio

I also received private confirmation from a high-level source at an affected vendor about the true severity of this issue. In a nutshell, I was told that it’s indeed “very, freaking scary” and “near impossible” to fix properly.

Tod Beardsley from BreakingPoint has posted a few proof-of-concept exploits with speculation around clickjacking.

---