(new) Adobe Flash Player security hole found, flXHR’s response
What is flXHR doing about it?
So, flXHR, by virtue of being an “open-book” in terms of acting as a pass-through client side proxy to replace native XHR for cross-domain communication, is *particularly* susceptible to this type of vulnerability.
The strategy employed with this new flXHR update is to implement in actionscript an analog of the built-in policy checking code that the Flash Player has, and to apply stricter, more comprehensive checking of such policies to plug the ‘auto-trust’ hole.
On top of the intrinsic policy checking that the Flash Player already does, flXHR’s actionscript code additionally requests the XML of all applicable policies (the master policy and any custom policies loaded), and checks them against not only the SWF domain (as the Flash Player does), but also against the domain of the page that the SWF is executing in.
The additional processing checks *only* occur if the SWF domain and the page domain are different. flXHR is able to grab the content of the policy files in the ’security hole’ case because the Flash Player grants the auto-trust. But flXHR then imposes whatever stricter rules it finds from examining the policies to any abitrary XHR-type communication that the page’s javascript may initiate.
So in all cases, the flXHR checking doesn’t (and couldn’t!) grant *any* additional access rights that the Flash Player would not already have granted. Instead, it imposes stricter regulation and closes down access that Flash Player would normally provide, in the case where it is deemed to be imprudent to allow such unchecked communication.
The code implemented in flXHR was an attempt to duplicate the relevant parts of code-logic as publicly described in Adobe’s security documentation. Because flXHR does not deal with FTP, nor does it deal with Socket-level communication, only a subset (HTTP and HTTPS) of the possible Flash Player communication policies needed to be re-implemented in actionscript.
The code weight cost was significant in relativity to prior versions of flXHR (an additional 6-7k of compressed SWF, ~600 lines of AS), and another 1-2k of Javascript code to manage the complexities that this checking introduces. However, it appears from performance testing benchmark comparisons, the new version of flXHR is in general not noticeably slower because the additional checks do *not* actually require additional server round trips (because the Flash Player already requested the policies first, and cached them), so the only additional time is to parse the XML and check it, which thanks to AS3 is quite fast and efficient.
Another drawback, owing to another limitation of Flash Player (which will hopefully eventually be lifted) is that since AS running in a SWF in a web page cannot access response headers (it can in AIR apps, but not in the browser), the “master policy” type in Adobe’s model which allows for granting permission to custom policies purely by content-type cannot be accomodated. Therefore, flXHR will only examine (custom) policy files if the master policy declares a type of “all”, and will default to assuming “master-only” (or “none”) if “by-content-type” (or “by-filename” for FTP) is encountered. This is an unfortunate but necessary (at this time) restriction on authors using flXHR — they can only allow all custom policies, or none.
With the above exceptions noted, thorough testing has been conducted, and it is my belief that while probably not totally the most efficient AS coding solution, the checks implemented in flXHR represent currently the best way to address this security hole short of Adobe releasing another patch to their plugin.
I look forward to hearing from the community and from Adobe’s engineers on this topic, to see if anyone has any thoughts on the security hole or on flXHR’s answer to it.
You definitely raised an interesting point regarding Flash security. I wouldn’t call this a security hole though, but rather a missing security feature.
It’s always up to developer to develop secure application according to the platform capabilities and limitation. A “good” developer can break the toughest security model in a sec
Comment by guya — August 28, 2008 @ 10:47 am
@guya- I think the reason I chose to use “hole” instead of “gap” or “missing feature” is because of point #2 in the page-1 summary — that the behavior is contrary to Adobe’s own security white paper (bottom of page 28) on the topic.
But yes, I agree wholeheartedly that developers/authors need to be more diligent. That’s why I spent an entire month writing and testing (some fairly complex) code to “plug” the hole in the flXHR project so that flXHR can’t be abused (purposely or inadvertently).
But, clearly, my code is not nearly as efficient as if Adobe would address the hole/feature with their native code. And my code doesn’t do much to help all the other flash .swf assets out there which may be vulnerable to such a thing (although the code I wrote *is* in its own class so it *could* be adapted to other projects somewhat straightforwardly).
I guess that’s mostly what I am hoping will come of all this, so that eventually my code won’t be necessary, and other flash content developers won’t have to worry (as much) about this kind of feature-gap.
Comment by Shade — August 28, 2008 @ 12:56 pm
The problem is your underlying assumption is incorrect. You said:
“The domain of the URL of the hosting HTML page is *not* considered, even though the SWF’s executable code (similar to any remotely loaded Javascript files) will in reality execute in the context of that page.”
However, SWF is executed in the context of the SWF’s origin, not of the surrounding page and does not have access to the surrounding page (unless both SWF and HTML are from the same origin OR you enable cross-domain scripting explicitly with allowScriptAccess=always). So it is not the same as importing JavaScript via the SCRIPT tag.
Comment by LDA — October 9, 2008 @ 3:29 pm
I understand that the SWF logically operates in the originating domain security context. And I understand how SWF differs from JS, in that SWF provides this special ability to self-contain its execution to a remote security context (*unless* that barrier is intentionally taken down by the author).
But physically, the SWF is operating inside of an HTML page on perhaps a different domain, and moreover, may be interacting with the javascript of that page on the different domain (if the author allowed it).
In my opinion, what matters most here is the practical security context, which for flash on a webpage, can look a lot more like a mix between the page’s domain and the SWF domain, than *just* the SWF domain.
I know there are access controls (‘allowscriptaccess’ and ‘allowdomain’) which are generally in place to help prevent (or allow) the swf from stepping out of its security context bounds when on a page from a different domain. However, there are plenty of times when a flash file (like flXHR for instance) must be granted permission to talk with the surrounding page regardless of the domain, to accomplish its tasks or goals.
A stand-alone, totally security-sandboxed flash is fine for say a flash ad, but real interactive RIA type flash often needs to step outside it’s walls from time-to-time, and so authors must sometimes breach this defense.
So, if you have such a flash file, which, internally published *and* through the HTML it’s hosted in, has granted this cross-domain access, then practically speaking, that SWF is now operating in a hybrid security context, a mixture of both the page domain and the originating domain.
It is *this* use case which leads me to assert that both the page domain and the swf-domain would be proper to check in resolving cross-domain policies from a server.
Think about it this way… if Adobe’s flash *did* do as I suggest, in most cases (where the page-domain and swf-domain are the same), the behavior wouldn’t be any different than it is right now. But in the set of cases where a SWF is operating in the hybrid context, the cross-domain policies *would be* more secure than they are now, assuming that only the swf-domain need be considered.
I’m simply suggesting that giving developers the ability to breach the strict originating domain security context (ie, the “AllowDomain” actionscript call) but not having the policy file model also support this hybrid context is where the “hole” comes from. And try as I may, the implementation I put in place to protect flXHR from being exploited while in the hybrid zone is limited in its effectiveness — only a native solution from Adobe would fully plug this hole.
Comment by Shade — October 9, 2008 @ 4:52 pm
[...] was the class added to flXHR.swf in a previous alpha release to address the needs discussed in this blog on security model holes. However, it was discovered through further testing that IP addresses, single-word domains (like [...]
Pingback by Changes and new features in flensed 1.0 | the Fresh! — December 5, 2008 @ 7:32 pm