Local HTML files can read local directory listings, at least when the directory listings are in the HTML format (which is the default format) rather than the XUL format. Local files have always been able to read other local files with certain extensions (txt, html, bat, ...), but this bug allows them to find other local files without guessing the complete filename. I don't know how much of an increased risk this is. (I think local files shouldn't be able to read other local files, but that's another bug.)
Created attachment 125538 [details] demo: lists files in the same directory This demo reads a list of files from a directory listing in an iframe and outputs the list in a different format. It does not recurse into subfolders or containing folders.
Could ns4 do this? (via a new window rather than an iframe, of course) I guess we could change the definition of 'same origin' for files, but thats likely to break people testing stuff locally before uploading to an http server.
We definitely do not want rogue local files to be able to munge around on disk.
Let me ask the naive question: why is this so bad? I'm not sure I get it. Is it just a belt-n-suspenders thing? Afterall, the only way someone could get tripped up by this is if they were somehow tricked into loading a nasty .html file from the filesystem. Is that really something we should be so concerned about?
Created attachment 130862 [details] 4.x version of demo Works in 4.x. I don't see a hazard here, except that for defense-in-depth, we might want to preclude this (last line of defense if you've been tricked into loading bad content? No, not the last line: there would still be no way to automate sending results back to evil.org without your consent, right?). But not for 1.5, at the last minute. /be
Brendan: There is almost always a way for a script to automate sending informatoin back to evil.org without your consent. In this case, it's as simple as submitting form POSTs. I think I'm going to disclose this on Monday.
(In reply to comment #4) > Let me ask the naive question: why is this so bad? For one thing this affects viewing HTML attachments in Thunderbird -- they're saved to a local tmp file and opened in the browser.
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
fix for this included in the patch for bug 230606. Is there a legitimate need for a mozilla-as-platform app to use file: pages that can navigate directories? Do I need to add a hidden security. pref setting to allow such apps to revert to the current behavior?
Bug 230606 checked into trunk. There's a pref setting to revert the changes if necessary.
We can't afford to fix bug 230606 on the 1.8 branch (too much incompatibility), but we should be able to fix just this aspect. Attack script running from a saved local file would still be able to read specifically known local files (e.g. /etc/passwd) but would not be able to scan your disk looking for interesting stuff. In particular a script would not be able to enumerate the profile tree to find the salted directory name containing all the private Mozilla data (passwords, cookies, Thunderbird POP mail, etc)
Dan needs to fix this completely on the trunk before we can take a branch patch. Punting to the next release.
Given some of the pain caused by changing the file rules on the trunk this is probably not the kind of compatibility change we can safely take on the Firefox 2 branch updates.