Adobe is not willing to fix Flash security issues.

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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")
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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. :)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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).
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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.
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

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

Post 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"?
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

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

Post 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.
Post Reply