Slashdot Mirror
Flash Vulnerability Found, Adobe Says No Fix Forthcoming
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."
Someone has found an issue with Flash?! Say it isn't so...
"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?
Better known as 318230.
I'm very angry that I can't use this vulnerability on my iPhone.
How good it Gnash these days?
It's always risky to execute code downloaded from the Web, be it JavaScript, Flash content, Java Code or ActiveX. NoScript can help mitigate that risk by offering WhiteListing in Firefox. It might not be too convenient, but security seems to be worth it to me.
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>
________
Entranced by anime since late summer 2001 and loving it ^_^
Kind of ironic that an article that warns about flash vulnerabilities as:
Oh, wait - it's ComputerWorld. Sorry, I had my expectations too high.
While I love flash, because I've been working with it for so many years (go ActionScript!) I have seen many things it can do. Unfortunately, most people don't take it seriously. While the issue's only come up after a vulnerability has been used, I've been telling people about the awesome power of AS. Because flash allows for so much, I honestly don't know how you can lock it down. But on the plus side, I don't use flash/AS in a conventional manner, so most of the ways I would be able to (ab)use it is not really in reach for most people because they wouldn't even think of the possibilities that flash can do! So security through obscurity I guess would be the best way to say it.
My abilities are only limited by my imagination
It's not a problem for Web sites, except for their users that run crappy software (ie Flash).
n/t
so we can have malware based on open standards.
Example from the article:
Since when are you going to allow someone to upload an swf for an avatar. It's going to get creamed when you resize it via php anyway.
This is the same "vulnerability" you'd have by allowing people to upload php code, or perl code, or javascript, to your server and you sending it out without doing ANY validation.
In other words, it's not a vulnerability, it's a symptom of totally bonehead design and someone looking for page hits.
What next - "All Windows Versions of Apache Vulnerable To .EXE Exploit" - where they'll say that if you allow people to upload .exe files to your site and blindly execute them, BAD THINGS (TM) will happen?
This belongs in idle.slashdot.org - it's not news, it's so bad it's not even wrong.
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 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.
TFA points out that the flash code can be pre-pended to the entire .zip family, and more.
It is executable code that doesn't look like it is code. That in a nutshell is the problem, aside from the pt of origin of that code being obfuscated.
Another reason to browse inside a VM. btw, anyone know if any browsers can internally handle parallel authentications (ie a virtual browser)?
Comment removed based on user account deletion
Use it.
"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*
they will be devoured by silverlight.
The Kruger Dunning explains most post on
I'm glad that 64-bit Firefox doesn't have a flash plugin.
Science : Proprietary , Knowledge : Open Source
Back on topic: according to TFA Google added protection from CSRF attacks to their login form. But why is this necessary? AFAIK login forms with passwords aren't vulnerable to this attack unless the user gives their password to the attacker's site.
I ask because on my website I have CSRF protection for all forms except logins and I wasn't able to find specific information about security problems with my approach with a Google search.
There's a hidden treasure in Python 3.x: __prepare__()
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?
OK, can we get rid of Flash now?
No? Alright then, just asking.
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.
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.
I made a PHP/MySQL library that prevents SQL injection & makes coding easier!
132 is the number. Do it.
What origin policy does Silverlight use?
This isn't specific to Flash, it applies to ANY active content that automatically runs.
working on an x64 version of flash...
oh, wait...
*insert pithy sig here*
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!
A few hungry lawyers can get this problem fixed in a week. Just get a few injured parties and they will take care of the rest. While they are at it, they can fix the problems with the entire internet protocol suite that allows any application on any box to send and receive any data from any IP with zero traceability or accountability, all for free. This shit has got to end and the only way it will is if the consumers of this 1970s archaic crap we are all swallowing start to complain (i.e., lose money and time).
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 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 with a lax security policy. 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 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 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.
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.
Where are we going and why are we in a handbasket?
Seems like the simple solution is to serve all non-trusted content from a separate hostname. For example, serve avatars or uploaded files from usercontent.example.com.
As far as I can tell this would stop the attack nicely. The malicious SWF would execute in the context of a domain you don't care about.
Oh no, a hacker saw my obligatory wacky animated avatar targeting the monthly pop culture event/person/thing/etc/insert/cmdr_taco/bad news everyone/virgin nerd/all your base belongs to us.
30% off web hosting. Coupon code "SLASHDOT".
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 ...
We already know webmasters are involved.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Couldn't Gnash feature some interface that effectively prohibit a program from doing things common to malware (fetching data from the user's storage, connecting to someplace else, or sending data, for example)? These things might make some uses very inconvenient but more secure by default than Adobe's flash player.
Obviously I don't know enough about what flash players are expected to be able to do, but I don't see the question being raised elsewhere in the thread.
Digital Citizen
ITYM 10000100
I wonder if fears of these sorts of attacks are why many major sites seems to be serving scripts and other static content from a completely different domain instead of a subdomain of the main site like an ostensibly sensible admin would do.
Whenever I see yet another Flash security issue, I wonder if Adobie Gillis is their CEO, or maybe they should change their name.
And Oracle Support cannot understand why so many Oracle admins and/or their organizations have issues with their shiny new Flash-based support web site (to which we upload all kinds of debugging files) ....
Another reason to browse inside a VM
Or run the browser in Sandboxie.
"But this one goes to 11!"
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.
good thing firefox will automatically block this plug in for me, to keep me safe. that's what they do right?
I strongly agree with what Google had to say on that at one point. A virtual browser would only be security through obscurity:
"Virtual machines are sometimes thought of as impenetrable barriers between the guest and host, but in reality they're usually just another layer of software between you and the attacker. As with any complex application, it would be naive to think such a large codebase could be written without some serious bugs creeping in. If any of those bugs are exploitable, attackers restricted to the guest could potentially break out onto the host machine." - http://blogs.zdnet.com/micro-markets/?p=1454
I'm curious why you used that bit of patent text for your signature. I know that many Slashdotters ridicule patents for claiming the invention of common things. But that's not what that sentence is doing in that patent. It's just defining what a "cup" is for purposes of the patent. That's a wise thing to do since a "cup" could also mean a jockstrap, part of a bra, or the hole in a putting green. The invention includes a certain kind of insulated holder for drinking cups, and with that sentence makes clear that it doesn't apply to the other cups.
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.
Take it away brother. I got nothin'!
Seriously, at least on the web-based video front, this is practically the same as Flash BEGGING to be ousted in favor of HTML5.
Chas - The one, the only.
THANK GOD!!!
So now would be the right time to change the label on the server side user agent check from paranoid to advisable?
Damn, I hit preview and I still didn't see it:
Either the browser has to restrict the applet to only show up if it's explicitly told to, or the applet itself has to include something like flashblock
That should be
Either the browser has to restrict the plugin to only see applets if it's explicitly told to, or the plugin itself has to include something like Flashblock
After a little bit of looking further, I found it:
~/.macromedia/Flash_Player/#SharedObjects/
Cil, adobe, cil adobe, C...I....L.... adobe.
I just can't fathom yet another vulnerability, much less one they have no plans to fix, which you apparently don't even need adobe flash installed on your pc to get infected. Seriously come on...this is really crappy news.
Adobe is going to become the Skynet we all fear in the future, watch and see.... :P
Another nail in Flash's coffin. Another Macromedia product Adobe is running into the ground.
Truth, Just Us, And Hatred For All Mankind!
Heh, 4 is the first thing I thought of. I use that number when someone has cut me off on the road.
Hey! It just occurred to me: that binary number is also often used in warmups to intimacy! So that's why they call it fourplay!
Sorry Slasdotters. The predeeding is gonna be a huge whoosh to most of you because, well, you don't get it.
(Heh, heh - my captcha is fourfold :)
I use swf-dec and gnash.
Am I vulnerable?
Ok, that was retorical - bwahahah!