new flash security policies

So… I am not happy with Adobe right now. With the push of Flash Player 9,0,115,0 “moviestar”, which included such awesome features as H.264 and AAC codec support and improvements to fullscreen mode, they kind of ambushed me with some sweeping changes to their security policy.

I’d been running pre-release nightly builds of the player since 9,0,60,x… and had noticed some strange warnings. Mysterious “Socket Security Error #2048” exceptions that were being thrown at random – even though I was serving an appropriate (for the time) crossdomain.xml file, unexplained timeouts attempting to talk to an xml socket server when I was very clearly not attempting to do any such thing, etc… My regularly repeated attempts to find documentation on what the warnings actually meant proved fruitless. I believe that is because the appropriate document was not actually released to the public until 9,0,115,0 was released.

Now, the bit where they improved the format for crossdomain.xml files doesn’t really affect me one way or the other. I approve of the improvements but could really care less in this case. They don’t really affect anything I’m doing.

The part that really chaps my hide is the fact that they’ve completely redone the way that socket security policies are handled. The important parts:

  • A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.
  • HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.

That’s right. Your socket policy data can’t live in the sitewide crossdomain.xml file that Apache serves any more.

Flash Player 9,0,115,0 introduces a concept of socket master policy files, which are served from the fixed TCP port number 843.

Socket policy files may be obtained from the same port as a main connection (the socket connection being made by ActionScript, which is authorized by a socket policy file), or from a different port, separate from the main connection. If you opt to serve a socket policy file from the same port as a main connection, the server listening on that port must understand socket policy file requests (which are indicated by a transmission of from Flash Player), and must respond differently for policy file requests and main connection requests.

  • When a SWF file attempts to make a socket connection, even to its own domain, Flash Player will first attempt to contact port 843 to see if the host is serving a socket master policy file.

So… regardless of whether you’re even using a custom port 843 client, the Flash Player is going to try to hit it. What if your firewall doesn’t allow/route traffic to sub-1024 ports w/o special configuration? What if you don’t have the access to bind to a sub-1024 port and can’t rewrite your other server process to serve the policy data on its port?

  • Socket meta-policies can only be declared in a socket master policy file. The syntax is the same as for declaring a meta-policy in an URL master policy file, using the <site-control> tag. Socket meta-policies cannot be declared in HTTP response headers, as HTTP is not involved.

This implies that you can’t even tell apache to listen to port 843 and serve up the data. You HAVE to either maintain a separate server process specifically for the purpose of serving this policy data, or you have to edit the process that SWF’s are connecting to and make them serve the data..

As of the time of this writing (10 days after moviestar’s release), they have yet to release promised help on how to deploy a solution to these new changes. Granted, the one article they did release explains what needs to be done in high level terms. It was sufficient to help me out. I wrote a server that simply listens on port 843 and spews the required xml. But… I’d have really appreciated specific examples, and I suspect plenty of people would appreciate drop-in solutions to the issue.

A 5-minute skeleton implementation (not recommended for production use by any means) written as a PHP cli script might look something like this:

I’ll try to make my production version of this a bit more suitable for public consumption and release it as soon as I can.

The random #2048 security errors continue, despite having deployed my port 843 policy xml server. Granted, they happen less than before… but they still happen. And even when my policy server isn’t running, the errors aren’t thrown 100% of the time. This just baffles me. If they were consistent, that would be one thing. But when you get a security error 1 time in 20… that’s not security, that’s not even a lame deterrent. It’s just incentive to hammer the same port over and over again until something finally gives.

Now, I admit that I could be wrong here… but I’ve re-re-read the documentation on these policies a few times now, and cannot find any reason for the behaviors I’m seeing.

update

On April 22nd, 2008, I released a much better, much more reliable version of this daemon. Head over there for more details and source code.

16 thoughts on “new flash security policies”

  1. Hi,
    I am also not happy with the way which adobe is handling the backward compatiabilty for the flash player version.

  2. I am curious if you have more information since this was posted. It’s April 13th, 2008. I just encountered an IE7 problem with XML socket connections that isn’t happening on IE 6 or Firefox. I wasn wondering if it was somehow related to this issue…

  3. Thanks a lot, we just ran into this exact problem and couldn’t figure out why, after following adobe’s instructions, it still didn’t work. Your article is the best info on it on the web, that we could find, so great job from you and share the word!

  4. We’ve run into the same problem. It appears that no matter how we structure the policy file that it is always rejected with “invalid syntax” even when we use the example policy they provide (which should be valid but not allow the socket connection). It’s not even 1 in 20 failures it’s 100% failure. What a pain this has become.

  5. Many thanks for the detailed explanation of this issue. I had been ignoring the policy-file-request for a while but was forced to respond to it after the release of r115. Let’s hope adobe keeps things as they are now…

  6. Me again :))

    It seems that whenever the swf does not connect due to problems with the 843 policy server (don’t know why these problems appear), the swf sends, as expected, a policy-file-request. If you correctly respond to this request then the swf reconnects and all is ok.
    I does not work if I stop the 843 policy server, so this is just a failsafe!

  7. Bad point for Adobe! Now I have to configure all my servers, my customers call me every time arrrrfff!!!!!

    I have just a problem with a Java socket server, I receive the “” from the Flash player and I send the cross-domain XML but it fails!!

    Is someone has an example of XML syntax which works ???

    Thanks u so much!

  8. For those who have multiple servers i.e. some web servers on one side and a xml (or not) socket server on another side, the “master policy socket server” ™ has to run on the socket server, not the web servers. This would have been overkill to have to run some crappy socket server on every single web server serving SWF files.
    Shame on Adobe they are not even using “virtual hosts” on the policy server, it is therefore not possible to run separate policies (for separate domains or on shared socket server hosting) from the same master policy server.
    We are back to the problems we had 30 years earlier with FTP and HTTP/1.0 needing an IP for every single domain name. Not to mention how much companies are using secured applications with Flash as a frontend, directly from firewalled and/or secured vpn connections, obviously allowing only connections to port 80.
    What a massive turn on for competitors like Silverlight…

  9. Well damn it i used to be able to play flash games at work and now adobe f-ed this all up. I am not a happy camper and want to play some one please tell me what to do. I hate big brother!

  10. I have created the policy server in .net. Anyone needs the source code can drop me a mail (info@epioneersolutions.com).

    Thanks for this great article.

  11. We got following Error messages…
    only client side (Chat Window)..
    Error: Connection to socket server failed (Flash Security Error).

    how to fix this issue.. please give some extra tips..

    by
    SR

  12. The arrogance!

    Who do Adobe think they are that they can introduce a new protocol on a privileged port into the web?

    This is infuriating. It’s a waste of bandwidth and a waste of time. Adobe Flash isn’t so important to me that I want to invest ANYTHING in learning and supporting their security model, only to have it change on me in the next version and require another 5 hours of reading and implementation!

    I just need low-level sockets in my web applications. When this is natively available in common browsers it’s bye-bye to Adobe and their CS-undergrad-student-project approach to security.

    Hopefully firewall makers will boycott this stupidity.

Leave a Reply

Your email address will not be published. Required fields are marked *