Off the top of my head, here are a few possible changes:

1. Deny connections by default, unless the server specifically says "this application can connect" (This is already how adobe determines policies on remote servers. It would not be so hard to make the object's origin follow the same rules)
2. Check whether the content-type headers of the server delivering the object actually match those of a flash object, preventing the content overloading attacks described in the paper.
3. Implement a signing policy, so that unsigned flash objects are not given permission to access the server.
4. Run embedded flash objects in the context of the page they are embedded in, rather than that of the origin server. (Flash objects accessed directly, like javascript run through the javascript: uri handler, have no permissions)

Maybe not ideal, but a hell of a lot better than having everybody vulnerable by default, and expecting the server administrators to fix it for them on a case by case basis.

And if you allow me to upload a zip file to your site, will you strip out the swf file that's prepended to it? This is key: It's still a perfectly-formatted zip file.

You may start checking for prepended swf files now, but you sure as hell weren't yesterday.

How exactly is this FUD?

And meanwhile, the attackers are using the ridiculously arcane attack vectors to compromise systems. Seems like it'd be useful to have some people that understand them on the good guys' side.

Browsers do use MIME type to decide on the parser, except with embed tags, where they use the content-type attribute of the embed tag to decide which plugin to invoke.

The plugin, in turn, *should* check the MIME type to determine whether the file it's loading is valid. The Flash plugin does not.

On the other hand, the more arcane the attack, the less likely it is to get fixed, and so the more websites remain vulnerable. The end result is that an attacker well-versed in a variety of obscure attacks can find a way into just about everything.

This one, though, does affect an awful lot of sites- it's rare to find a site that doesn't allow users to upload some kind of file. The impression I get is that image uploads may be more or less simple to validate, but most other filetypes aren't.

If you can write an SWF that can be executed to compromise a website, despite the fact that it looks like, acts like, and in fact is a valid MS Word document, I'd call that a problem.

Your JAR example is actually a pretty good one... as TFA mentions, a similar attack with JAR files that looked like GIFs came out in 2008. Sun fixed their plugin.

In this case, it was used to log the user into the attacker's account, which contained the malicious SWF uploaded as an attachment. If the user then logged into gmail (the video uses a registration email to prompt the user to do so), his account would be compromised.

In Gmail's case, there are other privacy consequences to the login CSRF. For example, if the user is logged into an account that I have access to, I can actually view his google search history.

You'd think so, but you'd be wrong. Embedded content can specify the content-type in HTML (in order for the browser to know what plugin to use to load that content), and Flash trusts that declaration, not the content-type supplied by the server. A properly-designed plugin should trust the server, not the HTML that calls it.

If you can pull it off, you deserve to be as BOFHy as possible.

Unless the explanation itself is emailed to them and contains a secondary attack... if they really did it with XSS as the ZDNet article states, that's a reasonable assumption.

But we may be bordering on ridiculous.

ZDnet Article: http://blogs.zdnet.com/security/?p=3514

One of the hackers posted an uninformative response on his blog: http://skeptikal.org/2009/06/strongwebmail-incident.html

Was there doubt as to whether humans practiced cannibalism? It's well documented in Africa and a variety of island nations. I personally know people whose parents did so.

1) You make a purchase, inject javascript into your address. The administrator goes to the website to print shipping labels. Now you control the administrator.

2) You log in. Later that day, you're visiting evil.com, which loads the site in the background, with payload, and slurps data off of it.