The default bug view has changed. See this FAQ.

local files can read directory listings

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
Security
--
minor
RESOLVED FIXED
14 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: dveditz)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {csectype-disclosure})

Trunk
mozilla1.9alpha8
x86
Windows XP
csectype-disclosure
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.5 -
blocking1.9 +
blocking1.8.1.13 -
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want P1])

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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.)
(Reporter)

Comment 1

14 years ago
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.
(Assignee)

Comment 3

14 years ago
We definitely do not want rogue local files to be able to munge around on disk.
Flags: blocking1.5?

Comment 4

14 years ago
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

Updated

14 years ago
Flags: blocking1.5? → blocking1.5-
(Reporter)

Comment 6

13 years ago
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.
(Reporter)

Updated

12 years ago
Assignee: security-bugs → dveditz
QA Contact: carosendahl → toolkit
(Assignee)

Comment 7

11 years ago
(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.
(Assignee)

Updated

10 years ago
Group: security
Whiteboard: [sg:want]
Flags: blocking1.9?
(Assignee)

Updated

10 years ago
Blocks: 318775
(Assignee)

Updated

10 years ago
Whiteboard: [sg:want] → [sg:want P1]
Flags: blocking1.9? → blocking1.9+
(Assignee)

Updated

10 years ago
Target Milestone: --- → mozilla1.9alpha5
(Assignee)

Updated

10 years ago
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
(Assignee)

Comment 9

10 years ago
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
(Assignee)

Comment 10

10 years ago
Bug 230606 checked into trunk. There's a pref setting to revert the changes if necessary.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Depends on: 395625
(Assignee)

Comment 11

9 years ago
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?
(Assignee)

Updated

9 years ago
Flags: blocking1.8.1.12? → blocking1.8.1.12+
(Assignee)

Updated

9 years ago
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+
(Assignee)

Comment 13

9 years ago
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]
(Reporter)

Updated

4 years ago
Keywords: csec-disclosure
You need to log in before you can comment on or make changes to this bug.