User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 Similar to recent 307 patch > http://www.mozilla.org/security/announce/2011/mfsa2011-10.html Adobe has suggested the fix would involve browser involvement because they are unable to properly handle the 302 redirection. The related vulnerability was discovered while recommending remediation to the vendor Techsmith in regards to their product Camtasia. Camtasia, like many other flash based platforms allowed for an attacker to specify remote XML configuration files that could lead to remote code execution on any website that utilized their software. Their patch involved altering the main flash file to verify the domain of the SWF and the XML configuration file reside on the same domain. It was discovered this limitation can be bypassed by targeting a page that results in an open 302 redirection and the flash plugin is unable to handle the redirection. This vulnerability requires a SWF that utilizes external configurations and an open redirection to reside on the same application. Reproducible: Always Actual Results: Flash Content spoofing and cross site scripting

Could you list very specifically what the Flash player is loading and what you think we ought to do about it? We have implemented a new API in Firefox 4 which allows plugins to observe the fact that redirects happen for streams. But in general, following redirects is a perfectly normal behavior.

The SWF from the example link utilizes an external XML configuration file that it verifies must exist on the same domain the SWF resides on. If the path given for the XML file is an open redirect, flash player will think the requirements for same domain have been met and be completely blind to redirection to the attacker's domain. The requirements for the attack scenario are unlikely but if successful allows an attacker to elevate open redirection to execute XSS. DomainA => DomainA (DomainB) To prevent this scenario flash player would need additional insight when a 302 redirection has occurred so security restraints can be evaluated according to the end target and not the initial redirection. This will likely be resolved with the API in Firefox 4.

As it stands, this is either INVALID or a dupe of bug 475991. In terms of Firefox security, this bug doesn't need to remain private. Before we make it public, though, please confirm that there this won't negatively affect security for people using the product. You shouldn't allow open redirects in security-sensitive sites in any case.