Flash Vulnerability Found, Adobe Says No Fix Forthcoming 355
Posted
by
timothy
from the more-from-the-slums-of-the-internet dept.
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."
Re:Client or server? (Score:3, Informative)
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.
Re:the article is bullshit. (Score:5, Informative)
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.
Re:the article is bullshit. (Score:5, Informative)
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.
Re:Client or server? (Score:4, Informative)
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, Informative)
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:Uploading a swf with a jpg extension? (Score:4, Informative)
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.
Re:Broken security model (Score:2, Informative)
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 data coming from untrusted sources, no exceptions. Even if it's hard.
Bottom line: This is not news. Some random security researcher took a known caveat in a fully-documented system and tried to sensationalize it, that's all.
Re:the article is bullshit. (Score:3, Informative)
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.
Re:Client or server? (Score:2, Informative)
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.
Re:Client or server? (Score:5, Informative)
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......
Re:Broken security model (Score:1, Informative)
I think the fact that such a simple, known attack is news to the people on this board- who are likely the very people that Adobe expects to fix it, is news in itself.
In fact, the researcher himself discussed the fact that this is an old attack, even linking to information about Adobe's flawed remediation measures.
Adobe expects administrators to be aware of this problem. Few are.
Most security people aren't even aware of this problem.
Sites are vulnerable by default, unless they specifically account for it... and again, few know to account for it.
Even fully validated and perfectly valid files can be malicious.
THIS is the news- not the exploit itself.
Re:Client or server? (Score:3, Informative)
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.
Re:Flash security has always frightened me (Score:5, Informative)
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.
Re:the article is bullshit. (Score:5, Informative)
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.
Re:NEWS FLASH: Web sites need to screen uploads (Score:5, Informative)
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.
Re:Client or server? (Score:4, Informative)
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.
Re:Client or server? (Score:3, Informative)
Re:Client or server? (Score:3, Informative)
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.
Re:the article is bullshit. (Score:3, Informative)
//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.