the Fresh!

In what should be a wake-up call to all web-dev authors who create (or use) Flash content on their sites, Jens Brynildsen of FlashMagazine writes about how a well-known Flash security hole was just exploited by ads placed on the MSN (Norweigan) site, quite possibly affecting/infecting tens of thousands of their users.

If you haven’t already, PLEASE update to the latest (9.0.124) plugin, right now! Also, help Jens’ article get some love by digg’ing it, please. We’ve got to get the word out!

NOTE: This security bug has been known and exposed for months now, and is *not* the same as the new security hole I found and wrote about last week. That one, unfortunately, remains unaddressed by Adobe so far.

As I mention in the first comment on that digg posting, for quite a while now, libraries like SWFObject and our very own CheckPlayer have exposed Adobe’s “ExpressInstall” functionality, which is a drop-dead simple way for users to be prompted to update their Flash Player plugin automatically, unobtrusively, inline in the browser whenever they visit a site with Flash content (even ads!).

If web authors would realize the importance of keeping users’ systems up to date and secure, and would simply use libraries and features like “ExpressInstall” to update users’ plugins as they visit their site, I think there’d be much less chance that hackers and malicious folks will be able to wide-spread take advantage of such vulnerabilities.

This call is *especially* true for the big, high traffic sites, who have probably the best possible chance of getting updates out to the public. If Yahoo, MSN, YouTube, Flickr, etc would use the “ExpressInstall” feature on their flash content, and specify the latest secure version (such as “9.0.124″), then millions of users would be updated very quickly, and vulnerabilities like this would die very quickly too!

I also think Adobe could do a better job of getting this same call-to-action out, for the general web-dev authoring community. We all have to take responsibility in helping keep the web as safe and secure as it can be for the technologies we use to present content to users.

Security Hole Summary

First, a brief summary of the two main “use case” conclusions of this article regarding the impact of the security hole found:

1. If a page is hosting a SWF from a different domain than the page… In this case, Adobe’s model will *only* check the SWF’s domain for cross-domain policy permission. Since a SWF has to be made publicly available through HTTP/S just like images do, *anyone* can link to your SWF and use it in their page… any server who your SWF can contact would probably want to allow access not just based on where the SWF is coming from, but also from the page context it’s running in, but they cannot control the page-domain access. This is especially true if you as the creator of the SWF had to make the SWF more open/flexible in its capabilities for arbitrary communication (such as flXHR or other RIA communication widgets), because it’s more susceptible to “abuse” by a malicious page and its javascript.

2. The more limited, niche-case is if you want to host a SWF on your server, but do not want that SWF to be able to contact your server… you *cannot* control that, because the flash player will grant “auto-trust” to the SWF to talk to *any* part of your public server’s access points. Ideally, it would seem like most server admins/authors would want to be able to publish a policy on their own server which controlled access by *any* SWF, not just any remote SWF. It seems pretty clumsy and dangerous that a host’er of a SWF cannot control that SWF’s communication back to the same hosting server with a server policy… and moreover, *this* case is actually contradictory to what Adobe’s own whitepaper says (bottom of page 28 of this PDF).

A major update has been released which affects all 3 flensed projects, flensedCore, CheckPlayer, and flXHR. All users are encouraged to upgrade as soon as possible.

Here’s a run-down of the major things to note (more details can be found in the documentation and release-notes for each project):

• Both CheckPlayer and flXHR have been tested thoroughly on a wide spread of browsers and platforms. The pass/fail notes can be found here: flensed Documentation
• A new test-suite tool is available for easy testing of CheckPlayer and flXHR in various browser environments. The tool can be found here: flensed Test Suites
• CheckPlayer now supports two new events, SWF_TIMEOUT and SWF_EI_READY. The timeout is an optional setting that times-out a non-responsive loading request of a SWF asset. The EI-ready is an optional SWF ExternalInterface callback function to check for availability/initialization on the loaded SWF (since the EI takes some time to be ready after a SWF is fully loaded). Both events tie into the DoSWF callback function feature, which allows your code to respond definitively when either of these events occur, and either load a new SWF asset or display other alternative content.
• flXHR now supports the username/password parameters to the open() method call, which if non-empty, will create an ‘Authorization’ header and append it to the request.
• flXHR now has a new feature called ‘instancePooling’. Essentially, this feature is most useful when integrating flXHR with Ajax frameworks (jQuery, Dojo, etc). The feature instructs flXHR to keep references to flXHR instances around, and when new instantiation requests come in, if a suitable idle (already-used) instance is available, to re-use that by sending back its reference, instead of the time/memory penalty of creating a new instance. This should greatly improve the performance of flXHR in a multiple-request environment, especially with JS frameworks.
• Both CheckPlayer and flXHR have undergone some significant polishing in terms of code clean up, proper memory management, robust asset loading, etc.
• Lastly, flXHR has received a major security upgrade. Details of this security change are far too intricate for this post, and will instead be handled in a separate post and in dedicated pages. These writeups are forthcoming very shortly. The short story is that (what we deem as) a security ‘hole’ in Adobe Flash Player’s cross-domain policy model was identified and reported to Adobe, and is pending a response from their engineers.

  But rather than wait for a future plugin update, flXHR’s code has *temporarily* (hopefully!) been augmented with code to attempt to plug the hole in the best way possible. The change in behavior that authors will now see is that the cross-domain policies will be enforced more strictly, in that both the flXHR.swf’s originating domain *and* the URL domain of the HTML page that hosts the flXHR.swf will be checked for cross-domain authorization (before, only the SWF’s domain is checked).

Please update flensedCore (to v0.2), CheckPlayer (to v0.7) and flXHR (to v0.6) as soon as possible to take advantage of the bug fixes, security updates, and new features! Join us in the forums and in our google-group mailing list for more information and answers to any questions you may have!