New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 333094 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit 29 days ago
Closed: Mar 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: Flash allows clipboard theft / manipulation for duration of session after receiving a single paste event

Reported by jor...@jordanmilne.com, Jan 10 2014

Issue description

VULNERABILITY DETAILS

Not sure if this is the correct place to report this, but this affects Flash as shipped with Chrome the most, due to Flash's event handlers not stalling the rest of the browser.

Flash allows you to manipulate (inside click events) as well as read (inside paste events) the clipboard. Flash attempts to curb abuse by ensuring that the event handler was triggered by user action, however an attacker may extend the duration of the event by blocking in the handler.

Additionally, Flash event handlers continue to execute even after the tab has closed. Since you may call `.getData()` and `.setData()` on `generalClipboard` as many times as you want so long as you're in an user-initiated event handler, convincing users to paste something onto your page allows you to steal and selectively manipulate their clipboard for the duration of the session.

Click event handlers are much easier get users to trigger (using a single-pixel flash object that follows the mouse until it receives a click,) but only allow write access to the clipboard.

The only real caveat is that Chrome will ask the user if they want to kill Flash after a few seconds when the user browses to another page with flash embedded.

VERSION
Chrome Version: 33.0.1750.18 dev
Operating System: Ubuntu 13.04
Flash Version: Shockwave Flash 12.0 r0 (12.0.0.41)

REPRODUCTION CASE

`simple_jack.mxml` and `simple_jack.swf` in the attached archive are trivial examples of the issue and alert the current clipboard contents for up to 60 seconds after a paste event. 'Something else' is also appended to the clipboard whenever it's changed.


The files in `persist_jack` demonstrate how an attacker may actually use this exploit. Event bubbling is used to bypass the 60-second time limit for event handlers and the effect persists for up to 2 hours, across tab closes. 

While the tab is open, we exfiltrate clipboard contents by passing them to JavaScript via `ExternalInterface.call()`. When the tab is closed and we can no longer call JavaScript, we abuse the fact that `Socket.write*()` is synchronous and write to a previously opened socket.

We also modify the clipboard as soon as it's changed. We just append "AAAAAAAAH" to it, but we could selectively rewrite things that look like commands and whatnot.

As a side note, doing a context-menu paste under Linux will cause a segfault with this demo, but I don't think it's exploitable.
 
flash-clipboard.tar.gz
99 KB Download
There's really 3 issues at play here:

1) Access to `Clipboard.generalClipboard.getData()` is unrestricted inside a `paste` event handler. I think mimicking Chrome's behaviour in the JS Clipboard API would make sense. If the clipboard contents have changed since the `paste` event was raised, `getData()` should return null / undefined.

2) Access to `Clipboard.generalClipboard.setData()` is unrestricted inside a number of event handlers. This is basically a revival of `http://news.bbc.co.uk/2/hi/technology/7567889.stm` with interaction. I'm not sure of a restriction that would make sense here without breaking content.

3?) ActionScript can execute long after the embedding page has gone away by triggering nested event handlers. In practice this seems to be limited to 2 hours since event handlers are killed after blocking for 60 seconds, and I could only nest handlers to a depth of 140.

Comment 2 by dcheng@chromium.org, Jan 10 2014

Cc: raymes@chromium.org
For #1, it seems like Flash should be using the clipboard sequence number.

Comment 3 by jln@chromium.org, Jan 10 2014

Labels: Cr-Internals-Plugins-Flash Security_Severity-Low OS-Windows
Status: Available

Comment 4 by jln@chromium.org, Jan 10 2014

Labels: OS-Linux OS-MAC Pri-2 Security_Impact-Stable Security_Impact-Beta
Assuming this does impact Beta and Stable (I didn't try).

Comment 5 by raymes@chromium.org, Jan 10 2014

Cc: yzshen@chromium.org ihf@chromium.org
Labels: yzshen
Thanks for the detailed report. 1) makes sense. Can you explain 2) in more detail? Is this a bug or expected behavior.

3) sounds like a separate bug that should also be addressed.

Comment 6 by raymes@chromium.org, Jan 10 2014

Labels: -yzshen
> Assuming this does impact Beta and Stable (I didn't try).

I tested Stable on Linux and Windows, both are affected.

> Can you explain 2) in more detail? Is this a bug or expected behavior.

It's expected behavior, but it should probably be restricted further; I'm just not sure how. Flash allows you to set the contents of the clipboard inside a click event handler, but we can block in the click event for as long as we want without freezing the rest of the page. Combined with point 3, we're able to continually clobber the clipboard until the plugin is killed just by having someone click our page. Like http://zeroclipboard.org/ but malicious. 

The "user-initiated event" precaution doesn't work very well when blocking inside the handlers isn't penalized by the page freezing or a hung script message appearing (as would normally happen when blocking inside JS event handlers.)

By continually placing "echo 'hey there!'\n" in the clipboard, I accidentally got command execution on myself a few times when copying and pasting commands between two terminals. Attached is an example of how `setData()` in a `click` event handler may be abused.

This'd probably affect any other function that checks for user-initiated events ( http://www.adobe.com/devnet/flashplayer/articles/fplayer10_uia_requirements.html ,) but most of those are just annoyances like opening modal dialogs.
copy_clobber.tar.gz
43.4 KB Download

Comment 8 by raymes@chromium.org, Jan 13 2014

Cc: cpu@chromium.org
Owner: anthony....@adobe.com
+anthony.chow
(I'm not sure who else from the Adobe side to notify on this...cpu maybe you know).

Anthony could you look in to this? We can provide a sequence number exposed from pepper but it would be good if someone could fix issues 1) and 3) on the flash side.

Comment 9 by raymes@chromium.org, Jan 13 2014

Cc: jsc...@chromium.org
Cc: smori...@adobe.com anthony....@adobe.com
Owner: jecl...@adobe.com
I'm no longer on the flapper project. Please contact Jeromie or Bob, thanks!

Comment 11 by f...@chromium.org, Jan 13 2014

Labels: Cr-Security-UX

Comment 12 by jecl...@adobe.com, Jan 13 2014

Thanks for the notification.  This is Adobe 3692913.  We'll get it assigned and investigated ASAP.
jeclark: I've posted https://code.google.com/p/chromium/issues/detail?id=333094 to expose a clipboard sequence number in pepper.
Cc: jecl...@adobe.com
Project Member

Comment 15 by bugdroid1@chromium.org, Jan 28 2014

------------------------------------------------------------------------
r247383 | raymes@chromium.org | 2014-01-28T01:45:33.967441Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/proxy/flash_clipboard_resource.cc?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/pepper/pepper_flash_clipboard_message_filter.cc?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/proxy/flash_clipboard_resource.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/thunk/interfaces_ppb_private_flash.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/pepper/pepper_flash_clipboard_message_filter.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/cpp/private/flash_clipboard.cc?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/cpp/private/flash_clipboard.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/c/private/ppb_flash_clipboard.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/native_client/src/untrusted/pnacl_irt_shim/pnacl_shim.c?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/tests/test_flash_clipboard.cc?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/tests/test_flash_clipboard.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/thunk/ppb_flash_clipboard_thunk.cc?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/thunk/ppb_flash_clipboard_api.h?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/api/private/ppb_flash_clipboard.idl?r1=247383&r2=247382&pathrev=247383
   M http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/proxy/ppapi_messages.h?r1=247383&r2=247382&pathrev=247383

Add GetSequenceNumber function to PPB_Flash_Clipboard

This provides access to a sequence number which identifies the clipboard state.

BUG= 333094 

Review URL: https://codereview.chromium.org/136183002
------------------------------------------------------------------------

Comment 16 by kenrb@chromium.org, Jan 29 2014

Is this fixed or does it need further work?
This still needs work by Adobe on the flash side to address the issues mentioned. I've landed a GetSequenceNumber function for the clipboard state so that the plugin can detect when the state changes.

jeclark is there any update on this? Thanks!

Comment 18 by f...@chromium.org, Feb 5 2014

Status: Assigned
jeclark@ - ping?

Comment 19 by jecl...@adobe.com, Feb 5 2014

Sorry, I wrote a response on Friday and left it sitting in an open tab.

The developer working the issue has a local fix.  He's out for a couple days, but his status as of Friday was that he expects to have it checked in and confirmed towards the end of the week.

Comment 20 by jecl...@adobe.com, Feb 8 2014

Xing committed a fix today, we're still verifying.  CLs are 1243958 in Mainline and 1243959 in King.
Labels: -OS-Windows -OS-Linux -OS-MAC OS-All
Did the fix for this ship?

Comment 22 by ihf@chromium.org, Mar 12 2014

Yes, it should be in 12.0.0.77.
Status: Fixed
Project Member

Comment 24 by ClusterFuzz, Mar 12 2014

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 25 by ClusterFuzz, Jun 18 2014

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member

Comment 26 by ClusterFuzz, Feb 2 2016

Labels: -Security_Impact-Beta
Project Member

Comment 27 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 28 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment