Page 2 of 4

Re: Adobe is not willing to fix Flash security issues.

Posted: Mon Nov 30, 2009 7:36 am
by josh
kaisellgren wrote:Just hold your horses, things will be better understood soon. My time is pretty limited right now.
I don't see why a simple explanation isn't justified? You're going to make gmail think it is a jpeg so it doesn't send a content-disposition header, but thru some file extension/hex editing magic you will get gmail to send headers that invoke flash player without a content-disposition header?

If you haven't thought about it enough to sum it up succinctly, you are probably just making hypothesis about what will/will not work. There's nothing wrong with that, but it is wrong IMO to present a hypothesis as fact, especially at the cost of other's reputation

Re: Adobe is not willing to fix Flash security issues.

Posted: Wed Dec 02, 2009 2:04 am
by kaisellgren
I'll be at home on Friday so I'll then show a demo movie of a CSRF attack. I'm not posting any working code here, sorry.
Josh wrote:but it is wrong IMO to present a hypothesis as fact
It's a hypothesis only in case of Gmail, but I never said they are vulnerable to anything, although it's likely because they serve certain MIME types with Content-Type only.

Re: Adobe is not willing to fix Flash security issues.

Posted: Wed Dec 02, 2009 1:31 pm
by josh
So you're going to create a file that is a valid jpeg, that is a valid swf, and that has valid actionscript code, and enough of it to do an exploit?

No one asked for working code, however if you are going to go attacking (as in slandering) companies it is the burden of you to provide evidence of their flaw.

Re: Adobe is not willing to fix Flash security issues.

Posted: Sat Dec 05, 2009 12:24 pm
by kaisellgren
http://www.youtube.com/watch?v=9qZBCH7FGZ0

In this video, I'm showing a simplistic example of the issues I've been talking about. In essence it goes like this: visit my blog and I've got your sensitive details. (I've been taking this code out of my website by now.)

This is a confidentiality issue. In the mentioned video, I'm just reading the basic accounts details. However, Adobe should fix this since I could even read your Adobe product serials, use them or get them banned by sharing the serials (your account too). Adobe products cost hell a lot of money and the target site is just Adobe at this time. Also, I think I have not said yet that this technique does not always require file uploading, simple "online text editor" could be enough and I actually managed to find my local hospital to be vulnerable and leak sensitive patient details.

And as you are a clever guy, I'm sure you understand that I can also achieve CSRF attacks because I can read the tokens.

This is all possible due to Adobe Flash not respecting MIME types and because it does not use the Same Origin Policy. To be honest, it is not fatal to not change their policy, but at least they need to respect those damn MIME types. If they decide not to change their policy, how about telling the truth to the developers and stop telling us that Flash uses the Same Origin Policy, because it doesn't.

Re: Adobe is not willing to fix Flash security issues.

Posted: Sat Dec 05, 2009 3:19 pm
by josh
Interesting, I was able to reproduce on my server on using different formats (prep-ended an empty zip file to a swf object, and embedded it)

So what is the recommended blacklisting approach you recommend? With a jpeg we can resize it 1 pixel or whatever like you always recommend, but in the case of a .swf simply renamed to .txt?

This reminds me of "remote PHP inclusion", except in this circumstance its not the code does that including that gets attacked, its the server that simply thought was hosting an innocuous txt file. Very sad on Adobe's part. This is what you would expect to be typical of a company like Microsoft. Hey I wonder if we have to blacklist silverlight too.

I think this flaw has likely existed since Macromedia, so that is the corporate entity truly at blame (I think Adobe simply doesn't understand it, or is afraid to change it - probably due to an "internal communications issue")

Re: Adobe is not willing to fix Flash security issues.

Posted: Sat Dec 05, 2009 3:56 pm
by kaisellgren
If you want as a web programmer to upload files to a non-throwaway domain, then you should alter the file contents somehow if possible. With pictures, resize them.
josh wrote:So what is the recommended blacklisting approach you recommend? With a jpeg we can resize it 1 pixel or whatever like you always recommend, but in the case of a .swf simply renamed to .txt?
Renaming affects nothing, but resizing should work fine. The problem is there are other file types then images...
josh wrote:Hey I wonder if we have to blacklist silverlight too.
Silverlight seems to be safe, at least on a quick look.
josh wrote:I think this flaw has likely existed since Macromedia, so that is the corporate entity truly at blame (I think Adobe simply doesn't understand it, or is afraid to change it - probably due to an "internal communications issue")
That's right. It has existed ever since Flash 1. :)

Re: Adobe is not willing to fix Flash security issues.

Posted: Sat Dec 05, 2009 6:04 pm
by josh
kaisellgren wrote: The problem is there are other file types then images...
Exactly. Since you seem to be up to date on the byte codes, what byte code should I blacklist in all file types? Some files are impossible to modify from PHP because there is no open source implementation for working with them, or spec on how to make your own. A simple blacklist should protect us, but what do you recommend that would have no loop holes?

I just reported it to Adobe *again*, I don't have permission to view my own issue though because I marked it as security related. Maybe if we keep submitting it they'll fix it.

Re: Adobe is not willing to fix Flash security issues.

Posted: Sun Dec 06, 2009 5:17 am
by kaisellgren
Follow these until you find a solution that is possible for you:
1) Get a throwaway domain.
2) Send Content-Disposition headers for data that is opened non-inline.
3) Resize pictures.
4) Look for the three first bytes in the file if they are 0x46 0x57 0x53 or 0x43 0x57 0x53.

And ah, for client-side security, get Flashblock for Firefox, Toggle Flash for IE, Flashblock for Chrome, ClickToFlash for Webkit (e.g. Safari).

Re: Adobe is not willing to fix Flash security issues.

Posted: Sun Dec 06, 2009 7:51 am
by josh
That would be acceptable for .swf files, to host them off-domain, but if the website's SEO strategy is to utilized user uploaded content, like .zip files and they should be on the same domain, is there some byte sequence that will always be present in an swf that we can just blacklist?

Re: Adobe is not willing to fix Flash security issues.

Posted: Sun Dec 06, 2009 8:20 am
by kaisellgren
The only thing that can be found in each SWF file is the three byte sequence 0x46 0x57 0x53 or 0x43 0x57 0x53. The former is seen in compressed SWF files and the ladder is seen in uncompressed SWF files. Other than that, there's no easy way to detect Flash content. All SWF files begin with either of those.

Re: Adobe is not willing to fix Flash security issues.

Posted: Sun Dec 06, 2009 8:30 am
by kaisellgren
I think the best you can do is to check that

Code: Select all

if (preg_match("#^(?:\x{0043}|\x{0046})\x{0057}\x{0053}#",$subject))
equals false.

Re: Adobe is not willing to fix Flash security issues.

Posted: Mon Dec 07, 2009 11:31 am
by josh
1. if (preg_match("#^(?:\x{0043}|\x{0046})\x{0057}\x{0053}#",$subject))

Why not 0x43? (http://php.net/manual/en/language.types.integer.php), I didn't test though. And whats the literal (escaped) \x for? Other then that looks good

Re: Adobe is not willing to fix Flash security issues.

Posted: Sat Dec 12, 2009 1:52 pm
by kaisellgren
A 0x43 would match literal "0x43" in PCRE. To match a specific character, one can use \x{....} where dots denote numbers. If you want to supply the actual character itself into the RegEx clause, sometimes it can create bugs. I always prefer plain string RegExes.

Re: Adobe is not willing to fix Flash security issues.

Posted: Sat Dec 12, 2009 3:53 pm
by josh
Ok so I'm a little slow, so the curly braces with numbers inside them are like saying "match a character who's character code is this number"?

Re: Adobe is not willing to fix Flash security issues.

Posted: Sun Dec 13, 2009 5:36 am
by kaisellgren
\x1f and \x{001f} are the same. However, you can't type \x263a, but you can type \x{263a}. Using curly brackets for 2-character \x syntax is just a preference of mine.