jd/adobe

This page we’re on here does not call any SWF. But it does call 27 third-party domains, each registering an HTTP request tied to an IP address, and many of which deliver changeable JavaScript. The blog entry at foregroundsecurity.com only calls out to two other domains… much more manageable.

If you’re hosting third-party content which you cannot explicitly trust, then that’s an issue, regardless of filetype. Even a GIF enables web-bugs; an ad enables cross-site tracking.

SWF, like .JS, is interactive… more complex than GIF. That’s why the HTML you use to invoke a SWF can control the amount of trust you wish to confer, as noted above… it’s under your control.
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_04.html

(I described the original essay as “offkey” because a hot title buried its lede under anecdotes, and did not link concerned readers to corrective info. Nothing personal.)

jd/adobe

We’re not being off-key. This isn’t cute – this is millions of web sites vulnerable and no fix for anybody. And the problem goes much deeper than “hosting instructions is risky”.

First, the number of ways that Adobe’s instructions can be uploaded (bypassing traditional content filtering) is huge. People can’t avoid hosting .swfs, even if they want to. That’s a large amount of what Mike Bailey’s post focused on.

Second, most web administrators (especially at small-to-medium businesses) don’t treat Flash objects as “code”. They’re treated as content – like a .mpeg or a .wmv. This may be inappropriate, but it’s true – you can’t abdicate responsibility just because you don’t like it. Much like Microsoft before, we have to acknowledge that “secure by default” makes people make a lot fewer inappropriate decisions.

Most importantly, the problem is that administrators CAN’T limit which code runs in their domain. A stronger policy for allowing execution within the domain for any Flash object by the player would allow the administrator to say: “I only want to allow X content to run within my domain”.

That ability doesn’t exist for administrators (but could with a small change to the way cross-domain.xml works)

Adobe’s assertion that it’s up to the administrator belies the reality that it’s not common practice to separate all user-uploaded content to a separate domain.

Heck, if that was common practice, Adobe’s own web properties wouldn’t be vulnerable as well. They are.

-Mike Murray
CISO, Foreground Security

Once you get past the anecdotes, the key seems to be “hosting instructions from strangers is risky”. That’s true. We see it in ad networks, not just Gmail’s SWF-hosting.

Here’s an intro to the options to customize the sandbox around third-party content you may not trust:
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_04.html

The headlines (and cute photos ;-) don’t seem to match the reality…?

jd/adobe