Closed Bug 209234 Opened 19 years ago Closed 15 years ago

local files can read directory listings


(Core :: Security, defect)

Windows XP
Not set





(Reporter: jruderman, Assigned: dveditz)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: csectype-disclosure, Whiteboard: [sg:want P1])


(2 files)

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.)
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.
Flags: blocking1.5?
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?
Attached file 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 without your consent, right?).

But not for 1.5, at the last minute.

Flags: blocking1.5? → blocking1.5-
Brendan: There is almost always a way for a script to automate sending
informatoin back to without your consent.  In this case, it's as simple
as submitting form POSTs.

I think I'm going to disclose this on Monday.
Assignee: security-bugs → dveditz
QA Contact: carosendahl → toolkit
(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.
Group: security
Whiteboard: [sg:want]
Blocks: 318775
Whiteboard: [sg:want] → [sg:want P1]
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9alpha5
Target Milestone: mozilla1.9alpha5 → mozilla1.9alpha6
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
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?
Depends on: 230606
Bug 230606 checked into trunk. There's a pref setting to revert the changes if necessary.
Closed: 15 years ago
Resolution: --- → FIXED
Depends on: 395625
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)
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Flags: blocking1.8.1.12? → blocking1.8.1.12+
Flags: blocking1.8.1.12+ → blocking1.8.1.13+
Whiteboard: [sg:want P1] → [sg:want P1][needs branch patch]
Dan needs to fix this completely on the trunk before we can take a branch patch. Punting to the next release.
Flags: blocking1.8.1.14+
Flags: blocking1.8.1.13-
Flags: blocking1.8.1.13+
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.
Flags: blocking1.8.1.15+
Whiteboard: [sg:want P1][needs branch patch] → [sg:want P1]
Keywords: csec-disclosure
You need to log in before you can comment on or make changes to this bug.