Flash Is Vulnerable – No Fix Coming
There is a gaping security hole in Flash, that according to ComputerWorld’s Gregg Keizer “can exploit a flaw… to compromise nearly every Web site that allows users to upload content, including Google’s Gmail, then launch silent attacks on visitors to those sites.”
Not good. But it gets worse.
Adobe has acknowledged the problem, and has promised nothing. No patch, no quick fix, nothing but a thumb of the nose. Adobe has made it plain that websites and their creators are responsible for their security.
That sounds like GM saying drivers are responsible for exploding gas tanks. This is a big, bad problem. Expect to see backlash to Adobe, and some fix in the pipeline. If not, a large swath of the internet is now very, very insecure.
Mike Murray of Foreground Security said it well: “Any site that allows user-uploadable content is vulnerable, and most are not configured to prevent this.”
H/T @MichaelKlurfeld for the tip.
Alex Wilhelm is a Chicago-based technology blogger and entrepreneur. He has worked for a number of technology companies in recent years, and has a particular interest in watching the social web monetize. Follow Alex on Twitter, or on Facebook. You can reach Alex via email at alex.w@thenextweb.com
[...] This post was mentioned on Twitter by David Petherick, by SEOux Indianer, FeedLinks, Chef du Tech, webquebec and others. webquebec said: Flash Is Vulnerable – No Fix Coming: There is a gaping security hole in Flash, that according to ComputerW.. http://bit.ly/120t7D #web [...]
The original blogpost was a little off-key, as were the followup journals, and now the follow-followup blogposts….
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/fl.....ps_04.html
The headlines (and cute photos ;-) don’t seem to match the reality…?
jd/adobe
Your statement seems to contradict what your parent corp. has said. If nothing else, Adobe should issue an emphatic statement explaining that :
1) nothing is broken, and there was some terrible communication.
2) things are broken
John,
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
t
fwiw, I’m not interested in bigger page-hits… not going to get into a big debate.
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/fl.....ps_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
Linux Web Hosting For Small Businesses.
http://twurl.nl/1ri4oo
Followup: Adobe staffer Peleus Uhley has a clear explanation of the issue underlying the discussion:
http://blogs.adobe.com/asset/2.....e-ori.html
jd/adobe