You have a malformed url for linking to the second screenshot.

The uses of Flash videos is ironic. I am one of the 1% who does not use flash.

In Firefox, I'd recommend combining NoScript with the FlashBlock extension:

https://addons.mozilla.org/en-US/firefox/addon/433

Since NoScript doesn't allow fine-grained control of whitelisting separately for scripts and flash, this gives you a second layer of control; you can safely enable scripts on gmail without having to worry that any flash will break through.

Let me be the first to say, "Oh. Crap."

If this isn't already being exploited, it will be soon. Thanks a bunch, Adobe! And a double "thank you" for telling us you don't care and won't fix it. Guess who's turning off Flash right now, and for the foreseeable future?

Seems like this attack could be mitigated easily by serving untrusted content (uploads, etc.) from a separate, un-cookied hostname. If a malicious flash binary was served from, say, mail-attachments.google.com, the exploit would execute in the context of a sandbox with no access to other parts of the app.

Advertisement are likely to be untrusted content.
the coverage of flash, made flash based advertising possible, and there was also a vulnerability that was also exploited via ads.

Antonio: that's a good point, but it misses part of the solution. It's not a different HOST that the content needs to be served from - it's a different DOMAIN.

You see this in some sites that do a good job - Facebook, for example, puts its user-uploaded photos on sites like http://photos-a.ak.fbcdn.net. This is most-often done for performance and architecture reasons, but it has the added benefit of being the way to stop this attack.

So, in your example, the solution wouldn't be mail-attachments.google.com, but goog-attach.com, or the like.

-Mike

"if I can convince a server to serve up a file on my behalf, I can use that file to attack the server."

I am slow, but how is that attacking the server? Sure you can use it to host the file, but attacking the server?

Mike: that was true in Flash 6 and earlier, but according to the docs, Flash 7 and later relies on exact hostname matching.

"Version 7. Superdomain matching is changed to exact domain matching. Two files are permitted to script each other only if the host names in their URLs are identical; otherwise, a call to System.security.allowDomain() is required."

Source: http://livedocs.adobe.com/flas...02104.html

Thanks for the reminder.

This issue is not new at all. This has been around for a few years. I remember doing this to myspace profiles just for fun. It still works btw.

The bottom line is, if you allow "flash" (.swf and such) then the exploit will always work. Client/server side are both affected.

AFAIK, the only way to defeat this is to disable flash. NoScript and firefox flash blocker is the fix. Use common sense when browsing around flash sites.

I'll take your word for that, Antonio - Mike Bailey is the true expert on this particular set of issues. I'm doing my best to learn on the fly. :-)

It would be interesting to see if the Gnash plugin also has the same vulnerability. At least if it does turn up to be an issue, the Gnash people would probably be more willing to fix it.

"SWF files do not require a .swf extension or special content-type headers to execute".

I don't buy that. Your cPanel screenshot sure makes it look like cPanel recognizes that it's serving a SWF; I fully expect that cPanel sent an appropriate Content-Type response header. This is important. Historically Firefox/Mozilla will respect the Content-Type response header; announce a binary as the wrong type and Firefox will choke on it. In this case, that means I expect Firefox will protect users. Most cautious web site operators will not serve user-supplied content that has XSS implications, e.g. won't display raw HTML attachments as text/html, but would *at least* use application/octet-stream content type and disposition attributes to prevent the client from thinking the page should be rendered as having come from the server.

Internet Explorer, on the other hand, has tended to play fast-and-loose with Content-Type response headers, sometimes inspecting the response body and deciding what type of file it is, basically ignoring the server's response headers. I can easily imagine IE users being vulnerable.

Why don't you post a demo exploit? Make a site that offers links to a demo SWF with different file extensions (yes, sometimes IE would pay attention to the "file extension" in a URL). Upload some demos of the hybrid file types you describe. Test the links with different browsers. As I said, I am really skeptical of your apparent claim that Firefox would invoke the Flash plugin to execute a SWF even if the URL were http://example.com/test.txt and the server announced the SWF as content-type text/plain.

It's a shame the major browser developers couldn't agree on a codec for HTML5 video. If it weren't for Flash video, the number of people exposed to this risk would be greatly reduced.

And have you ever looked at your cpu usage stats while watching Flash video compared to literally *anything* else? It's horrendous. Gluttonous, really.

So, I'm guessing you released this because that other app scripter posted his experience with both Myspace/Facebook directly in his crossdomain.xml experience and your research expanded upon that.

Wiz,

> Use common sense when browsing around flash sites.

Unfortunately, this is not feasible. Have you ever noticed how many site use flash for advertisements?

Antonio: You are correct that exact name matching limits the scope of a flash vulnerability, but the research I posted last week on cross-subdomain cookie attacks pretty much destroys any faith I had in the ability of subdomains to keep things separate.

It's worth noting that most of those attacks work perfectly fine using Actionscript instead of Javascript. Additionally, Actionscript can execute javascript using ExternalInterface.

Peter: The cPanel screenshot is indeed executing the file directly. In that case, a .swf file was uploaded through another upload script, and no other magic was necessary.

In the gmail exploit, however, the payload was uploaded as a .jpg image, served up with image/jpg headers, and loaded into an tag on my attacking server. The browser decides which plugin to load the embedded file with based on the content-type attribute of the embed tag. The Flash plugin, in turn, does not validate the MIME type of the file- if it looks like a flash format, it will try to execute it. This is the basis for the content overloading attacks mentioned in the original post.

I may set up a demonstration page later, but for the time being, you are welcome to try any variation of these attacks on your own. If you'd like a test swf to demonstrate with, let me know.

maybe its just me, but the gmail/youtube video does not show the last two or three seconds of the video.

I'm missing the proverbial money shot.

anyone else having the same problem?

Quit telling me to change IE6, you spackers. If I could, I would. I -- and tens of thousands like me -- must work with browser-based applications that still don't work in IE7 or IE8 because Microsoft decided to break their own damned rules and design documents.

Since there's neither an IE6 compatibility mode nor a method to install multiple IE versions I have no choice but to continue using IE6 no matter how annoyingly condescending you choose to be, you toerags.

Lets just assume disabling flash or javascript for majority of users is a no go.

I suppose Antonio is right about the exact domain matching rendering userfiles.mysite.com a safe subdomain to put usercontributed files

Since every site puts usercontributed files in different places, there is no way for Adobe to patch this exploit without changes on each website.

I suggest Adobe extends crossdomain.xml with a tag like this:



This way most sites should only add a few lines of text to crossdomain.xml to keep userfiles from executing.

Or perhaps something like



if we want different foldes to be put in same sandbox.

Oh nice... I see this blog does not like html entities.

The above should read:

Lets just assume disabling flash or javascript for majority of users is a no go.

I suppose Antonio is right about the exact domain matching rendering userfiles.mysite.com a safe subdomain to put usercontributed files

Since every site puts usercontributed files in different places, there is no way for Adobe to patch this exploit without changes on each website.

I suggest Adobe extends crossdomain.xml with a tag like this:

(sandbox url='www.mysite.com/userfiles/*' /)

This way most sites should only add a few lines of text to crossdomain.xml to keep userfiles from executing.

Or perhaps something like

(sandbox context='contextA' url='www.mysite.com/userfiles1/*' /)
(sandbox context='contextB' url='www.mysite.com/userfiles2/*' /)




if we want different foldes to be put in same sandbox.

Second take on posting:
You are stuffing two problems into one title. Which one is the topic?

- Origin policy "issue"
How is this Adobe's fault? Granted it's stupid that data has "a trust" based on domain name, but that's the reality for now. It's got nothing to do with Adobe, they're implementing it to be compliant with the rest of the web.

- "Two files in one"
File type detection checks the file and whether the detection is based on file name extension or content, the conclusion is the same: the WWW-browser chooses who it hands off the content for presentation. Be it a Flash plugin or the browser's internal image rendering engine, it's the browser that decides who it hands off the job to. If there are some half-assed implementations on browsers end, it's their fault. You don't go handing off an image file to a flash player even if there is flash data appended to the image.

More rigorous detections based on file extension and content should be needed on behalf of, for example, Java-player. Not too many cases where that would be a threat in itself. Where that would be a threat, well, there are far more problems going on.

sorry for being slow here, but i can't find any passage of this article that details or even hints towards what kinds of problems the END-USERS viewing these flash files can suffer.

is it so that normally, if a flash file is served from www.test.com, the flash player should allow this script to only fetch data from www.test.com? and now it has been found out that it can fetch data from anywhere, at all times?

if this is so, then how does this pose an extra risk for users on the web? it's not like adservers have been handing out "bad flash" for ages... maybe i am missing something.

Hi Mike, Thanks for the first interesting read of the day. I have a question though. How is this an issue with Flash Origin Policy? This look like an issue with content validation. Consider the case of uploading what the server thinks is a GIF but is actually some executable format like PHP for example? Then whatever executable format you have uploaded when requested has access to the domain where it currently resides. You say one way around this is to host uploaded files on a different domain. This all points to issues with web application design rather than an issue with Flash. Is my assessment correct or is some information missing from the blog?

From what I can see the only Origin Policy violated here was in your example when you use it to get the user to load an SWF file in the google domain.

Cheers,
Patrick

ReallyEvilCanine: you can use Firefox with IETab. Also, just search google for "install multiple ie versions" and you'll find there's plenty of solutions to install multiple versions of IE.

If an untrusted user can get any kind of client-side executable content (Flash, JavaScript, Java, Silverlight, PDF, etc) on a server then that content can make same-origin requests just like any content that was intentionally put on the server. It seems like sanitizing and isolating all user contributed content is the only way to deal with this.

I recently published an article about How Bad Crossdomain Policies Expose Protected Data to Malicious Applications and now it looks like I should write another article about How Un-sanitized and Non-Isolated User Contributed Content Expose Protected Data to Malicious Applications.

-James

Thanks for the clarification on the content-type. Essentially, the browser cares more about the type attribute of the embed tag than the content-type of the object. Got it.

There's something that the web browsers could do to help. Web browsers could alter their Accept request headers when requesting a URL that is expected to deliver a specific content type. Firefox 3, for instance, sends this generic Accept header when requesting an object that the EMBED tag has described as type=application/x-shockwave-flash: "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8". That's just the generic Firefox Accept header, telling the server it will accept anything but prefers HTML, XHTML, or XML; it does not give the server any hint what Firefox really *wants*.

It would be perfectly legal for Firefox to send an Accept request header like "application/x-shockwave-flash;q=0.95,text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" to tell the web server it's expecting a SWF. The web server could then refuse to serve what it thinks is an image/jpeg object. It *might* also be appropriate for the browser to merely send an Accept header like "application/x-shockwave-flash;q=0.95" for the URL specified in the SRC attribute, but I wonder if that might have some adverse effects on error handling, e.g. the server wanting to send a text/html error page. One important point about this fix: browsers would have to send the same Accept header if redirected. and of course browsers could choose to add new X- headers, e.g. "X-Expected-Content-Type: application/x-shockwave-flash"

A similar approach could be taken with other HTML tags, e.g. Accept could start with "image/*;q=0.95" if requesting the SRC for an IMG -- this could help prevent some annoying CSRF stuff like IMG SRC=http://example.com/dbquery.do?records=all&details=verbose

ReallyEvilCanine: you can use Firefox with IETab.

True, but it uses the version of IE installed.

Also, just search google for "install multiple ie versions" and you'll find there's plenty of solutions to install multiple versions of IE.

Stand alone versions are not the same as an installed version.

Attempting to upgrade or downgrade the version of Internet Explorer will leave a system in a extremely unstable state, with a broken system restore dialog! (blank dialog page)


Even attempting to just copy over a different version and force all the files ends up with an unstable system.

Here's a little test for you since you seem to be so smart. You'll have to do it on real hardware, not a hybervisor, vm, etc. Real Metal.

1. Install XP SP3 slipstreamed with IE8
2. Acquire an MBOX 2, and Protols 8LE
3. install XP
4. install the MBOX 2, and Protools 8LE

Tell us more about how we should google (sic) IE. --Google isn't a verb by the way.

Show us how to roll back to IE 7 when there is no directory of uninstall files.

Tell us about your DAE errors, and how you now have to reinstall a box you been building for 4 months.

For extra points try the same experiment with professional language software.

For more extra points show us how to remove ie8 with "perfect uninstall" and "final uninstall" and show us how to remove IE8 and install a lower version. Take notes of how well system restore is working..

Yeah thought so..

Night night..

I might be missing something, but here goes:

I don't understand how this is Adobe's fault. If you can have an image tag like this:



And if "malicious_payload.jpg" is actually a swf file, the browser should very much NOT be executing that swf, and if it is, that's definitely a vulnerability of your browser.

Plus it's really unclear to me what power that gives the attacker over the server. So you can execute this swf file -- so what? The only way a swf can talk to the originating server is by loading URLs from that server. It doesn't have special powers that a web page doesn't have. So the attacker still has to know how to upload some sort of malicious aspx page to the server, in which case what advantage does the swf give you?

argh, again:

I might be missing something, but here goes:

I don't understand how this is Adobe's fault. If you can have an image tag like this:

image source=myphotos.com/images/
malicious_payload.jpg"/

And if "malicious_payload.jpg" is actually a swf file, the browser should very much NOT be executing that swf, and if it is, that's definitely a vulnerability of your browser.

Plus it's really unclear to me what power that gives the attacker over the server. So you can execute this swf file -- so what? The only way a swf can talk to the originating server is by loading URLs from that server. It doesn't have special powers that a web page doesn't have. So the attacker still has to know how to upload some sort of malicious aspx page to the server, in which case what advantage does the swf give you?

This article is, quite simply put, completely irresponsible. The problem is not flash, it's the fact that sysadmins and site managers are not properly securing their upload processes.

There's nothing Adobe can do about this. As a commenter on an article linking to this stated quite well, there is no code patch for stupidity.

Shame on you for creating misdirected FUD, Mike.

Jay,

Thanks for the feedback, but this isn't FUD and it isn't about just "not properly securing" their upload processes.

We'll be posting a FAQ about this later today to help everyone understand the issues in greater detail.

-Mike

eeeeaaii:
Setup:
target server: forums.example.org
evil server: exploit.example.com
attacker: Mallory
victim: Alice
1) Mallory uploads a GIF+SWF to forums.example.org
2) forums.example.org will serve the GIF+SWF as image/gif
3) Mallory makes page on exploit.example.com with EMBED TYPE=application/x-shockwave-flash SRC=http://forums.example.org/images/upload1.gif
4) Mallory gets Alice to open the page on exploit.example.com made in step 3
5) At this point, Alice's browser, expecting a SWF, requests upload1.gif from forums.example.org.
6) Alice's Flash plugin finds a SWF inside the .gif response and executes it. The plugin on Alice's browser sees this as a SWF "published" by the forums.example.org server. The ActionScript inside the SWF can then interact with the forums.example.org server through Alice's browser -- in the process passing along Alice's identification/authentication info. This is a setup for things like CSRF attacks against Alice's account on forums.example.org. See for instance http://blog.guya.net/2008/09/1...d-example/

With my Accept/X-Expected-Content-Type suggestion, in step 5, the server at forums would see that Alice's browser wanted a SWF. The forums server would almost certainly not intend to allow SWF uploads (unlike the cPanel screenshot), so it could then respond with a text/html error page and something like a 403 status code indicating that Alice cannot access upload1.gif with an HTTP request that indicates that Alice really wants a SWF.

Probably servers should generally be configured not to send the "wrong" content type any time the client really wanted anything starting with "application/", or any time the client wanted a type known to be dangerous, e.g. text/javascript.

Phil,
Nice test case. No need to be an asshole.

Hey Mike,

See my comment above.

Can you explain how (or if) this is exclusive to Flash? It seems no different than any other client-side executable content in the browser (Flash, JavaScript, Java, Silverlight, PDF, etc).

Thanks.

-James

I don't believe that this is Adobe's fault. If a Java-based web site administrator allows end-users to upload JSP files and then serves them in such a way that they may be executed as JSPs from that server, is that Sun's fault

I've just done my own testing to simulate the GMail exploit described above, both with GMail itself and with my company's own webmail product. In both cases, we include the correct combination of HTTP response headers to force the user to download SWF files that were attached to messages. That prevents the SWF file from being "served" by the sensitive domain (e.g. mail.google.com). The browser does allow the user to *download* the SWF to their filesystem.

If you try to embed the SWF file (by guessing the URL that GMail would use to provide it) in a malicious HTML page, the Flash Player will *not* launch the SWF file, because of the Content-Disposition header. When I used a proxy to erase the Content-Disposition header in the response from GMail I was able to launch the SWF in my malicious HTML page - but I had to configure my proxy to do so.

What this comes down to is that web site administrators (and application engineers) need to make sure that untrusted SWF content (e.g. message attachments) must not be served over HTTP - they need to make sure that the server forces the browser to download the SWF to their local filesystem.

At that point, the SWF will be like any other file on the user's machine. It could be executed either if the user has the standalone Flash Player, or if they manually drag it to a browser. But then it would not have GMail's origin; it would be a highly restricted SWF that wouldn't have the same cookies as the user's browser session, and wouldn't be allowed to make requests to sites with loose crossdomain.xml files.

GMail may have added the Content-Disposition header since Mike Bailey originally demoed his test. I'd encourage him to try again today.

-Antun

>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.

Source?

"you simply cannot trust user-supplied content", that's true for the whole internet, no matter if you are using flash, asp, php, java or whatever, web developers are the ones responsible to validate user content and place protecting measures in place!

In this case, Flash provides the developers with tools for that so... get your facts straight before jumping into wrong conclusions.

No - The 99% number is Adobe's.

What's interesting is that YouTube uses flash to deliver it's content. Watching that video could have been the thing that crashed you system just now.

Quoted "Peter" --
5) At this point, Alice's browser, expecting a SWF, requests upload1.gif from forums.example.org.
6) Alice's Flash plugin finds a SWF inside the .gif response and executes it.
--Quote


Oh does it now? Or is this IE-only issue? I think it can't be even IE issue. You should try this out, because Firefox doesn't do this.

I don't know how Adobe Flash player determines whether to open a given file or not, but if it's based on actually determining the file's content itself, then it is for real Adobe's fault and should be fixed.

Though I find this highly unlikely, when a program expects a file to be in one format, it really should just go about showing it the way it can, not trying to "hey maybe it's a new exploit which I can trip on.. lemme see if this valid executable file contains content that I can run"


On the other hand if the Flash player trusts the Content-Type it has been given by the WWW-server which says the content-type of the file is Flash even though it clearly starts as an image, it a bug in the browser or the WWW-server (or the library the originator uses to detect file format).

For real! Put this to rest already! Read the comments and realize that the title was completely off the point.

This dudes a fscking moron-- the problem is not a "vulnerability" and "exploitation" of this capability is not an attack. This guy is just some random f*ck trying to make a name for himself by "discovering" how to run uploaded SWF files... BLAH.

VM wrote: ""What's interesting is that YouTube uses flash to deliver it's content. Watching that video could have been the thing that crashed you system just now.""
No. Why not? Simple, the SWF has been created by YouTube, the user uploaded content is only the Video file, that is loaded by this SWF. And exact that is the filter, that protects the viewer here, as every uploaded video goes through a reencoding/compression process on the YouTube-server. That reencoding/compression process kills anything executable inside the uploaded video, the worst thing, that could happen is a unusable, unviewable video.

Regards
Nohab.