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...
I'm very angry that I can't use this vulnerability on my iPhone.
How good it Gnash these days?
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.
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
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.
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.
so we can have malware based on open standards.
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).
I am TheRaven on Soylent News
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 irony of this comment is how bad my example is. Had I RTFA better, I wouldn't have used that example.
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.
Didn't really read the article, did you?
Uploading the swf as an avatar is just the beginning. You can also overload ZIP files, which also includes .docx, making perfectly legal documents that also are executable flash objects. Also, many server-side validation libraries apparently will also not catch properly malformed (if such a thing is possible) pdfs, mp3s, etc.
Ironically, all that email antivirus that require you to zip up your files does no good here... a overloaded zip file can be used to compromise webmail clients (like gmail, as in the example).
Flash's security policy is severely broken. I'd call this a pretty big deal.
Comment removed based on user account deletion
You, sir, are entitled to the Arrogant Uninformed Derogatory Comment of The Day Award. Here's why, a quote from TFA:
It gets worse. Uploading a SWF with a .jpg extension, or a forged content-type header will get you a long way, but what if you can upload perfectly valid files with malicious content? Remember GIFAR? The basic premise is this: Overload a GIF file with a JAR archive. Specifically, the ZIP file format can be appended to any binary file and still be valid. The GIF format, in turn, can have any binary file appended to it. The JAR archive, being essentially a ZIP file, can be combined with a GIF image to create a a file that is both a valid image and a perfectly valid JAR archive. While SWF files cannot be appended to other formats, the inverse of the GIFAR exploit works- any file format in the ZIP family can have a SWF file prepended to it. 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. Additionally, if you don't care too much about compliance with standards (and what attacker does?), many server-side content validation libraries will also allow malformed PDFs, MP3s, and other media formats, so long as you are careful not to mangle them too much. This content overloading technique has countless variations, but the end result is always the same: no matter how good your validation routines, you simply cannot trust user-supplied content.
Short of rewriting everything that has anything to do with several popular formats, you're out of luck.
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, I'm sure that any self-respecting blackhat hacker will as well.
This is Slashdot. Common sense is futile. You will be modded down.
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 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? :-)
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.
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__()
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.
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
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?
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.
I dont read
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!
I'll have to find the right web site to browse to in order to handle the carry
I work for the Department of Redundancy Department.
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!
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.
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 ...
No. Read the quote again.
A malicious Flash payload can be smuggled in an image that looks absolutely harmless for MIME checking libraries. The magic number is there, as are the headers and sometimes even the actual image data that produces an actual image. I'm not familiar with the details of GIF and JPEG payloading, but I've read that clever techniques exist for producing images that can be even read by ImageMagick and similar libraries, for example to produce thumbnails. The thumbnail will not carry the payload, of course, but image hosting sites often save the original full sized image as it is, to avoid degrading it with further compression. This effectively means that an image could be prepared that will upload and display just fine even when thumbnail generation and MIME checking is employed.
There is one effective defense, though - serving user-uploaded content from a dedicated domain that contains absolutely nothing but static files. I'm glad that my website is doing that for a long time already, originally for my convinience of being able to move the files to a different server with only a single rsync call and a DNS record change, but it's paying off in other areas as well.
This is Slashdot. Common sense is futile. You will be modded down.
Since almost all web-apps check content by the Content-Type and file extension; it's either not broken or is in very good company (you're essentially saying everything is broken, including Gmail's ability to attach image files such as .jpegs of declared type Image/Jpeg which are actually SWFs)...
By far it is flash that is broken. The flash plugin shouldn't execute on image/jpeg content types.
They are simply ignoring web standards and executing code if the magic number matches. This is clearly a bug in flash.
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......
Slashdot really needs an appallingly ignorant mod. Or maybe just an RTFA.
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.
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 XSS attack on steroids.
Overall, it's a pretty interesting hack, but harder to pull off than your average XSS vulnerability. It requires problems in the server, browser and flash client.
good thing firefox will automatically block this plug in for me, to keep me safe. that's what they do right?
... except that the file should be handled as either an swf or a zip - if the browser handles it as both, for any reason, then it's the browser implementation that is broken.
For example, if the browser says "all files that end in ".zip" , I'll do "x" with them, AND says "all files that have a header that begins with the magic number for an swf, I'll do "y" with them, so that you cat the swf and the zip and you can end up running both plugins, it's a broken browser.
To illustrate:
BAD:
if_file_has_swf_header() {code}
if_file_has_zip_ext() {code}
A file with an swf header and a zip extension runs both pieces of code. Bad programmer. BAD programmer. No treat for you!
GOOD:
#define IS_SWF 0x01;
#define IS_ZIP 0x02;
#define IS_DOC 0x04;
FILE_TYPE_MASK tile_type_mask = 0x00;
// at this point, the invalid file sets the mask to 0x03, (both swf and zip bits set)
// since file_type_mask doesn't match any of the valid values, it calls the unknown_or_corrupt_file() routine.
if_file_has_swf_header( file_type_mask += IS_SWF);
if_file_has_zip_ext() {file_type_mask +=IS_ZIP};
if_file_has_doc_ext() {file_type_mask +=IS_DOC};
switch (file_type_mask) {
case IS_SWF: some code; break;
case IS_ZIP: some code; break;
case IS_DOC: some code; break;
default: unknown_or_corrupt_file();
}
In the second example, your file is completely ignored, because it has more than one bit in the mask set, It isn't recognized as a valid swf, and it isn't recognized as a valid zip. The browser doesn't try to load it in the flash plugin, and doesn't try to display the zipped contents either.
All code should have one execution path or "choke point" for stuff like this. If your code doesn't, it's an indication that you need to refactor. If you have a waterfall of if statements, you have a logic fart waiting to stink up the place.
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.
It doesn't quite work like that. Most browsers don't look at magic bytes to try to guess the content of a file, nor do they look at the file extension (since there's no need for anything on the web to actually have a file extension at all); the content-type header is sent by the server for that purpose. (Internet Explorer is one exception to the "most browsers" rule.).
If you click on a link to a .zip file with SWF at the start, the server will (probably) say it's content-type is application/zip or similar, and the browser will do whatever it's configured to do for that kind of content. If the server says its content-type is image/jpeg, the browser will try to interpret it as a JPEG image (and probably fail, resulting in an error being displayed). The browser doesn't try to guess what the content is (unless it's MSIE).
However, you don't normally run a Flash object by clicking on a link to it. When you link to/embed an external resource within HTML, you can specify the content-type within the HTML. Think <link rel="stylesheet" href="..." type="text/css"> for including a stylesheet. This tells the browser not just where it is, but also what it is. This effectively overrides whatever content-type the server sends. It's very often used with <object> or <embed> tags to give the browser an idea of what the object is so it knows whether or not it can handle it before it requests it. It also enables you to put content on servers which don't have a mime-type configured for that file extension and still have them work.
As such, you can embed in a Flash object into a page, referencing an object with a .zip extension, and the browser will ignore the content-type as supplied by the server because it's already been told that it's a Flash object. Therefore, it'll be executed by the Flash plugin. If you also had a normal direct link to the file on the same page and a user clicked on it, it'd be opened in their archive manager, because the browser would be relying on the content-type header sent by the server.
That really isn't a stretch- most XSS and CSRF exploits work the same way. It just requires that the user be logged into victim.com and click a link to evil.com.
"The cup is in turn designed for holding hot or cold liquids, and has an open rim and closed base." --US Patent #5425497
It can issue HTTP requests to the server, including POST requests containing form submissions. If this functionality is exposed to you via a web interface then it's also exposed to the Flash program. If there's a page which lets you send messages to your contacts, it can visit that page and send links to itself using that.
I am TheRaven on Soylent News
No it's not, the formats allow for this. A zip file can have a SWF prepended to it and still be a valid zip file. New Office documents are zip files, so an attacker could create an office document and then prepend a SWF file to it. That makes a valid zip-family file with an executable SWF payload, and the content type says that it's a Word document or whatever.
What kind of content checking do you recommend to mitigate this? Since you're asserting that everyone else's content checking is broken, then I assume that yours works, can you share it? Your extensive admin experience should give you insight that most people don't have.
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
//Only an idiot trusts crap uploaded by the general public.//
Some sites by their nature rely on user-supplied content. Facebook, photography enthusiasts, and community blogs all accept files from one user and make them available to another (which is essentially all the site must do in order to bu vulnerable).
In many cases, you can process whatever they send you, but there may be cases where you cannot reencode images, covert document formats, or alter/filter/forbid their files. (Whatever the reason---whether it's a matter of legality, policy, or user expectations.) Or you may simply be hosting files.
Making a user-supplied file available via HTTP is all that you need in order to be exploited. While you may not need to do this, there are legitimate cases where others do.
Ultimately, scanning inbound files for the bits that the Flash plugin uses to identify valid SWF files and removing them should remediate the vulnerability completely---but this shouldn't be necessary because Adobe should have an effective security model.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.