Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc.... 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Security of allowing file uploads.
Posted by: fjw
Date: November 05, 2008 07:47PM

I have a web application which allows file uploads from untrusted users (think email attachments).

The application stores a session identifier in a cookie.

What I need to know is how do I prevent these file uploads from being executed (as Flash, or Java for instance) from external sites and thus allowing external sites to gain access to cookies set for my domain?

1. Attacker signs up at my site and uploads SWF or Java file (perhaps with .jpg extension or whatever) to my app.
2. Attacker embeds this in an <object> tag on their own site (attack site).
3. Unsuspecting member of my site with a valid cookie stumbles upon the attack site.

Q1. Does the attack site gain access to the unsuspecting member's valid cookie? The server with the web application has no crossdomain.xml file or anything, though the attack site might.

Q2. How can I prevent browsers and plugins from executing files that I serve? Serving it up with a different media type (ie, application/octet-stream or image/jpeg) does not help me; Flash plugin still execute SWF files even if served with different media types and extensions.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 05, 2008 09:13PM

This is precisely the kind of attack that I need to know how to prevent:

http://www.infoworld.com/article/08/08/01/A_photo_that_can_steal_your_online_credentials_1.html

In that attack, user uploads a JAR file that appears to be a harmless GIF file and is served as a GIF. But Java applets will nonetheless run it as a JAR.

Let's say that I want people to be able to upload JAR or SWF files legitimately; how can I serve them so that they can be downloaded as "attachments" but won't run in any Java/Flash plugin?

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: thrill
Date: November 05, 2008 09:34PM

Back about 10 years ago ISPs wanted to provide shell access to all it's users. Unfortunately, with the buffer overflow affecting countless of systems, they figured out the best option was to not allow shell access..

With the shown ability of graphic files to include a payload your options are pretty low, unless of course you can create some sort of program that can not only scan, but also clean files that include payloads..

Another option would also be to use a program such as ImageMagick to convert the files from whatever they are, to other 'allowed' formats (.png).. but I am not sure the image conversion would work well enough at removing the bad code.

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 05, 2008 10:51PM

> With the shown ability of graphic files to include
> a payload your options are pretty low, unless of
> course you can create some sort of program that
> can not only scan, but also clean files that
> include payloads..

Scanning for the ZIP/JAR signature is not too much of a problem for me - I already scan file types, although currently only at the start of a file (I'd need to scan the whole file to detect this sort of issue).

However, that covers detection of a harmful file only. That brings me to a situation where users are simply blocked from sharing certain files, which is not what I want - I'd prefer it if users were able to legitimately upload and share JAR files if they want to - for instance if they are Java developers - I just want to serve these in such a way that they can only be downloaded by the browser and are un-openable by the Java runtime - ie by an <applet> tag on any site.

How do services like Gmail get around this? Do they disallow JAR files as attachments? If not, how do they serve the JAR files in such a way that attacking sites can't include the specific URLs for them in <applet> or <object> calls and gain access to people's Gmail accounts?



Edited 1 time(s). Last edit at 11/05/2008 10:52PM by fjw.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: thrill
Date: November 05, 2008 11:39PM

Ahh.. that's a little better description of what you need.. but I may not be the right person to help you with that specific problem..

Maybe someone who is more familiar with apache mime types might be able to provide you a better answer. Actually.. are you running apache? :)

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 06, 2008 12:19AM

I am developing a custom php app. I have tested serving a jar file with various content-type headers intended to tell browsers it isn't a java file, such as application/octet-stream, even image/gif , but the JVM ignores mine types and will always execute it from the applet tag - presumably using the privileges of my domain.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: tx
Date: November 06, 2008 12:48AM

@fjw: I will investigate this issues as it interests me, but I do wonder, is there really a benefit to allowing users to share jar files? Would not source packages do just as well?

-tx @ lowtech-labs.org

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: Anonymous User
Date: November 06, 2008 02:57AM

Basically you have to check the file source and make sure that there's nothing that can harm the user agent. Header settings only make kind of sense when the user can guess the URL of the uploaded file. But what if you file is being included by another file?

http://maliciousmarkup.blogspot.com/2008/11/why-use-expression-when-theres-htc.html
http://maliciousmarkup.blogspot.com/2008/11/foucs-and-obfuscated-binding-of-death.html

Make sure your web server is configured correctly too - and really delivers the files being uploaded with the mime type they're supposed to have. Image conversion helps in some cases - but not all. For the JAR issue you could utilize unzip() to test for the validity of the files contents - but that again brings own risks...

Uploads are difficult...

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 06, 2008 05:07AM

tx Wrote:
-------------------------------------------------------
> @fjw: I will investigate this issues as it
> interests me, but I do wonder, is there really a
> benefit to allowing users to share jar files?
> Would not source packages do just as well?

For my application, I would like to provide the general ability for users to upload whatever file they want as an 'attachment' to their page. I would prefer not to disable some particular types of files - such as JAR, CLASS, ZIP etc - because it would be giving in to a software problem. The user just cares that they can upload the files they want, and who knows, a Java programmer may want to use my application.

I have been looking in to how Gmail gets around this problem, and they DO allow ordinary JAR files as attachments, and from what I can tell, they appear to include secret tokens in the query string of any URL links to the attachment.

They also get around it because in Gmail, only the recipient can access any attachments (or know its URL). So in this type of attack, the recipient is the attacker, and if he grabs the URL and puts it into an applet tag on their own site, it will still not load for anyone - even logged in users - because they will not be logged in as the recipient of that email.

Which leaves me still wondering how someone wanting a more widespread sharing feature could implement it safely without disallowing some file types.

MediaWiki, for example, scan the file type and simply do not allow you to upload some file types as attachments. This would be the obvious fallback strategy.

Another solution may be to do what I have seen some mail servers do - compress the file into a ZIP file. A JAR inside another ZIP file shouldn't be executable by an applet tag on anybody's site, and the user can still download it, though they have to unzip it.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 06, 2008 06:40PM

I think I've found a solution:


- Allow all uploads.

- Only allow downloads using the POST method, ie as the result of clicking a button. AFAIK an applet tag on another site can never use the POST method to execute an applet.

- Exceptions can be made where the file has been scanned and identified as harmless.

The downside to this is that download managers won't be able to download the file, and as far as I can tell there would be no way to allow resuming and partial downloads of the file.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: kuza55
Date: November 06, 2008 11:03PM

fjw Wrote:
-------------------------------------------------------
> How do services like Gmail get around this? Do
> they disallow JAR files as attachments? If not,
> how do they serve the JAR files in such a way that
> attacking sites can't include the specific URLs
> for them in or calls and gain access to people's
> Gmail accounts?

They think they solved the problem by having a unique id for every email message and rely on the attacker not being able to guess the id; my exploits say this didn't work :p

Having said that, Flash has now (Flash 10 & 9.0.151.0) started respecting both Content-Type and Content-Disposition: attachment headers (some bastard academics got it patched, I am developing a serious grudge against those guys, since they keep killing my GMail bugs), so that should no longer really be a threat to you.

I've heard a Java patch is in the works, but that's only 2nd or 3rd hand.

Your best option to protect yourself is to do what Hotmail does and only serve attachments from an IP address (this is the approach Gmail takes when serving cached content, since scrubbing whole html files of active script is very, very hard) and use a random Token in the URL to make sure they are still only viewable by who you want them to be viewable by.

Also, scanning files to determine if they're safe is a doomed solution. Blacklists anyone?

----------------------------------------------------------
Don't forget our IRC: irc://irc.irchighway.net/#slackers
[kuza55.blogspot.com]

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: Kyo
Date: November 21, 2008 10:15AM

yep, your best bet is using a different domain/an IP address for serving the content. Even if you manage to somehow filter out every known exploit, someone will eventually find something new. Kuza said it, pretty much

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 25, 2008 10:19PM

kuza55 thanks for your help. It's unfortunate that the content-type of files is ignored when they are called from applets/object/embed, or I could have got around this simply by specifying a content type of application/octet-stream (or a content-disposition of attachment, though that is ignored in even more situations).

In an ideal world, no JAR file served as application/octet-stream would be executed by a client, cross-domain or not.

It looks like the best solution is to use a different hostname with no common "two dot" root, or like Hotmail, use the IP address only for serving attachments and the hostname only for everything else (including sessions).

The problem is that it isn't portable. For instance in a typical web application - take MediaWiki for example (as used by WikiPedia). WikiPedia serves all uploaded content from a separate unrelated hostname in order to solve these issues. However, a default install of MediaWiki doesn't do this, because in order to be portable the default install doesn't require more than one unrelated hostname, or a dedicated IP. It serves everything from the same hostname.

An alternative solution might be similar to the one used to solve "login CSRF" - make sure that the attachment is only served as the result of a POST method containing a token which is related somehow to the token given in a cookie. This will solve the cross-site aspect, where another site includes your attachments in applet or object tags. Still, if IE will persist in treating application/octet-stream that looks like HTML as HTML, then users may still be able to "view" it in their browser and hence be owned by script in it that was never intended to be run.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: Kyo
Date: November 26, 2008 09:10AM

Normally, subdomains would be enough. However, a bug in IE allows you to get access to www.*.* from subdomain.*.*

As how I said, if you don't want to use IPs, you'd have to get a second domain name. None of these solutions, including subdomains are really portable, though.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 27, 2008 06:36AM

On a slightly different note, another observation about the GIFAR problem: a ZIP archive may contain arbitrary data not only before the start of the first file, but also at the end of the file, in the form of a "ZIP file comment".

My testing with any data in this ZIP file comment lead to the JAR still being executed by the JRE, therefore it is possible not only to have a JAR at the end of a file and GIF at the start, but for the JAR to be completely contained within another file.

The possibilities are endless - you can essentially have any old PDF, image, whatever and put the JAR information completely inside it, in a comment field, in free space reserved by the file format, or just as 'broken' image data in a frame of the image.

The implication is that anyone allowing any upload file type MUST scan the entire file (or, in the case of the JRE, at least the last 65536 bytes) for what may be a ZIP central directory header. Simply opening the image and saving it as a fresh image may not be enough, as if the image data ends up the same (ie the same colour pixels in the same locations), ZIP data encoded as the actual visible image data may still be valid.

(of course, serving this from a completely different domain makes this a non-issue, but for the billions of people who use standard installs of web applications this is an issue. Fixing this in web applications is not the answer, because it is very difficult to do, and something as simple as patching the plugin so it obeys content-type would be easy and would give users the ability to protect themselves even for existing web applications)



Edited 1 time(s). Last edit at 11/27/2008 06:40AM by fjw.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: lightos
Date: November 28, 2008 11:31PM

Hey everyone,

I was wondering if anyone here has successfully tried out the gifar?
I tried to create one using "cat image.gif java.jar >gifar.gif", but it didn't completely work for me.
The applet fails to load because it says the .class file can't be located,
it will only work when I put the .class file in the same folder as the gifar.gif or change the extension to a .jar.

The server log looks like this:
"GET /gifar/gifar2.gif HTTP/1.1" 200
"GET /gifar/gifar.class HTTP/1.1" 404
"GET /gifar/gifar/class.class HTTP/1.1" 404

I tried it on Firefox, IE and Opera on Ubuntu 8.10 & Windows XP SP3,
also verified that all the correct files were in place.
Any ideas?

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: fjw
Date: November 29, 2008 11:19AM

I successfully used a JPG+JAR running from Firefox, created with the command:
copy /b me.jpg + clock.jar gifar.jpg

Edit: looking at your post above, it looks like the JRE is searching for a main class file named "gifar.class", which I am assuming isn't the main class file you wanted.

Try specifying the class when you call the applet. I used something like this:

<applet code="clock.class" archive="gifar.jpg" width=300 height=200></applet>



Edited 1 time(s). Last edit at 11/29/2008 11:22AM by fjw.

Options: ReplyQuote
Re: Security of allowing file uploads.
Posted by: Inferno
Date: February 01, 2009 04:27PM

Hi Fjw,

In order to prevent uploads of jars hidden inside images, please take a look at my article at http://securethoughts.com/2009/01/easy-server-side-fix-for-the-gifar-security-issue/

-Inferno

Options: ReplyQuote


Sorry, only registered users may post in this forum.