209234 - local files can read directory listings

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[Jesse Ruderman]

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.)

Comment 1

[Jesse Ruderman]

Attachment: 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.

Comment 2

[Bradley Baetz (:bbaetz)]

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.

Comment 3

[Daniel Veditz [:dveditz]]

We definitely do not want rogue local files to be able to munge around on disk.

Comment 4

[Darin Fisher]

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?

Comment 5

[Brendan Eich [:brendan]]

Attachment: 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

Comment 6

[Jesse Ruderman]

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.

Comment 7

[Daniel Veditz [:dveditz]]

(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.

Comment 8

[Mike Connor [:mconnor]]

punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.

Comment 9

[Daniel Veditz [:dveditz]]

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?

Comment 10

[Daniel Veditz [:dveditz]]

Bug 230606 checked into trunk. There's a pref setting to revert the changes if necessary.

Comment 11

[Daniel Veditz [:dveditz]]

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)

Comment 12

[Samuel Sidler (old account; do not CC)]

Dan needs to fix this completely on the trunk before we can take a branch patch. Punting to the next release.

Comment 13

[Daniel Veditz [:dveditz]]

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.