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:
  • 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>

  • Client. (Score:2, Insightful)

    by XanC (644172) on Thursday November 12 2009, @08:01PM (#30081542)

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

  • 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.

  • 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.
  • Re:OH NO!!! (Score:3, Insightful)

    by Ragzouken (943900) on Thursday November 12 2009, @08:13PM (#30081670)

    It doesn't matter, and unsigned, obviously.

  • Re:OH NO!!! (Score:2, Insightful)

    by elmedico27 (931070) on Thursday November 12 2009, @08:17PM (#30081696)
    No kidding, call it news when Adobe says "Hey, we're actually going to fix some shit this time!"
  • by smash (1351) <<jethro.rose> <at> <gmail.com>> 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.
  • So Adobe says... (Score:0, Insightful)

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

    "Oops! We found security issues with our software and we plan to do absolute dick about it. The problem is now on everyone else's hands." *shit eating grin*

  • by KillShill (877105) on Thursday November 12 2009, @08:38PM (#30081888)

    I'm glad that 64-bit Firefox doesn't have a flash plugin.

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

    by thePowerOfGrayskull (905905) <marc.paradiseNO@SPAMgmail.com> 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?

  • 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.

  • Bad Adobe! (Score:3, Insightful)

    by onyxruby (118189) <onyxrubyNO@SPAMcomcast.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 Lobster Quadrille (965591) on Thursday November 12 2009, @09:01PM (#30082122)

    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.

  • 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.

  • by Lobster Quadrille (965591) on Thursday November 12 2009, @09:09PM (#30082186)

    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 [xs-sniper.com].

  • Re:OH NO!!! (Score:2, Insightful)

    by wvmarle (1070040) on Thursday November 12 2009, @09:26PM (#30082288)

    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 anything with Flash. So the user has to be able to UPload something and as a result RECEIVE something? From the site they upload to I suppose. Weird to say the least but then maybe I should RTFA to find out more.

    To me the more and more of these issues I see the less it starts to worry me. It's starting to get normal, you start to get used to it, that's not good of course. On the other hand I have the feeling it simply has to do with more awareness, more and more researchers digging around trying out the strangest scenarios to find vulnerabilities. Which in a way is not bad at all.

  • 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 ...

  • Re:OH NO!!! (Score:3, Insightful)

    by Lobster Quadrille (965591) on Thursday November 12 2009, @09:38PM (#30082384)

    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.

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

    It's not often I agree with you, but I do this time, geekoid.

    Abobe model is broken. Flash should be secureable.

  • by dissy (172727) on Thursday November 12 2009, @11:06PM (#30082964)

    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.

    What change exactly can Adobe make to come into play here?

  • by dissy (172727) on Thursday November 12 2009, @11:13PM (#30083006)

    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.

  • by FlyingBishop (1293238) on Thursday November 12 2009, @11:47PM (#30083262)

    Slashdot really needs an appallingly ignorant mod. Or maybe just an RTFA.

  • 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?
  • by tomhudson (43916) <barbara.hudson@b ... m ['ra-' in gap]> on Friday November 13 2009, @12:05AM (#30083380) Journal

    The article is bullshit, and your comment is also misinformed. Read what you wrote after the stuff you quoted:

    Short of rewriting everything that has anything to do with several popular formats, you're out of luck

    The very first rule is "be restrictive in what you allow."

    Anyone uploading an swf with a jpg extension is going to find that they're fucked on anything I'd write, simply because when I call code to resize it and convert it to a png, the swf is going to get really mangled, isn't it ... so your renaming "sploit" isn't going to work.

    This means that ZIP archives, self-extracting executables, Microsoft Office Open XML documents, XPI files, and, if you want to be ridiculous, even JAR files can all be crafted to contain executable SWFs

    If it's not running on the server, and it's not running in the client browser, I don't give a shit what it contains - it's not my problem, and it doesn't affect what I'm doing. I'm not going to use jars from joe q public in my code, it'll be a cold day in hell when I use MSOOXML, xpi files suck, and I'm certainly not going to take an untrusted zip file, unzip it, and use it. And the stuff you quote agrees with me:

    the end result is always the same: no matter how good your validation routines, you simply cannot trust user-supplied content.

    Only an idiot trusts crap uploaded by the general public.

    How, you do ask, is such a prepared file going to be uploaded? A worm that intercepts uploads in the browser, for example. I was able to come up with this in two minuttes (sic), I'm sure that any self-respecting blackhat hacker will as well.

    The source is irrelevant - the simple fact is that if you trust end-user-supplied data, you're either on drugs, or you should be. BTW - Your statement "worm that intercepts uploads in the browser" doesn't even parse. Go back to your bong.

  • wait (Score:3, Insightful)

    by GregNorc (801858) <<gregnorc> <at> <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.

  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Friday November 13 2009, @12:49AM (#30083592)

    unless you consider bash or Windows Explorer to be "special tools," it's not exactly a heinous task.

    Most users do.

  • by Lobster Quadrille (965591) on Friday November 13 2009, @02:27AM (#30084052)

    Maybe you should have read the whole article. Cross-site scripting is never mentioned, and seeing how Mike Bailey, the researcher in question, won $10,000 with a Cross-site scripting attack [slashdot.org], I think he probably knows the difference

    This is a flash attack, dealing with content ownership and poor security controls on flash's part. The end result can indeed be cross-site scripting, but that's not a requirement, and actionscript has different capabilities than javascript.

Brain damage is all in your head. -- Karl Lehenbauer

Working...