Flash ActionScripts in Firefox trigger action in Safari & Internet Explorer




13 years ago
13 years ago


(Reporter: g, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:nse], URL)



13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20060111 Firefox/

We discovered that the Flash plug-in in Firefox will send messages to the Flash plug-in in another browser. We have only tested this with both browsers have pages from the same domain open. But, I am worried that this could target .swf files on other domains and represent a security issue.

Reproducible: Always

Steps to Reproduce:
1. Open http://www.dreamworksanimation.com/dwa/opencms/movies/movie_sharktale.html in both Firefox and Safari/Internet Explorer.
2. click on one of the teaser trailers in Firefox

Actual Results:  
The trailer will now play in Safari/Internet Explorer

Expected Results:  
The trailer should only play within the window that it was in.

I have tested this on Mac OS X 10.4 and a friend has tested this on Windows XP and we have had the same results. Please do not make the URL public, because we don't want people to target the website.

Comment 1

13 years ago
I think the Flash equivalent of cookies is shared between browsers too...
It appears to depend on order: whichever one loads the page first will be the one in which the movie plays. Same thing happens if you open two IE windows which has the same implications: does the flash security model depend on the site hosting the page, or on the site hosting the content? If it's the latter this is a huge problem, if the former then everything's cool.
Note that in this case both flash movies on the page have the exact same URL with different parameters (some of which apparently tell it to fetch additional content/movies).

If I copy top.swf to a local server and access the menu version there I cannot cause the movie to play in the first-loaded window. (good)

If I create a local page that loads top.swf from dreamworks.com, then clicking in my local page will start the movie on the dreamworks page. This seems very bad. Since flash has the ability to call scripts in the page, could this be used for cross-site communication and spying? Maybe it's no more a worry than a single site including a 3rd party flash in the first place, but given the proliferation of flash ads I'm not sure people are worrying about that as much as they should.

Can the grandma@macromedia.com cc'd on this bug shed any light on this behavior?
Ever confirmed: true
Whiteboard: [sg:high] macromedia XSS
The embedding page needs to create an embedname_DoFSCommand() function in order for the plugin to be able to call scripts in the page so I guess that would make page authors complicit in any XSS risk.
Whiteboard: [sg:high] macromedia XSS → [sg:investigate] macromedia XSS?

Comment 5

13 years ago
Unfortunately, I am unable to reproduce the problem on either Win or Mac, following these instructions. On Mac I open Safari and Firefox, and on Win I open IE and Firefox. I open the url in each browser, then I select an item in the Play Trailer box in Firefox. The movie always seems to play in Firefox. Have I missed something?
Michelle, you're loading the url in Safari before loading it in Firefox, right?

Perhaps this depends on the version of Flash Player?

Comment 7

13 years ago
I can see the bug now. We will investigate. Thanks for bringing this to our attention.

Comment 8

13 years ago
We investigated this thoroughly, there is not a security risk here.  (But thanks for raising it as a possible issue.)

Here is what is happening.  This app uses Flash's "LocalConnection" class to communicate between the main SWF (the one at the top of the page) and the second one ("Play Trailer").  (In this case, this is actually two instances of the same SWF, but that doesn't actually matter.)

LocalConnection allows any two SWFs on the same machine to communicate with each other.  To use LocalConnection, one Flash app registers itself with a name, which will be global to the machine as long as that app is running.  Then, any other app can send a message to it, using the global name.

In the case of this Shark Tale page, the Flash app in whichever browser loaded first registered itself with a name (let's say "TrailerPlayer"), by calling LocalConnection.connect(connectionName).  Then, when you load a different browser, the new instance of that same Flash app tried to register itself; but its registration failed, because the name was already taken.  The app didn't notice the error (the return code from connect()).

So when the other Flash app on the same page tries to send it a message to play the trailer, with something like LocalConnection.send("TrailerPlayer", "playTrailer") or whatever, the message got sent to the wrong browser.  It's a simple bug in this Shark Tale app -- if this is a big-enough problem to worry about, then the app could use a different mechanism to communicate between the Flash apps.

As to the key question of whether it is a security risk:  It is not.  Because of the potential for abuse, LocalConnection has strict rules about whether two Flash apps are allowed to talk to each other.  To oversimplify, basically they are allowed to talk to each other as long as they are on equal footing -- as long as one doesn't have access to a different part of your system than the other one does (e.g. some apps can only read local files; others can only read/write the network).

LocalConnection has been secured since it was first introduced, which was in Flash Player 6.  The rules about local file security (including for LocalConnection) were added in Flash Player 8.  Here's a reference: http://www.macromedia.com/devnet/flash/articles/fplayer8_security.html
As designed and not a security problem per macromedia (Thanks for getting back to us with the details).
Group: security
Last Resolved: 13 years ago
Resolution: --- → INVALID
Whiteboard: [sg:investigate] macromedia XSS? → [sg:nse]
You need to log in before you can comment on or make changes to this bug.