I’m a regular listener to Security Now!, the weekly TWIT podcast about security and privacy, primarily as it relates to being online. Last week’s episode #225 was about the ‘same origin policy’ issue.
What is the Same Origin Policy?
Wikipedia has a thorough write-up on same origin policy here, but I’ll give you the basics. It’s a matter of what files and processes trust each other on web sites. Basically, if files exist on the same domain, they are granted access to the same level of information.
When would that 2nd piece of code not have access to the 1st function’s data? If my 2nd function was stored on a completely separate domain from http://SuperGeekery.com, it wouldn’t have access to the 1st piece of code’s data or functions because of the same origin policy. Smart, right? That’s done because web authors need to be able to keep information from leaking out.
What the Kerfuffle? Part 1 - How the Flash Player works.
The security blog, Foreground Security, has a detailed post called Flash Origin Policy Issues. Basically, Flash has the same basic rules as I described above. If a Flash file lives on the same domain as something else, it has access to all that same information.
This should be fine because, for example, to get something onto my domain at SuperGeekery.com, you’d have to be me, right? And everything I write should be able to trust each other and share with each other. You may wonder if Flash Ads are a problem. Do they have this problem? No, there are Flash ads all over the internet, but since they are almost never hosted on the same server as the domain you’re visiting, they don’t get to access the data the web site’s primary code’s data. Cool.
Oh, there is a problem in the Flash Player though I haven’t mentioned to you yet. The Foreground Security article nails it by pointing out that the Flash files “do not require a .swf extension or special content-type headers to execute.” Hmmm. What mischief could that lead to?
Let’s look at an example. If I have a file that I call “mycat.jpg” on my server that’s not really a JPEG but actually a SWF file (a Flash file) and then I load “mycat.jpg” into this web page the Flash Player will execute it as if it’s a Flash file. That Flash file will have access to that 1st function’s data even though it appears to be a JPEG which shouldn’t have any ability to run any code. There’s a problem here.
What the Kerfuffle? Part 2 - How the most CMS’s work.
I’ve built sites using a variety of content management systems. SuperGeekery is Expression Engine behind the scenes. I love EE, by the way. I’ve also built WordPress sites, TextPattern sites and I’ve built ‘test’ Drupal sites, although none are live to outside users. In all cases, the default place for visitors to upload a file, say for their member profile photo, is on the same domain that the rest of the site is hosted on.
All of them have some sort of upload checking built in. Basically, you can often limit the type of files to allow by checking the extension. (I haven’t tested all of this, but here’s a link to a post about this vulnerability in WordPress version 2.8.5 and lower.) If a file doesn’t end with the proper extension, it doesn’t get onto the server.
That means if someone is able to upload a malicious Flash file to your site ‘disguised’ as a JPEG or GIF, it will be executed by the Flash Player unless you’ve not followed the standard way your CMS will store uploaded content from users. When anyone visits your site and that JPEG is displayed, it is trusted file being served from your domain and it’s a Flash file that has scripting ability. That’s trouble.
What the Kerfuffle? Part 3 - Adobe’s response
The real kerfuffle has been around Adobe’s response to the problem. One way to handle it seems like making all future versions of the Flash player only execute files that have the proper file extension. If it’s not a .swf file, refuse to run it. Adobe says the problem is not that simple though. I don’t know the full story so I have to believe them, but their response was posted in a blog post here. It sort of reads as if they’re saying it’s not their problem:
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. Flash Player will acknowledge that request and present an Open/Save/Cancel dialogue to the user rather than render the content. Developers may also choose to limit uploads to only the types of content that they plan to support. These steps to properly managing user-generated active content uploads may be challenging, but good web security requires vigilance against this type of risk alongside all the other familiar web threats like CSS, CSRF, ...
So Adobe doesn’t really seem to want to fix this problem. It’s the web master’s problem. Interestingly, Foreground Security points out in another post that http://www.adobe.com, http://www.acrobat.com, http://www.photoshop.com, and other Adobe web properties all suffer from letting users upload images that “are not validated fully, and are stored on (and executable from) api.photoshop.com” and their domain policy allows them to be executed. I guess it is hard to do properly.
Adobe, take on this problem.
This is a tough problem for everyone involved. It’s tough for web developers. It’s tough for Adobe. It’s tough for users. Don’t you just wish people wouldn’t do malicous things?
It’s vitally important for Adobe to hit this problem hard and come up with a fix even if they don’t consider themselves as responsible for the problem. The last thing I want to have as the response to this problem is to have users across the web start to uninstall the Flash player on a mass scale because Adobe has chosen to punt on this issue. I and many people I know make our livings relying on Flash as a tool to deliver rich media online. If web users choose to uninstall Flash because they feel threatened by having it on their machine, it threatens the entire ecosystem built around Flash. Adobe, that’s bad for all of us.