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."
FOSS flash plugins? (Score:2, Interesting)
Say it ain't so o o o (Score:1, Interesting)
Re:Client or server? (Score:5, Interesting)
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).
Re:Client or server? (Score:3, Interesting)
Re:Client or server? (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? :-)
Why does a login form need CSRF protection? (Score:3, Interesting)
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.
Uploading a swf with a jpg extension? (Score:4, Interesting)
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.
Re:What the... (Score:5, Interesting)
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.
Re:Flash security has always frightened me (Score:4, Interesting)
Wrong. The two properties of Flash that make it vulnerable to this class of attack are:
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.
Re:Broken security model (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 that unsigned flash objects are not given permission to access the server.
4. Run embedded flash objects in the context of the page they are embedded in, rather than that of the origin server. (Flash objects accessed directly, like javascript run through the javascript: uri handler, have no permissions)
Maybe not ideal, but a hell of a lot better than having everybody vulnerable by default, and expecting the server administrators to fix it for them on a case by case basis.
Re:the article is bullshit. (Score:2, Interesting)
... 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.