Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Flash Vulnerability Found, Adobe Says No Fix Forthcoming

timothy posted more than 4 years ago | from the more-from-the-slums-of-the-internet dept.

Media 355

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


OH NO!!! (4, Funny)

Narcocide (102829) | more than 4 years ago | (#30081360)

Someone has found an issue with Flash?! Say it isn't so...

Re:OH NO!!! (4, Funny)

Monkeedude1212 (1560403) | more than 4 years ago | (#30081396)

I lost count. Can someone help me out again? This time I'll count using Binary on my fingers.

Re:OH NO!!! (1, Redundant)

somersault (912633) | more than 4 years ago | (#30081452)

This time I'll count using Binary on my fingers.

I've never actually considered doing this. Clever. Almost completely useless as I don't have much use for physical counting references, but clever nonetheless!

Why does a login form need CSRF protection? (2, Interesting)

YA_Python_dev (885173) | more than 4 years ago | (#30081890)

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.

Re:Why does a login form need CSRF protection? (3, Insightful)

Lobster Quadrille (965591) | more than 4 years ago | (#30082122)

In this case, it was used to log the user into the attacker's account, which contained the malicious SWF uploaded as an attachment. If the user then logged into gmail (the video uses a registration email to prompt the user to do so), his account would be compromised.

In Gmail's case, there are other privacy consequences to the login CSRF. For example, if the user is logged into an account that I have access to, I can actually view his google search history.

Re:OH NO!!! (1, Offtopic)

bertoelcon (1557907) | more than 4 years ago | (#30081478)

This time I'll count using Binary on my fingers.

That isn't going to go high enough either.

Re:OH NO!!! (0, Offtopic)

selven (1556643) | more than 4 years ago | (#30082146)

Then use three states - open, half-open and closed, getting 59049 possibilities! You can even add the directions the palms are facing (toward you, sideways, away from you), getting up to 531441. Add three positions for how far away your hands are and get the holy grail, 4782969!

Well, this is Flash...

Re:OH NO!!! (5, Funny)

The Archon V2.0 (782634) | more than 4 years ago | (#30082016)

I lost count. Can someone help me out again? This time I'll count using Binary on my fingers.

I tried that, but when I got to 132 vulnerabilities, I felt that was an appropriate enough representation of my opinion and stopped counting.

Re:OH NO!!! (2, Insightful)

elmedico27 (931070) | more than 4 years ago | (#30081696)

No kidding, call it news when Adobe says "Hey, we're actually going to fix some shit this time!"

Client or server? (1)

Dan East (318230) | more than 4 years ago | (#30081418)

"Any site that allows files to be uploaded could be vulnerable"

"Every user with Flash installed is vulnerable"

So who is vulnerable? The server or the client?

Re:Client or server? (3, Informative)

mujadaddy (1238164) | more than 4 years ago | (#30081464)


If I can get a Flash object onto your server, I can execute scripts in the context of your domain.

Only appears to be an issue with servers that accept uploads exactly as TFS says, curiously enough.

Re:Client or server? (1)

smash (1351) | more than 4 years ago | (#30081730)

I read that to mean "i can execute scripts in the security context of your domain on the client's browser". E.G. - you have foosite.com as a site trusted to run active content - some guy can upload a malicious flash object and it will run as if authored/published by the website owner in you browser as a trusted site object. My server for example, has no flash installed, so how is a flash object going to run there?

Allowing users to upload flash is fucking retarded anyway. Its like allowing users to upload any javascript or activeX object they like, and then having your user's browsers execute it.

This isn't a flash problem - its an active content problem - flash just happens to be the most common, easy to abuse active content provider out there that people actually trust to run (but shouldn't).

Re:Client or server? (1)

PIBM (588930) | more than 4 years ago | (#30081770)

If you had RTFA, you`d have noticed that they are giving ways of having flash uploaded on the server while it`s actually checking for other file types, so it`s not as simple as blocking flash file uploads.

Re:Client or server? (4, Informative)

Adrian Lopez (2615) | more than 4 years ago | (#30081908)

It would probably be more accurate to say that websites (not servers) are vulnerable to such an attack. After all, unless I've misread TFA, no code is actually being executed server side. Instead, what's happening is that any SWF's posted to a publicly-accessible location are being served under the server's domain and therefore any scripts in the SWF will execute with rights to access that domain. There's nothing the SWF can do through scripting that a visitor can't do directly, so depending on how you look at it you could say the server itself isn't vulnerable to this, but the website and the clients are.

Re:Client or server? (3, Funny)

jpmorgan (517966) | more than 4 years ago | (#30081472)

I know it's a lot to ask, but you could just RTFA. I guess I'll be the enabler today...

Apparently it's a server-side vulnerability, but this puts users at risk since hijacking trusted websites makes it much easier to socially engineer malware onto people's computers. I.e., if gmail were to be compromised, and you login to gmail and there's a link to download some special gmail-improving program, a lot of people will download and install it, even though it was placed there by a hacker and not Google themselves.

Client. (1, Insightful)

XanC (644172) | more than 4 years ago | (#30081542)

It's not a problem for Web sites, except for their users that run crappy software (ie Flash).

Re:Client or server? (1)

Z34107 (925136) | more than 4 years ago | (#30081594)

Relevant part of the article:

The basic policy for Actionscript is very close to the Javascript same-origin policy: A Flash object can only access content from the domain it originated from. ... The important difference, of course, is that flash objects are not web pages. A flash object does not need to be injected into a web page to execute- simply loading the content is enough. Let's consider the implications of this policy for a moment: If I can get a Flash object onto your server, I can execute scripts in the context of your domain.

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.

Re:Client or server? (2, Interesting)

theTerribleRobbo (661592) | more than 4 years ago | (#30081826)

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? :-)

Re:Client or server? (4, Informative)

Anonymous Coward | more than 4 years ago | (#30081884)

Flash files can also be loaded by embedding them in an HTML page with attributes that say "content-type='application-x-shockwave-flash'" or something like that, regardless of extension or the content-type header given by the server. The server may think it's a zip file, but your browser can still be convinced to run it as flash.

So, I drop a malicious .docx on vulnerable site, create my own web page that embeds the object, and get you to visit that page. presto, you're pwned.

the article is bullshit. (1, Flamebait)

tomhudson (43916) | more than 4 years ago | (#30081622)

Example from the article:

"All they need to do is create a malicious Flash object, and upload it to the [Web] server."

He used the example of a company that lets users upload content to a message forum to explain the process. "If the user forum lets people upload an image for their avatar, someone could upload a malicious Flash file that looks like an avatar image," Bailey said. "Anyone who then views that avatar would be vulnerable to attack."

Since when are you going to allow someone to upload an swf for an avatar. It's going to get creamed when you resize it via php anyway.

This is the same "vulnerability" you'd have by allowing people to upload php code, or perl code, or javascript, to your server and you sending it out without doing ANY validation.

In other words, it's not a vulnerability, it's a symptom of totally bonehead design and someone looking for page hits.

What next - "All Windows Versions of Apache Vulnerable To .EXE Exploit" - where they'll say that if you allow people to upload .exe files to your site and blindly execute them, BAD THINGS (TM) will happen?

This belongs in idle.slashdot.org - it's not news, it's so bad it's not even wrong.

Re:the article is bullshit. (5, Informative)

Anonymous Coward | more than 4 years ago | (#30081686)

Didn't really read the article, did you?

Uploading the swf as an avatar is just the beginning. You can also overload ZIP files, which also includes .docx, making perfectly legal documents that also are executable flash objects. Also, many server-side validation libraries apparently will also not catch properly malformed (if such a thing is possible) pdfs, mp3s, etc.

Ironically, all that email antivirus that require you to zip up your files does no good here... a overloaded zip file can be used to compromise webmail clients (like gmail, as in the example).

Flash's security policy is severely broken. I'd call this a pretty big deal.

Re:the article is bullshit. (1)

afidel (530433) | more than 4 years ago | (#30081778)

gmail doesn't allow zip attachments for this and so many other reasons.

Re:the article is bullshit. (0)

Anonymous Coward | more than 4 years ago | (#30081832)

gmail doesn't allow zip attachments for this and so many other reasons.

not so gmail accepts and sends .zip it just does not automatically load files and requires user input to download the attachment!

Re:the article is bullshit. (0)

Anonymous Coward | more than 4 years ago | (#30081870)

Does that actually mean the zip or docx would be executed in your browser or on the server itself?

Re:the article is bullshit. (5, Informative)

Enleth (947766) | more than 4 years ago | (#30081804)

You, sir, are entitled to the Arrogant Uninformed Derogatory Comment of The Day Award. Here's why, a quote from TFA:

It gets worse. Uploading a SWF with a .jpg extension, or a forged content-type header will get you a long way, but what if you can upload perfectly valid files with malicious content? Remember GIFAR? The basic premise is this: Overload a GIF file with a JAR archive. Specifically, the ZIP file format can be appended to any binary file and still be valid. The GIF format, in turn, can have any binary file appended to it. The JAR archive, being essentially a ZIP file, can be combined with a GIF image to create a a file that is both a valid image and a perfectly valid JAR archive. While SWF files cannot be appended to other formats, the inverse of the GIFAR exploit works- any file format in the ZIP family can have a SWF file prepended to it. This means that ZIP archives, self-extracting executables, Microsoft Office Open XML documents, XPI files, and, if you want to be ridiculous, even JAR files can all be crafted to contain executable SWFs. Additionally, if you don't care too much about compliance with standards (and what attacker does?), many server-side content validation libraries will also allow malformed PDFs, MP3s, and other media formats, so long as you are careful not to mangle them too much. This content overloading technique has countless variations, but the end result is always the same: no matter how good your validation routines, you simply cannot trust user-supplied content.

Short of rewriting everything that has anything to do with several popular formats, you're out of luck.

How, you do ask, is such a prepared file going to be uploaded? A worm that intercepts uploads in the browser, for example. I was able to come up with this in two minuttes, I'm sure that any self-respecting blackhat hacker will as well.

Re:the article is bullshit. (0)

Anonymous Coward | more than 4 years ago | (#30081812)

Wait, what?

Maybe the web site wants to compromise its users. Then what? You know, like a hacked or malicious web site.

Re:Client or server? (4, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#30081626)

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? (3, Insightful)

Ash Vince (602485) | more than 4 years ago | (#30081926)

I have just read the article. The problem seems to be with sites who allow flash object to be uploaded, then served to other people using the site. Of course, this is just stupid anyway. If I allow you to upload a flash object to my site, I should sanitise it before I allow my server to give it to anyone. The example they give is an animated avatar, but that is poor example as they should be restricted to animated gifs anyway.

This is just more FUD. ActionScript is a very powerful language, and so server admins should only allow flash files they trust to be served up form websites they maintain. To my mind that is just common sense. The only alternative would be for Adobe to cripple Flash beyond belief so it was only useful for a small percentage of what it is currently used for.

Re:Client or server? (1)

ThePengwin (934031) | more than 4 years ago | (#30082190)

+1 to that.

This is a huge amount of FUD. i believe newgrounds struck this problem back in early days of flash 6? They host all their flash on a foreign server to the actual newgrounds server to combat this. i dunno how successful their methods are, but every time i went to newgrounds, i didnt see it hacked.

Its an old bug, but its a dam commonsence issue. Youre uploading someone elses data, you should be carefull.

iPhone (5, Funny)

Anonymous Coward | more than 4 years ago | (#30081424)

I'm very angry that I can't use this vulnerability on my iPhone.

Re:iPhone (1)

FunkyRider (1128099) | more than 4 years ago | (#30081494)

Or your iphone is more vulnerable to throw away damage, or drop in water damage, or drop in toilet damage or stolen damage or whatever damage out there. quick, hide it!

FOSS flash plugins? (2, Interesting)

Tubal-Cain (1289912) | more than 4 years ago | (#30081428)

How good it Gnash these days?

Re:FOSS flash plugins? (-1)

Anonymous Coward | more than 4 years ago | (#30081776)

Recently podcasted

Re:FOSS flash plugins? (0)

Anonymous Coward | more than 4 years ago | (#30081994)

Nothing to do with anything. This is a problem with the specification. Either Gnash can run flash or it can't (this is more a server-side issue than client-side).

Foreign code (1)

cbreak (1575875) | more than 4 years ago | (#30081458)

It's always risky to execute code downloaded from the Web, be it JavaScript, Flash content, Java Code or ActiveX. NoScript can help mitigate that risk by offering WhiteListing in Firefox. It might not be too convenient, but security seems to be worth it to me.

yeah, but it is hidden in non-code Re:Foreign code (1)

j-stroy (640921) | more than 4 years ago | (#30081688)

TFA points out that the flash code can be pre-pended to the entire .zip family, and more.

It is executable code that doesn't look like it is code. That in a nutshell is the problem, aside from the pt of origin of that code being obfuscated.

Another reason to browse inside a VM. btw, anyone know if any browsers can internally handle parallel authentications (ie a virtual browser)?

Broken security model (3, Insightful)

Inf0phreak (627499) | more than 4 years ago | (#30081500)

Adobe's answer is just the greatest kind of cop out. "Websites just need to make sure to check all uploaded material". But that's obviously never going to happen -- fuck they can't even do that themselves! End users can't rely on every single website out there to be vigilant at all times and never accept an upload of a flash file.

If this is really unfixable in the flash plugin, then maybe it's because your security model is fucking broken and it's time to throw this piece of shit away?

Re:Broken security model (4, Insightful)

smash (1351) | more than 4 years ago | (#30081774)

Its not adobe's problem to fix. If you allow users to upload executable content to your web-server, and then have your web-app present that un-sanitized executable content to other users, you're a fucking idiot.

Re:Broken security model (0)

geekoid (135745) | more than 4 years ago | (#30081900)

It sure is. It's broken and needs to be fixed. The server just holds an infected item, like say a Gif. The client runs that because it's coming from a 'safe' domain. As you probably have no clue about, Javascript (now) only runs from the same domain. The actionscript is BROKEN, just like Java script was years ago.

Adobe should be held accountable.

Re:Broken security model (1)

smash (1351) | more than 4 years ago | (#30082008)

This is not CSS. This is the same as allowing people to upload any javascript to your site and the embedding it in your webpage for users to run. If it was an EXE file, a perl script, a java applet or whatever - it would have the same result. Its not a flash problem. Its a web-app problem.

Re:Broken security model (1)

clockwise_music (594832) | more than 4 years ago | (#30082024)

Adobe should not be held accountable. It's not their problem. If I write a program in c# to delete your hard disk, create the EXE, upload it to my website, you download and run it, what, it's Microsoft's fault? What if I write the program in Java and send you a link to a JAR file? Going to sue Sun?

Smash is correct, if you allow users to upload executable content to your website, you're a knob.

Re:Broken security model (4, Insightful)

Lobster Quadrille (965591) | more than 4 years ago | (#30082186)

If you can write an SWF that can be executed to compromise a website, despite the fact that it looks like, acts like, and in fact is a valid MS Word document, I'd call that a problem.

Your JAR example is actually a pretty good one... as TFA mentions, a similar attack with JAR files that looked like GIFs came out in 2008. Sun fixed their plugin [xs-sniper.com].

Re:Broken security model (1)

seanalltogether (1071602) | more than 4 years ago | (#30081892)

I'm still not exactly clear on the vulnerability itself, all I'm reading is "If I get a swf on your server, when it's executed in the browser it will have originated form that server" What exactly is the vulnerability there? Isn't this how it's supposed to work? Don't you want scripts executing on the domain they load from? From the article "If I can get a Flash object onto your server, I can execute scripts in the context of your domain. This is a frighteningly Bad Thing." Is he suggesting Flash should execute in a black hole or something like that? That would make no sense.

Re:Broken security model (-1)

Anonymous Coward | more than 4 years ago | (#30082094)

In a brief moment of sanity, I actually read (some of) the article. The vulnerability here is no different than any other cross site scripting exploit. I don't see an easy way to fix this in flash, or in javascript, or in anything. Allowing someone to run arbitrary code on your site is going to cause problems.

I hate flash as much as the next guy, but this is no different than being able to inject malicious javascript onto a poorly secured web site.

Frankly, I'm pretty amazed this is being heralded as some new vulnerability, and even more amazed 'security researches' get paid to 'discover' this. Can I claim my reward for discovering that letting anyone run whatever code they want on my computer is a security vulnerability?

Re:Broken security model (1, Informative)

Eil (82413) | more than 4 years ago | (#30082162)

Adobe's answer is just the greatest kind of cop out. "Websites just need to make sure to check all uploaded material".

Just because you have a seething hated of Adobe and didn't bother to RTFM doesn't mean Adobe is wrong.

I'm no security expert, but the issue seems to boil down to:

1) It might be considered a security flaw by some, but it's not a bug and it's not even unique to Flash. Everything is working as designed.
2) Yes, in 2009, website programmers still have to throughly validate and/or sanitize all data coming from untrusted sources, no exceptions. Even if it's hard.

Bottom line: This is not news. Some random security researcher took a known caveat in a fully-documented system and tried to sensationalize it, that's all.

Simple solution (1)

zcv (1108935) | more than 4 years ago | (#30082198)

Seems like the simple solution is to serve all non-trusted content from a separate hostname. For example, serve avatars or uploaded files from usercontent.example.com.

As far as I can tell this would stop the attack nicely. The malicious SWF would execute in the context of a domain you don't care about.

Warning - 2nd link points to a FLASH AD (5, Funny)

tomhudson (43916) | more than 4 years ago | (#30081534)

Kind of ironic that an article that warns about flash vulnerabilities as:

  1. A flash interstitial ad
  2. A page loaded with flash

Oh, wait - it's ComputerWorld. Sorry, I had my expectations too high.

Say it ain't so o o o (1, Interesting)

socz (1057222) | more than 4 years ago | (#30081540)

While I love flash, because I've been working with it for so many years (go ActionScript!) I have seen many things it can do. Unfortunately, most people don't take it seriously. While the issue's only come up after a vulnerability has been used, I've been telling people about the awesome power of AS. Because flash allows for so much, I honestly don't know how you can lock it down. But on the plus side, I don't use flash/AS in a conventional manner, so most of the ways I would be able to (ab)use it is not really in reach for most people because they wouldn't even think of the possibilities that flash can do! So security through obscurity I guess would be the best way to say it.

also risk of d/l .bat / .pl ! ban mimetypes now! (0)

Anonymous Coward | more than 4 years ago | (#30081550)


NEWS FLASH: Web sites need to screen uploads (3, Insightful)

Anonymous Coward | more than 4 years ago | (#30081630)

This is ridiculous. If a web site lets you upload a JavaScript file and then serves it back to you as part of a request, it would be crazy. All that has happened here is that people have worked out that doing the same thing with a Flash file is equally bad.

Of course there's no easy fix apart from web sites being sensible in what they upload -- just like anyone with a clue doesn't let users submit comments with tags in them.

Re:NEWS FLASH: Web sites need to screen uploads (1)

John Whitley (6067) | more than 4 years ago | (#30081694)

Actually, if you'd bothered to RTFA (I know, I know) the author gives concrete examples of where the SWF payload can be embedded in a swath of other media types and still successfully be used as an attack vector. It's a more complex problem than just serving user-generated SWF files.

Re:NEWS FLASH: Web sites need to screen uploads (0)

Anonymous Coward | more than 4 years ago | (#30081756)

whence mimetypes, idiot!

rm -rf ~

why is your $HOME still there?

Re:NEWS FLASH: Web sites need to screen uploads (0)

Anonymous Coward | more than 4 years ago | (#30081880)

From TFA, which I did read:

"if I can convince a server to serve up a file on my behalf, I can use that file to attack the server" -- this is not news.

They then go on to talk about GIFAR, but who lets a user upload anything and then embed it as if it were a Flash object (even if it looks like a GIF/ZIP/whatever)? You still need to be letting users embed content on your site that is processed by a plugin that provides an executable environment, which clearly is a bad idea.

Re:NEWS FLASH: Web sites need to screen uploads (0)

Anonymous Coward | more than 4 years ago | (#30082048)

The embedding need not happen on the victim site. That can happen anywhere. Once uploaded, the embedded object still thinks it's living on the victim site.

Re:NEWS FLASH: Web sites need to screen uploads (1)

thePowerOfGrayskull (905905) | more than 4 years ago | (#30081934)

But this isn't just SWF payload - any kind of payload can be embedded in the same way, and carry the same risks. In addition, unless I'm missing something, the flash content is limited to accessing things owned by that domain, and stored on the client computer by that domain (maybe even within flash itself? not sure?) . Which means - unless a server is particularly stupid about what it keeps on teh client - that the damage it can do is fairly limited, doesn't it?

Re:NEWS FLASH: Web sites need to screen uploads (0)

Anonymous Coward | more than 4 years ago | (#30081788)

A javascript file won't execute in the context of the domain that it's served from- it executes in the context of an html page. If you upload an HTML page, your example stands.

However, flash files don't need a .swf extension to execute, and the attacker can place executable swfs in many valid file formats. Uploading a malicious SWF is a lot easier than a malicious HTML page.

The vulnerability (5, Insightful)

Stan Vassilev (939229) | more than 4 years ago | (#30081666)

The vulnerability is not new at all. It's been known for probably coupe of years now. If a site accepts file uploads, in some cases even if simply displays user submitted data like *comments*, a malicious user may upload content that contains a policy XML snippet (the resulting file doesn't have to start with the snippet as well due to some specific of how the content is parsed). Flash can be pointed to that snippet and it will blindly accept it as the security policy for that domain/folder.

The security implications are that even if the site doesn't use Flash itself, a user opening a third party site with Flash could read from the site with the faulty policy.

Say Facebook is vulnerable to this problem (likely it is), and you're logged in. Opening another site will allow Flash on that third party site to read your Facebook details, as it has access to anything you do.

This problem was introduced sometimes Flash 7-8 (I forget) when an ability was added for Flash to read policy files from a custom URL. Prios to that, the only valid location was www.example.com/crossdomain.xml, which is, of course far simpler to lock down and secure. The bottom line is, they can fix this in a number of ways, but not in a backwards compatible manner. For the moment they simply seems to have their bets that people don't care enough about this problem to warrant the effort.


Anonymous Coward | more than 4 years ago | (#30081682)

It's Friday the 13th, children.

The one and only cat named Hercules

So Adobe says... (0, Insightful)

Anonymous Coward | more than 4 years ago | (#30081790)

"Oops! We found security issues with our software and we plan to do absolute dick about it. The problem is now on everyone else's hands." *shit eating grin*

If Adobe doesn't pick uo it's pace (1)

geekoid (135745) | more than 4 years ago | (#30081856)

they will be devoured by silverlight.

Silverlight? (1)

argent (18001) | more than 4 years ago | (#30082058)

What origin policy does Silverlight use?

This isn't specific to Flash, it applies to ANY active content that automatically runs.

What the... (3, Insightful)

thePowerOfGrayskull (905905) | more than 4 years ago | (#30081910)

Instead, Arkin added, Adobe has tried to get the word out to Web application designers and site administrators about the danger of allowing users to upload content. "Sites should not allow user uploads to a trusted domain," Arkin argued. "The real issue here is that developers should be cautious about using techniques that can be misused maliciously. In general, this is a general challenge in managing active content."

Arkin is from Adobe. And he's seriously saying that in order to "fix" this, web site owners must simply disallow users from uploading files. Period. (Not through Flash, but all file uploading .) That's a spectacular answer.

On the other hand... I kind of understand where he's comign from. If you let your users upload content unchecked, and serve that content up, you are potentially giving some level of access to client machines. In this case, it seems somewhat minimal? I'm not familiar with actionscript, but you don't get free reign to the user's machien do you? Only content specifically store under the domain of the owning server, in the context of Flash?

*raises hand* (1)

Anonymous Coward | more than 4 years ago | (#30081914)

OK, can we get rid of Flash now?

No? Alright then, just asking.

Easy solution... (1)

argent (18001) | more than 4 years ago | (#30081918)

Implement flashblock in the flash plugin itself, so that users have to explicitly request flash content be run, even if it's packaged in a way that manages to slip by flashblock.

Uploading a swf with a jpg extension? (3, Interesting)

FsG (648587) | more than 4 years ago | (#30081958)

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:Uploading a swf with a jpg extension? (1)

kipin (981566) | more than 4 years ago | (#30082064)

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.

I don't know if gif/jpeg rules are the same. But you can upload a GIF as a JPEG, and it will still render as a GIF, even though the file is itself JPEG. In fact, even some free image hosting sites exploit this "vulnerability". If you upload a GIF to tinypic, it will rename the file and place the .jpg extension after it.

Firefox and IE seem to have no problem deciphering this so I doubt it is something that the browsers specifically disallow.

Re:Uploading a swf with a jpg extension? (1)

FsG (648587) | more than 4 years ago | (#30082138)

Correct.. browsers use the MIME type sent by the server, rather than the file extension, to decide which parser to invoke.

So if you have an upload facility, all you have to do is be sure that you're using the jpeg MIME type for jpegs and the gif MIME types for gifs.. it shouldn't matter if the actual bits of the file are an image, an SWF, or even an EXE.. the browser should be invoking the handler that corresponds to the MIME type, not examining the bits of the file to try to guess what it is.

It really looks like the article is overstating things when it claims that forged files can be used with this flash vulnerability.

Re:Uploading a swf with a jpg extension? (3, Informative)

Lobster Quadrille (965591) | more than 4 years ago | (#30082084)

You'd think so, but you'd be wrong. Embedded content can specify the content-type in HTML (in order for the browser to know what plugin to use to load that content), and Flash trusts that declaration, not the content-type supplied by the server. A properly-designed plugin should trust the server, not the HTML that calls it.

Re:Uploading a swf with a jpg extension? (1)

QuoteMstr (55051) | more than 4 years ago | (#30082214)

Configuring a web server to send the correct content-type header would take all of five minutes. Clearly, Adobe cares more about saving five minutes of web developer time than about preventing identity theft for millions.

I'm not kidding. Web developer pay Adobe. Flash users don't.

Bad Adobe! (2, Insightful)

onyxruby (118189) | more than 4 years ago | (#30082082)

This is the same kind of logic Microsoft used with security in the 9.x kernel. Putting the impetus on third parties to behave and not take advantage of this is nuts! Are they not the least bit familiar with malware or anything else of the like? Bad Adobe, bad!

Let the lawyers fix this (0)

Anonymous Coward | more than 4 years ago | (#30082118)

A few hungry lawyers can get this problem fixed in a week. Just get a few injured parties and they will take care of the rest. While they are at it, they can fix the problems with the entire internet protocol suite that allows any application on any box to send and receive any data from any IP with zero traceability or accountability, all for free. This shit has got to end and the only way it will is if the consumers of this 1970s archaic crap we are all swallowing start to complain (i.e., lose money and time).

Flash security has always frightened me (4, Insightful)

QuoteMstr (55051) | more than 4 years ago | (#30082144)

I've been worried about Flash security for a long time now. I'd like to point out three features of Flash that bother me.

First, Flash allows a web application to paste data to the clipboard [jeffothy.com] even if the browser itself forbids this. Of the major browsers, only IE allows applications to directly set the clipboard content.

Second, Flash has an XMLHttpRequest equivalent [xml.com] with a lax security policy [adobe.com]. Cross-domain retrieval is controlled by an XML control file listing permissible origins.

Finally, Flash has its own cookie system. These Flash cookies are hidden from the user, and require special tools [fightidentitytheft.com] to remove.

These features are secure in themselves, but are enablers: they give attackers the means to exploit other vulnerabilities.

Unfortunately, this cavalier attitude fits Adobe's business model. Lax security is as much a feature of Flash as its vector graphics. Flash allows web developers "get shit done" with no regard for the security of the web ecosystem as a whole. Web developers then come to rely on Flash, which increases the adoption of Flash Player among users, which in turn increases the value of Adobe's authoring tools. Being insecure is lucrative, up to the point that the vulnerabilities become so egregious that users disable Flash.

On the other hand, browser vendors seem to take a mostly-conservative approach to security (don't laugh yet): consider XMLHttpRequest: sure, its same-origin restriction on the target URL is inconvenient, and the restriction might have been loosened [w3.org] while remaining secure. But this same prudent restriction has also prevented many attacks. Browser vendors have the right incentives because users have a realistic choice of browsers. Flash is an all-or-nothing affair.

I wish I had an answer. Hopefully, HTML 5 will become widely supported enough that websites won't feel compelled to use Flash for graphics and storage, and eventually Flash's market penetration will sink below the point that web developers can consider it a viable way to circumvent browser security.

So is there an "immune system" file scanner? (1)

presidenteloco (659168) | more than 4 years ago | (#30082174)

That can look for a signature in the uploaded file bytes that means the file is a swf? or a swf-readable policy xml file?

Anyone know of code that does that? Maybe Adobe would be kind enough to release some Java code and python
code for detecting their own files.

Oh no! (0)

Solokron (198043) | more than 4 years ago | (#30082218)

Oh no, a hacker saw my obligatory wacky animated avatar targeting the monthly pop culture event/person/thing/etc/insert/cmdr_taco/bad news everyone/virgin nerd/all your base belongs to us.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account