Blog Post

Flash Exploit Shows the Dark Side of Web 2.0

Update: As pointed out in the comments below, Symantec has since clarified their original worries about this being a zero-day exploit affecting current versions of Flash. However it still remains a problem affecting earlier versions of Flash. For details about the specific issue, see Adobe’s post on the problem.

Yesterday’s news of an exploit in Flash that gives hackers the ability to redirect a web site’s visitors to malware-laden servers highlights one of the biggest dangers and problems around the interactive web. Allowing third-party programs — such as Flash, mashups, widgets, or even specialized programs for activities such as bill payments — to run in web sites introduces vulnerabilities and performance troubles that are outside the web site owner’s control.

The Flash exploit is noteworthy because people take Flash for granted, the way they do JPEG and GIF images. So they are willing to let third-party content providers such as video sites or advertisers insert Flash into pages. The problem with this is that Flash is much more than an image or video; it’s a powerful programming language. And as a result, it’s vulnerable.

Mashed-up sites are becoming commonplace. Bloggers and site designers grab snippets of code, inserting them within tags in a page, and build a mashup. But it’s often unclear what they’re inserting. For example, recently-launched Apture shows relevant content when users mouse over a link, but they can also insert advertising.

Such third-party applications also slow down the performance of a web site, leading to irritated users and site owners who have less control over a site’s reliability and the overall user experience. This opens up opportunities for companies such as Gomez, AlertSite and Keynote Systems which provide different types of performance monitoring from a user perspective.

The allure of a component Internet is strong. By assembling widgets, Flash elements and third-party plug-ins, developers can quickly build dynamic applications. But unless they know everything that could be injected into their pages, they’re running a significant risk by doing so.

9 Responses to “Flash Exploit Shows the Dark Side of Web 2.0”

  1. Hi, are you aware that the “Web 2.0 danger” here is believing what you’re told, by reporters who don’t investigate stories before collecting ad revenue on them?

    Symantec has backtracked on their initial report, but syndicators and bloggers are still going with the old news:

    The current Adobe Flash Player is, counter to initial reports, apparently not vulnerable after all. Additionally (and to the best of my current information), the “thousands of compromised websites” already had injected HTML which pointed to two servers in China which hosted malformed SWF, and which were shut down pretty quickly after the first news reports.

    I agree with you that advertising networks must vet the content they ask others to republish. This holds true for JavaScript as well as for Flash, and we’ve got the history of goatse to consider as well. We do need more effective antibodies when accepting instructions from strangers.

    But we also need to get the story right. There are risks in blithely accepting programming from strangers, whether that programming is for a computer, or for a belief.


  2. Anyone who “take(s) Flash for granted” does so at their own peril. I run Firefox and have the NoScript add-on installed on every machine I use. NoScript blocks all active content by default and allows you to activate each type of script/plug-in (or all active content) on a per-site basis. A bit cumbersome at first, but it gets easier as you add trusted sites to the white list.

    It’s not fool-proof though, since a “trusted” site could become compromised. Still better than letting every script run by default (one of IE’s enduring faults).

  3. What happens is this:
    1. Crackers used Sql injection and other techniques to insert redirection scripts and flash tags in a few thousand websites.
    2. Visitors to those websites now connect to the “cracker” site and run the “bad”, “exploitive” flash script.
    3. Now the machines are compromised, since the flash runtime has an exploit.

  4. Using any type of technology that you did not write yourself will expose you to unknown risks – web developers use more and more off the shelf tools and some of them are still in the early stages of development. That being said, good off the shelf code will generally be of better quality than the code you write yourself.

    The more technologies we use the more vulnerable we will be to problems with them but this is true for Browsers, Word processors, Email Programs, and pretty much anything else. Flash isn’t too special in this regard and it’s always best to keep your software as uptodate as possible. However, one thing very few people realize is that Flash can actually call JavaScript on your page so malicious Flash objects could be harmful. Flash embeds should always be embedded with allowScriptAccess set to “never” by default unless they need to call some special JavaScript to work.

    As for web services it is definitely important to realize that you are placing some trust in the services you are using. Website authors choosing web servers should be careful about whom they trust, especially since information about the security of services is relatively sparse right now. Apture for example is in use on several blogs on the Washington Post and its architecture and security policies have been examined by technology teams at several publishers. We also try to pick content from reputable sources and only give a small number of trusted sources (e.g. YouTube) script access.

    Finally, I wanted to clarify that Apture only inserts content that was chosen specifically by the page author, so the author is always in full control of what their visitors will be seeing.