Forgot your password?
typodupeerror
Media Security IT

Flash Vulnerability Found, Adobe Says No Fix Forthcoming 355

Posted by timothy
from the more-from-the-slums-of-the-internet dept.
An anonymous reader writes "Security researchers at Foreground Security have found an issue with Adobe Flash. Any site that allows files to be uploaded could be vulnerable to this issue (whether they serve Flash or not!). Adobe has said that no easy fix exists and no patch is forthcoming. Adobe puts the responsibility on the website administrators themselves to fix this problem, but they themselves seem to be vulnerable to these problems. Every user with Flash installed is vulnerable to this new type of attack and — until IT administrators fix their sites — will continue to be."
This discussion has been archived. No new comments can be posted.

Flash Vulnerability Found, Adobe Says No Fix Forthcoming

Comments Filter:
  • OH NO!!! (Score:4, Funny)

    by Narcocide (102829) on Thursday November 12, 2009 @07:45PM (#30081360) Homepage

    Someone has found an issue with Flash?! Say it isn't so...

    • Re:OH NO!!! (Score:5, Funny)

      by Monkeedude1212 (1560403) on Thursday November 12, 2009 @07:48PM (#30081396) Journal

      I lost count. Can someone help me out again? This time I'll count using Binary on my fingers.

    • Re: (Score:2, Insightful)

      by elmedico27 (931070)
      No kidding, call it news when Adobe says "Hey, we're actually going to fix some shit this time!"
    • Re: (Score:2, Insightful)

      by wvmarle (1070040)

      Yes I was thinking about the same. Flash vulnerability after Windows critical flaw after Firefox hole... some with patches coming, others remaining unpatched (e.g. DNS problems).

      It seems to be getting more and more these days. But I can't imagine that software is getting worse - even Microsoft is thinking about security these days.

      And the flaws are becoming more and more obscure. OK I didn't RTFA but this has to do with users being vulnerable when servers accept file uploads, even if server doesn't do any

      • Re: (Score:3, Insightful)

        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.

  • "Any site that allows files to be uploaded could be vulnerable"

    "Every user with Flash installed is vulnerable"

    So who is vulnerable? The server or the client?

    • Re: (Score:3, Informative)

      by mujadaddy (1238164)
      Server.

      If I can get a Flash object onto your server, I can execute scripts in the context of your domain.

      Only appears to be an issue with servers that accept uploads exactly as TFS says, curiously enough.

      • by smash (1351)
        I read that to mean "i can execute scripts in the security context of your domain on the client's browser". E.G. - you have foosite.com as a site trusted to run active content - some guy can upload a malicious flash object and it will run as if authored/published by the website owner in you browser as a trusted site object. My server for example, has no flash installed, so how is a flash object going to run there?

        Allowing users to upload flash is fucking retarded anyway. Its like allowing users to uplo

        • by PIBM (588930)

          If you had RTFA, you`d have noticed that they are giving ways of having flash uploaded on the server while it`s actually checking for other file types, so it`s not as simple as blocking flash file uploads.

      • Re:Client or server? (Score:5, Informative)

        by Adrian Lopez (2615) on Thursday November 12, 2009 @08:41PM (#30081908) Homepage

        It would probably be more accurate to say that websites (not servers) are vulnerable to such an attack. After all, unless I've misread TFA, no code is actually being executed server side. Instead, what's happening is that any SWF's posted to a publicly-accessible location are being served under the server's domain and therefore any scripts in the SWF will execute with rights to access that domain. There's nothing the SWF can do through scripting that a visitor can't do directly, so depending on how you look at it you could say the server itself isn't vulnerable to this, but the website and the clients are.

        • Re:Client or server? (Score:5, Informative)

          by mysidia (191772) on Thursday November 12, 2009 @10:40PM (#30082764)

          There is no vulnerability if the clients don't have flash installed.

          It's a client-side vulnerability.

          Given flash's popularity, webmasters should understand the risk and block uploads of .SWFs and application/x-flash

          However, expecting webmasters to scan .jpeg uploads of declared type image/jpeg or declared application/octet-stream uploads to determine if flash might execute them, when they are intended to be simple downloads or image displays is way over the line...

          Especially if an attacker can construct an image file that is a valid image, but flash will pick up and execute......

    • by jpmorgan (517966) on Thursday November 12, 2009 @07:56PM (#30081472) Homepage
      I know it's a lot to ask, but you could just RTFA. I guess I'll be the enabler today...

      Apparently it's a server-side vulnerability, but this puts users at risk since hijacking trusted websites makes it much easier to socially engineer malware onto people's computers. I.e., if gmail were to be compromised, and you login to gmail and there's a link to download some special gmail-improving program, a lot of people will download and install it, even though it was placed there by a hacker and not Google themselves.
    • Client. (Score:2, Insightful)

      by XanC (644172)

      It's not a problem for Web sites, except for their users that run crappy software (ie Flash).

    • by Z34107 (925136)

      Relevant part of the article:

      The basic policy for Actionscript is very close to the Javascript same-origin policy: A Flash object can only access content from the domain it originated from. ... The important difference, of course, is that flash objects are not web pages. A flash object does not need to be injected into a web page to execute- simply loading the content is enough. Let's consider the implications of this policy for a moment: If I can get a Flash object onto your server, I can execute scripts i

      • Re: (Score:2, Interesting)

        So, user uploads a file - say, a picture for a forum avatar. Your image validation misses that malicious_flash.jpg is really a SWF file, and now you're executing flash all over the place "in the context of your domain." Which I guess means any SWF file I manage to upload anywhere can eat the hosting webserver.

        Also, from the article:

        To be sure, any server that allows unvalidated uploads of contents will let an attacker upload html pages with cross-site scripting or other attacks, but SWF files do not require a .swf extension or special content-type headers to execute.

        This is what I don't get: I understand that if a JPG is also a SWF (as per GIFAR and other manglements), it'll fool the browser into loading the content as flash.

        Simply chucking a SWF on a server, renaming it to foobar.jpg, and visiting it at http://example/foobar.jpg [example] doesn't load it as flash. Unless I'm really missing something here, I don't see how you can get the JPG to run as flash without also mucking around with content-type headers.

        Can someone enlighten me, please? :-)

        • Re:Client or server? (Score:4, Informative)

          by Anonymous Coward on Thursday November 12, 2009 @08:37PM (#30081884)

          Flash files can also be loaded by embedding them in an HTML page with attributes that say "content-type='application-x-shockwave-flash'" or something like that, regardless of extension or the content-type header given by the server. The server may think it's a zip file, but your browser can still be convinced to run it as flash.

          So, I drop a malicious .docx on vulnerable site, create my own web page that embeds the object, and get you to visit that page. presto, you're pwned.

    • Re:Client or server? (Score:5, Interesting)

      by TheRaven64 (641858) on Thursday November 12, 2009 @08:09PM (#30081626) Journal

      From what I understood skimming TFA, it's a cross-site scripting vulnerability, meaning the client's account on the server is vulnerable. I upload EvilFlash.swf to some site that allows downloads. Then I send you a link to this file. Your browser opens the .swf and runs it with the plugin. Unfortunately for you, the plug in runs it in the hosting site's domain, so it can access anything that you can access on the download site. If the site is something like PutYourFaceInTheBook.com then it will be able to access everything in your account and even modify everything there. It could then send links to everyone else on your friends list and if they click on them then the same thing happens.

      The best way of fixing this would be for Flash to check for public key file in a well-known location on the server and refuse to run any Flash files that are not accompanied by a signature from the corresponding private key (or run them but don't allow them to access any external resources).

    • by Ash Vince (602485) on Thursday November 12, 2009 @08:42PM (#30081926) Journal

      I have just read the article. The problem seems to be with sites who allow flash object to be uploaded, then served to other people using the site. Of course, this is just stupid anyway. If I allow you to upload a flash object to my site, I should sanitise it before I allow my server to give it to anyone. The example they give is an animated avatar, but that is poor example as they should be restricted to animated gifs anyway.

      This is just more FUD. ActionScript is a very powerful language, and so server admins should only allow flash files they trust to be served up form websites they maintain. To my mind that is just common sense. The only alternative would be for Adobe to cripple Flash beyond belief so it was only useful for a small percentage of what it is currently used for.

    • Re: (Score:3, Informative)

      It requires a vulnerability in both the server and the client. The server's vulnerability is that it allows SWF's to be uploaded and it's hard to validate whether it's a SWF or something else (the article uses the example of a file that's both a SWF and a valid ZIP file).

      The client side vulnerability is that it will execute any SWF as a flash object even if the extension or the headers are wrong. Once this is done, then the SWF object is running as if it's from the hacked website, which is basically an
  • iPhone (Score:5, Funny)

    by Anonymous Coward on Thursday November 12, 2009 @07:51PM (#30081424)

    I'm very angry that I can't use this vulnerability on my iPhone.

  • FOSS flash plugins? (Score:2, Interesting)

    by Tubal-Cain (1289912)
    How good it Gnash these days?
  • by Inf0phreak (627499) on Thursday November 12, 2009 @07:58PM (#30081500)
    <profanity>
    Adobe's answer is just the greatest kind of cop out. "Websites just need to make sure to check all uploaded material". But that's obviously never going to happen -- fuck they can't even do that themselves! End users can't rely on every single website out there to be vigilant at all times and never accept an upload of a flash file.

    If this is really unfixable in the flash plugin, then maybe it's because your security model is fucking broken and it's time to throw this piece of shit away?
    </profanity>

    • by smash (1351) on Thursday November 12, 2009 @08:24PM (#30081774) Homepage Journal
      Its not adobe's problem to fix. If you allow users to upload executable content to your web-server, and then have your web-app present that un-sanitized executable content to other users, you're a fucking idiot.
      • We already know webmasters are involved.

    • Re: (Score:2, Informative)

      by Eil (82413)

      Adobe's answer is just the greatest kind of cop out. "Websites just need to make sure to check all uploaded material".

      Just because you have a seething hated of Adobe and didn't bother to RTFM doesn't mean Adobe is wrong.

      I'm no security expert, but the issue seems to boil down to:

      1) It might be considered a security flaw by some, but it's not a bug and it's not even unique to Flash. Everything is working as designed.
      2) Yes, in 2009, website programmers still have to throughly validate and/or sanitize all dat

    • Re: (Score:3, Insightful)

      by dissy (172727)

      Adobe's answer is just the greatest kind of cop out.

      How exactly would you suggest Adobe modify the flash plugin so that it will run on your computer when I am the one to upload it to my website, but not run it when someone else who I have given permission (thus access) to upload it to my site in my name?

      Either you run code from my website, or you don't. You can't base any decisions on if it was my SCP client that uploaded it to the web server, or someone else uploaded it, mainly because there is no possible way for the server nor you to tell the difference.

      • Re: (Score:3, Insightful)

        by dissy (172727)

        mainly because there is no possible way for the server nor you to tell the difference.

        I fail. I meant there is no way for the browser to tell the difference.

        Obviously the server can tell the difference, and in fact is the only thing that can easily tell the difference, thus why it is a web server issue.

      • Re: (Score:3, Interesting)

        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

  • Kind of ironic that an article that warns about flash vulnerabilities as:

    1. A flash interstitial ad
    2. A page loaded with flash

    Oh, wait - it's ComputerWorld. Sorry, I had my expectations too high.

  • by ClosedSource (238333) on Thursday November 12, 2009 @08:03PM (#30081560)

    so we can have malware based on open standards.

  • by Anonymous Coward on Thursday November 12, 2009 @08:09PM (#30081630)

    This is ridiculous. If a web site lets you upload a JavaScript file and then serves it back to you as part of a request, it would be crazy. All that has happened here is that people have worked out that doing the same thing with a Flash file is equally bad.

    Of course there's no easy fix apart from web sites being sensible in what they upload -- just like anyone with a clue doesn't let users submit comments with tags in them.

    • Actually, if you'd bothered to RTFA (I know, I know) the author gives concrete examples of where the SWF payload can be embedded in a swath of other media types and still successfully be used as an attack vector. It's a more complex problem than just serving user-generated SWF files.

      • But this isn't just SWF payload - any kind of payload can be embedded in the same way, and carry the same risks. In addition, unless I'm missing something, the flash content is limited to accessing things owned by that domain, and stored on the client computer by that domain (maybe even within flash itself? not sure?) . Which means - unless a server is particularly stupid about what it keeps on teh client - that the damage it can do is fairly limited, doesn't it?
    • by smash (1351)
      AC needs modding up...
    • by drew (2081) on Friday November 13, 2009 @01:40AM (#30083794) Homepage

      You missed the point. Flash is not equally bad as JavaScript, it's far worse.

      Suppose I'm an attacker, and I upload a malicious javascript file to www.victimsite.example. I then reference it in a site I control www.seemingly-innocuous.example, the javascript file runs in the www.seemingly-innocuous.example domain sandbox. Even though the file was loaded from www.victimsite.example, it can't actually access anything on the victim's site. In order for that to happen I would have to also upload a malicious html document to www.victimsite.example, and convince unwary surfers to visit this new page.

      Now I decide to switch to flash. I upload a malicious SWF to www.victimsite.example, and embed it into a page at www.seemingly-innocuous.example. Unlike the JavaScript example, my malicious SWF now runs in the www.victimsite.example domain security sandbox, and can make any requests it wants to the victimsite.example domain without the visitor to my seemingly innocuous domain being any the wiser.

      It is a big deal, and it is nothing at all like JavaScript. But it's also not remotely new. I'm having a hard time finding anything in this article that hasn't been widely know for some time now. It even mentions attacks that have been going on for years.

  • The vulnerability (Score:5, Insightful)

    by Stan Vassilev (939229) on Thursday November 12, 2009 @08:13PM (#30081666)
    The vulnerability is not new at all. It's been known for probably coupe of years now. If a site accepts file uploads, in some cases even if simply displays user submitted data like *comments*, a malicious user may upload content that contains a policy XML snippet (the resulting file doesn't have to start with the snippet as well due to some specific of how the content is parsed). Flash can be pointed to that snippet and it will blindly accept it as the security policy for that domain/folder.

    The security implications are that even if the site doesn't use Flash itself, a user opening a third party site with Flash could read from the site with the faulty policy.

    Say Facebook is vulnerable to this problem (likely it is), and you're logged in. Opening another site will allow Flash on that third party site to read your Facebook details, as it has access to anything you do.

    This problem was introduced sometimes Flash 7-8 (I forget) when an ability was added for Flash to read policy files from a custom URL. Prios to that, the only valid location was www.example.com/crossdomain.xml, which is, of course far simpler to lock down and secure. The bottom line is, they can fix this in a number of ways, but not in a backwards compatible manner. For the moment they simply seems to have their bets that people don't care enough about this problem to warrant the effort.
  • Flashblock (Score:2, Offtopic)

    by Spatial (1235392)
    Use it [mozilla.org].
    • by MBCook (132727)
      No kidding. ClickToFlash [github.com] is the equivalent for Safari on OS X. The web is so much nicer when you get to chose to display Flash content.
  • they will be devoured by silverlight.

    • What origin policy does Silverlight use?

      This isn't specific to Flash, it applies to ANY active content that automatically runs.

      • Isn't this bug specifically talking about cross-site scripting? So it depends on how Silverlight manages that. I don't know the answer to that.
  • I'm glad that 64-bit Firefox doesn't have a flash plugin.

  • What the... (Score:4, Insightful)

    by thePowerOfGrayskull (905905) <marc.paradise@g m a i l . c om> on Thursday November 12, 2009 @08:41PM (#30081910) Homepage Journal

    Instead, Arkin added, Adobe has tried to get the word out to Web application designers and site administrators about the danger of allowing users to upload content. "Sites should not allow user uploads to a trusted domain," Arkin argued. "The real issue here is that developers should be cautious about using techniques that can be misused maliciously. In general, this is a general challenge in managing active content."

    Arkin is from Adobe. And he's seriously saying that in order to "fix" this, web site owners must simply disallow users from uploading files. Period. (Not through Flash, but all file uploading .) That's a spectacular answer.

    On the other hand... I kind of understand where he's comign from. If you let your users upload content unchecked, and serve that content up, you are potentially giving some level of access to client machines. In this case, it seems somewhat minimal? I'm not familiar with actionscript, but you don't get free reign to the user's machien do you? Only content specifically store under the domain of the owning server, in the context of Flash?

    • Re:What the... (Score:5, Interesting)

      by Tacvek (948259) on Thursday November 12, 2009 @10:05PM (#30082556) Journal

      He said don't allow uploads to trusted domains. If you want users to upload, they should be uploading to a separate domain. For example my-social-networking-site.com should host uploaded files at MSNS-files.com, or something like that. Being able to execute scripts in the context of MSNS-files.com would be worthless, while executing in the context of my-social-networking-site.com is very valuable.

  • Implement flashblock in the flash plugin itself, so that users have to explicitly request flash content be run, even if it's packaged in a way that manages to slip by flashblock.

  • by FsG (648587) on Thursday November 12, 2009 @08:46PM (#30081958)

    There's one thing I don't understand from the article.. how can this be triggered through files with other extensions that are served with a proper content type? I mean, let's say you have a phpBB3 (with attachments enabled) forum and some guy uploads a jpg. It's actually a swf in disguise, but phpBB's own checks miss that. Then it's served back to a user with a jpg extension and a jpeg content-type.

    According to the article, the SWF can still be executed under these circumstances, but that seems implausible to me. I would think that the browser would simply invoke the jpeg handler, fail to parse the image data, and throw an error.

    • by kipin (981566)

      According to the article, the SWF can still be executed under these circumstances, but that seems implausible to me. I would think that the browser would simply invoke the jpeg handler, fail to parse the image data, and throw an error.

      I don't know if gif/jpeg rules are the same. But you can upload a GIF as a JPEG, and it will still render as a GIF, even though the file is itself JPEG. In fact, even some free image hosting sites exploit this "vulnerability". If you upload a GIF to tinypic, it will rename the file and place the .jpg extension after it.

      Firefox and IE seem to have no problem deciphering this so I doubt it is something that the browsers specifically disallow.

      • by FsG (648587)

        Correct.. browsers use the MIME type sent by the server, rather than the file extension, to decide which parser to invoke.

        So if you have an upload facility, all you have to do is be sure that you're using the jpeg MIME type for jpegs and the gif MIME types for gifs.. it shouldn't matter if the actual bits of the file are an image, an SWF, or even an EXE.. the browser should be invoking the handler that corresponds to the MIME type, not examining the bits of the file to try to guess what it is.

        It really look

    • by Lobster Quadrille (965591) on Thursday November 12, 2009 @08:58PM (#30082084)

      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.

      • by QuoteMstr (55051)

        Configuring a web server to send the correct content-type header would take all of five minutes. Clearly, Adobe cares more about saving five minutes of web developer time than about preventing identity theft for millions.

        I'm not kidding. Web developer pay Adobe. Flash users don't.

  • Bad Adobe! (Score:3, Insightful)

    by onyxruby (118189) <{onyxruby} {at} {comcast.net}> on Thursday November 12, 2009 @08:58PM (#30082082)
    This is the same kind of logic Microsoft used with security in the 9.x kernel. Putting the impetus on third parties to behave and not take advantage of this is nuts! Are they not the least bit familiar with malware or anything else of the like? Bad Adobe, bad!
  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Thursday November 12, 2009 @09:04PM (#30082144)

    I've been worried about Flash security for a long time now. I'd like to point out three features of Flash that bother me.

    First, Flash allows a web application to paste data to the clipboard [jeffothy.com] even if the browser itself forbids this. Of the major browsers, only IE allows applications to directly set the clipboard content.

    Second, Flash has an XMLHttpRequest equivalent [xml.com] with a lax security policy [adobe.com]. Cross-domain retrieval is controlled by an XML control file listing permissible origins.

    Finally, Flash has its own cookie system. These Flash cookies are hidden from the user, and require special tools [fightidentitytheft.com] to remove.

    These features are secure in themselves, but are enablers: they give attackers the means to exploit other vulnerabilities.

    Unfortunately, this cavalier attitude fits Adobe's business model. Lax security is as much a feature of Flash as its vector graphics. Flash allows web developers "get shit done" with no regard for the security of the web ecosystem as a whole. Web developers then come to rely on Flash, which increases the adoption of Flash Player among users, which in turn increases the value of Adobe's authoring tools. Being insecure is lucrative, up to the point that the vulnerabilities become so egregious that users disable Flash.

    On the other hand, browser vendors seem to take a mostly-conservative approach to security (don't laugh yet): consider XMLHttpRequest: sure, its same-origin restriction on the target URL is inconvenient, and the restriction might have been loosened [w3.org] while remaining secure. But this same prudent restriction has also prevented many attacks. Browser vendors have the right incentives because users have a realistic choice of browsers. Flash is an all-or-nothing affair.

    I wish I had an answer. Hopefully, HTML 5 will become widely supported enough that websites won't feel compelled to use Flash for graphics and storage, and eventually Flash's market penetration will sink below the point that web developers can consider it a viable way to circumvent browser security.

    • I wish I had an answer.

      [Silver|Moon]light!

      ;)

      • by Niten (201835) on Thursday November 12, 2009 @10:18PM (#30082622)

        Wrong. The two properties of Flash that make it vulnerable to this class of attack are:

        1. It relies upon a same-origin security model, and
        2. Unlike JavaScript code, Flash objects can be executed by simply being loaded by a browser

        Both of these things are just as true for Silverlight as for Flash, so this issue will affect Microsoft Silverlight and its users as well. The reason that this is being advertised as a "Flash vulnerability" instead of a "Silverlight vulnerability" is, I'm sure, simply due to Silverlight's relatively tiny market share.

        On the other hand, HTML 5 + JavaScript, Canvas, etc. is a solution to this.

    • by Dirtside (91468) on Friday November 13, 2009 @12:34AM (#30083512) Journal

      These Flash cookies are hidden from the user, and require special tools [fightidentitytheft.com] to remove.

      Not to speak to any of your other points, but this isn't true. The Flash cookies are simply in your filesystem somewhere and can be deleted like any other files. (Where they are exactly depends on your browser and OS, but they're still just regular files.)

      You can't delete them from within the browser without addons or plugins (in other words, the Flash plugin itself does not let you do this -- at least, not without manually setting the allowed disk space to 0 for every single website, which is impractical at best), but unless you consider bash or Windows Explorer to be "special tools," it's not exactly a heinous task.

  • That can look for a signature in the uploaded file bytes that means the file is a swf? or a swf-readable policy xml file?

    Anyone know of code that does that? Maybe Adobe would be kind enough to release some Java code and python
    code for detecting their own files.

  • by Anonymous Coward on Thursday November 12, 2009 @09:29PM (#30082308)

    To disable Flash and Shockwave in my main browser.

    It's remarkable how nice it is to surf the modern web without them ... ads (that I don't already block) have small fonts and easy-to-ignore plain text, I can listen to music and surf, and not have some crappy video start playing in a background window ... I'm loving it.

    If I need Flash, I'll just surf with one of the alternate browsers for a page or three. The rest of the time ... bliss. Sheer bliss ...

  • by lidocaineus (661282) on Thursday November 12, 2009 @11:52PM (#30083294)

    I get the gist of the article - user flash content shouldn't be served from the same domain as your app.

    But here's the thing - I know many, many people who run webservers just for the hell of it, and give free accounts to friends and such (the ubiquitous public_html subdirectory for a user, aka ~ ). So let's say the webserver at example.com has something like a secure login for webmail access or other stuff on there as well. It's not terribly vital, but it's still in place. One of the users maliciously uploads one of these flash files, has another person run it, and then that person logs in to another section of example.com - can the attacker then grab that data? It seems to be the case.

    So what the hell are people in this situation supposed to do? Is the only solution to move all that user content to a subdomain as well? Seriously? At least javascript is confined mostly to a single PAGE - please tell me I'm reading this incorrectly.

  • by darrenkopp (981266) on Friday November 13, 2009 @12:01AM (#30083360) Homepage
    good thing firefox will automatically block this plug in for me, to keep me safe. that's what they do right?
  • wait (Score:3, Insightful)

    by GregNorc (801858) <gregnorc&gmail,com> on Friday November 13, 2009 @12:45AM (#30083570)

    If the malicious content is served by the site, then even using a whitelist ala Flashblock won't work, will it? That's pretty scary.

    • Re: (Score:3, Funny)

      by AHuxley (892839)
      Wow, thats not nice. Way to much power in one web based tool.
      This should all be so sandboxed and open sourced
      Let some smart people around the world fix all this stuff :)
      No bloat, faster, safer and Adobe can keep its secrets for media/vids ect.

Things are not as simple as they seems at first. - Edward Thorp

Working...