Peleus here. Research was recently published that makes several claims regarding Flash content on sites that allow end-user uploads that I would like to address. The topic raised is not news; it's something that has been understood and discussed by the security community for years. Most importantly, this is not a vulnerability in Adobe Flash Player. Web servers that choose to accept user-uploaded content also choose to accept the risks that go along with that functionality. Flash Player's behavior is consistent with other web technologies and the web browser security model. Several web technologies pose the same risk to servers that allow end-user uploads.
To really understand the issue, we need to take a step back and understand the same-origin policy. This policy basically states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other. Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact. The same-origin policy is enforced by the web browser, and all web content must follow it.
The researchers noticed that there are many web applications that allow end-users to upload their own content to the same domain as the web application itself. According to the same-origin policy, this means that the web application trusts the end-user's content in the same way that it trusts its own content. In most real world scenarios, this is not true. The web application does not trust end-user content and does not mean to grant end-user content any privileges on its domain. Quoting Law #4 of Microsoft's 10 Immutable Laws of Security, "If you allow a bad guy to upload programs to your web site, it's not your web site anymore." Microsoft originally published these laws in 2000 and TechNet Magazine revisited them in 2008 where they concluded, "Law 4, at least in spirit, still holds--in spite of some sites that are designed to permit people, bad and good, to upload programs to them."
When Flash content (SWF), as well as any other web content, is hosted on the same domain as the surrounding HTML, the same-origin policy defines a trust relationship between the two. Proposals have been made to have Flash content assume there is never any trust and therefore ask permission for each and every request that it makes. This would break all legitimate deployments of Flash content on the web and require all administrators to change their configurations in order to start supporting Flash again. It also would not solve the problem. Flash content is not the only content-type that can execute JavaScript when clicked on by a user. Law #4 still holds. The fundamental problem is that the site is not properly handling the upload of arbitrary active content. Attackers can still attempt to upload other forms of server-side or client-side code in an effort to exploit the server.
The web has already widely deployed much better solutions. Sites solve the problem by hosting untrusted content on a different domain. If a site developer wants to host arbitrary uploaded content on a site and does not want SWF content to execute on their site, the SWF can be served with headers, which instruct Flash Player to treat the file as an attachment. Flash Player will acknowledge that request and present an Open/Save/Cancel dialogue to the user rather than render the content. Developers may also choose to limit uploads to only the types of content that they plan to support. These steps to properly managing user-generated active content uploads may be challenging, but good web security requires vigilance against this type of risk alongside all the other familiar web threats like CSS, CSRF, ...
We understand that developers have many challenges when managing rich content, and we are working with the industry in discussing and supporting solutions (such as Content-Security Policies) to minimize the risks and educate the community. Our goal is to enable all of our customers (end-users, developers, and web site owners) with solutions that will protect them from the critical risks they face.