Our always proficient Senior Researcher Mike Bailey has found a way to attack the way that browsers handle Adobe Flash objects.  Anyone familiar with Mike's work knows his technical prowess, and I wanted to jump in at the top to quickly provide some insight in to the impact of this:

This vulnerability allows the same-origin policy of Adobe Flash to be exploited to allow nearly any site that allows user generated content to be attacked. No fix for this vulnerability currently exists.

This is frightening in that 99% of internet users worldwide use Adobe Flash. Almost everyone using the internet is vulnerable to a website that allows content to be updated inappropriately.  That's not hyperbole - it's just fact.

With that said, on to Mike Bailey....

The same-origin policy of Javascript is pretty well-understood at this point: a script can access content only from the same domain as the origin HTML page that executes it. While this policy has not had a great track record, it does work reasonably well. When switching from Javascript to Actionscript, a similar language used to handle interactive content for Flash objects, most developers assume that the policy is the same.

It sort of is.

The basic policy for Actionscript is very close to the Javascript same-origin policy: A Flash object can only access content from the domain it originated from. There are exceptions, which I'll get into another time, but they actually aren't particularly important. This flash behavior is known and documented, but is not particularly well-understood, even within the Web Application Security community. The important difference, of course, is that flash objects are not web pages. A flash object does not need to be injected into a web page to execute- simply loading the content is enough. Let's consider the implications of this policy for a moment: If I can get a Flash object onto your server, I can execute scripts in the context of your domain.

This is a frighteningly Bad Thing. How many web sites allow users to upload files of some sort? How many of those sites serve files back to users from the same domain as the rest of the application? Nearly every one of them is vulnerable.  To be sure, any server that allows unvalidated uploads of contents will let an attacker upload html pages with cross-site scripting or other attacks, but SWF files do not require a .swf extension or special content-type headers to execute. This means that poorly validated image upload features will be vulnerable. Also poorly validated document repositories. Also backup services, filesharing sites, webmail applications, and more.

It gets worse. Uploading a SWF with a .jpg extension, or a forged content-type header will get you a long way, but what if you can upload perfectly valid files with malicious content? Remember GIFAR? The basic premise is this: Overload a GIF file with a JAR archive. Specifically, the ZIP file format can be appended to any binary file and still be valid. The GIF format, in turn, can have any binary file appended to it. The JAR archive, being essentially a ZIP file, can be combined with a GIF image to create a a file that is both a valid image and a perfectly valid JAR archive. While SWF files cannot be appended to other formats, the inverse of the GIFAR exploit works- any file format in the ZIP family can have a SWF file prepended to it. This means that ZIP archives, self-extracting executables, Microsoft Office Open XML documents, XPI files, and, if you want to be ridiculous, even JAR files can all be crafted to contain executable SWFs. Additionally, if you don't care too much about compliance with standards (and what attacker does?), many server-side content validation libraries will also allow malformed PDFs, MP3s, and other media formats, so long as you are careful not to mangle them too much. This content overloading technique has countless variations, but the end result is always the same: no matter how good your validation routines, you simply cannot trust user-supplied content.

The short version of all this, of course, is that if I can convince a server to serve up a file on my behalf, I can use that file to attack the server. To demonstrate, here are screenshots of SWF files uploaded to and executed from cPanel's File Manager:

And from SquirrelMail:

To really get into it, let's look at a much more complex, but equally valid example: Gmail serves attachments from mail.google.com, the same domain that is used to access other webmail functionality. You may already see where I'm going with this, but actually exploiting this is extremely tricky, as there are a lot of hoops to jump through. It required uploading the SWF to my own account, then logging the victim into that account (via CSRF), loading the SWF into the browser, logging them out, and enticing the user to log in while keeping the original page loaded (eg. in another browser tab). Not simple, and that's the simplified version, but it worked beautifully. Here's video:

In fact, the Flash exploit itself still works, though the Gmail team has finally (after nearly 3 years of people attacking it) fixed the login CSRF issue that I used to load the object into the browser (well... sort of). At this point, one can still, theoretically, at least, execute the Flash payload as follows:

• Send payload to a targeted user's email account
• Predict or discover the ID within Gmail of the sent message
• Use that ID to execute the payload out of the user's own inbox.

The problem here lies in predicting the message ID- not a simple task given the volume that Gmail handles. I've played with this approach, and while I suspect it is possible, it would take a better statistician than myself.

Back to the Flash issue: while some attacks may be self-contained, and only need to access the source domain to do their dirty work, this all becomes a lot worse if sensitive data can be handed off to the attacker's server. Of course, this is not too hard. Resources may be requested (but not accessed by the SWF) without bothering with same-domain and crossdomain policies. If the SWF is loaded into a malicious web page, Javascript on that page can communicate with the SWF object, as well as with its origin domain (which is different from thesource of the SWF). The SWF itself can also communicate directly with the attacker's server, assuming his crossdomain.xml policy allows it. Considering that it's his server, that shouldn't be difficult to arrange.

I normally wrap up posts like this with mitigation recommendations, but in this case it's not easy. For users trying to protect themselves, disabling Flash completely is the only way to be sure. But that breaks a lot of valuable stuff on the internet. So, you probably will end up mitigating rather than solving the issue.

The best recommendations we have involve ways to control when you're using Flash and when you're not. If you're a Firefox user, NoScript may save you in most cases, though ironically, mail.google.com is whitelisted by default. For those using Internet Explorer, the Toggle Flash application will let you enable and disable Flash as you feel appropriate.

For website owners, all user-supplied content should be served from a completely separate domain. This is already implemented by Yahoo mail, Hotmail, Wikipedia, and many other major websites, but a huge variety of self-contained web applications do not do so (and if I can, for example, upload a malicious file to "apiwiki.twiitter.com", I can perform cross-subdomain cookie attacks). A partial solution was made possible by Flash 10,0,0,2: SWF files served with a "content-Disposition: attachment" header will not execute when embedded in a web page. If all user-generated content is served with this header (not a bad idea in any case), it may limit your exposure, but this is not a very robust solution.

The ideal fix should involve Adobe implementing a more sensible origin policy for Flash objects. According to Adobe, "unfortunately, there is no easy solution. This issue is very difficult to solve without also breaking existing, legitimate content elsewhere on the web." I don't see a fix coming from them anytime soon, but it should not be difficult to at least deny connections by default- even to the origin server of the object. Requiring a crossdomain.xml rule to explicitly allow these connections would at least save all the administrators whose sites don't use flash, while making sure that those who do are aware of the problem and opting in to the consequences.

--Mike Bailey