87501 - file: URLs "..." should be treated as "../.."

Status: RESOLVED WONTFIX

(Core :: Networking: File, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Type file:///c|/windows/desktop/../ into the location bar.  Notice that the
URL is changed to file:///c|/windows/.
2. Type file:///c|/windows/desktop/.../ into the location bar.  Notice that the
URL is not changed, but the contents of the root directory are shown.

"..." means "up two directories" on Win98 but not on Solaris.  I don't think it
has that meaning on WinNT.

I think the code causing Mozilla to only recognize ".." is in
nsIOService::ResolveRelativePath, but I'm not sure.

Right now, we canonicalize ".." but not "..." for both file and http.  I don't
know what the desired behavior is for an http url such as
http://mozilla.org/projects/components/.../, but the http behavior should not be
platform-dependent.  (Side note: if I type http://localhost/.../, my local web
server, OmniHTTPd, says "Security bypass attempted - possible breach".  How
reassuring.)

Mitch: is this the same code path that's supposed to prevent arbitrary local
content from being read through the chrome:// protocol? (when jarred chrome is off?)

Comment 1

[benc]

I've never heard of "..." in Windows, so we need to establish (from some 
technical source) that this should work.

That being said, looking at the BNF of file (RFC 1738)

fileurl        = "file://" [ host | "localhost" ] "/" fpath

fpath          = fsegment *[ "/" fsegment ]
fsegment       = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
unreserved     = alpha | digit | safe | extra
uchar          = unreserved | escape
safe           = "$" | "-" | "_" | "." | "+"

"." is a character that can appear unescaped. so "..." is a valid fsegement. We 
cannot cannonicalize this b/c RFC 1630 only recognizes ".." 

However, once the path is sent to Windows, if it does what you say, it should 
still work locally.

I have similar feelings about http, but that should be discussed in a new bug.

Comment 2

[benc]

+qawanted: has anyone heard of this before?!

Comment 3

[Jesse Ruderman]

BenC: I filed this bug primarily as a potential security hole on Windows.  If
Mozilla doesn't realize that Windows interprets "..." as "up two directories"
and sends "..." to the OS, something that is only allowed to look at things
within a given directory might be able to look at things in other directories.

If we can't canonicalize a file: URL with "...", we should reject it.

Comment 4

[benc]

If you can come up with some examples of how this is bad, go ahead and raise the 
severity. I've tried to figure out why this is bad, but in my first week back 
from a long break, I can't seem to grasp the implications.

Comment 5

[Andreas Otte]

rfc 2396 says that only '.' and '..' have special meaning in relative urls.
'...' then is just part of a segment of the dir (no change in the url!). If
'...' has special meaning on win98 there is nothing we can do about that in the
urlparser. We could perhaps block it in the win-specific part of the
implementation of nsIFile if there really is a need to do that

Comment 6

[benc]

We allow other potentially strange|dangerous|insecure behavior once you get into
the local file system, so it sounds like this is a WONTFIX.

Users are protected from general file:// badness via checkloadURI.
I defer to dougt or andreas, since ultimately this a design/code decision.

Comment 7

[Andreas Otte]

I vote for WONTFIX, Doug what's your opinion? 

Comment 8

[Jesse Ruderman]

I think it's a bug that pages loaded from file:/// can read a file anywhere in 
the file system.  Wontfixing this bug would make it impossible to fix that on 
Windows 98.

Comment 9

[Dan Mellem]

Yes, in MSDOS 6, 7, and Windows '9x, "..." means go up two directories, "...."
means go up three directories, etc.

However, this path isn't relative; it's an absolute path. As such the entire
path should be sent to the "server."

Comment 10

[benc]

The file URL already has access to the entire filesystem, so I am not sure how
this is bad. Is there some URL vs. OS exploit, where a hiearchical meaning of
the URL vs. the file accessed matters?

Using the original example, there isn't much that keeps people from using:

file:///c|/

There is some obfuscation problem w/ using: 

file:///c|/dir1/dir2/.../

but file is strictly a local convention, so I don't know if there is anything
you can do about it, since that is the entire idea behind file URLs.

dougt's going to have to make the call here.

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Jesse, I see what you're getting at, but I'm not sure there's an actual exploit
here. Can you create an exploit?

Comment 12

[Dan Mellem]

I wonder if this is taking the wrong approach. It seems that a file:// URL is
fully qualified so it's not a partial (relative) URL and "xxx/.." is only
removed when it's a partial URL. It seams that file:///c|/windows/desktop/../
and file:///c|/windows/desktop/.../ should remain as-is. Why are file URIs
canonized to begin with? If it's because of a security issue, that may apply
here as well.

Comment 13

[Jesse Ruderman]

> The file URL already has access to the entire filesystem, so I am not sure how
> this is bad.

1. File URLs should not have access to the entire filesystem IMO, and this bug
makes it harder to fix that.

2. This bug might allow chrome:// URLs to access the entire filesystem when
chrome is not jarred.  Untrusted content can load some thing from chrome://
URLs, such as images and XBL, which is necessary because of the way Mozilla
handles urls in UA and user style sheets.

3. Since we canonicalize "..", it's wrong to not canonicalize "...".

Comment 14

[benc]

What parts of a filesystem are we masking from file URLs?

We don't mask device drivers, and if we were to, I think we should do it at the
file handle level, not at the file URL level. 

If you were to say:

file:///dev/zero (whatever the windows 98 equivalent is...), and we had a mask
against that file URL, then I could see:

file:///dir/dir/.../dev/zero as being a backdoor.

But that isn't what we have. To my knowledge, we have no file URL blocking, so
who cares if you access the file handle directly or via a strange windows file
convention?

Comment 15

[Andreas Otte]

As I said before the code to canonicalize *urls* is no place to deal with local
file specifics on any filesystem. Therefore handling of ... or .... can have no
place there. 

file urls have by definition access to the entire file system on the client, at
least in the boundaries of the user executing mozilla and his ACLs and the
overall filesystem security of the OS. Because of that we block file-urls for
remote access, for example file-urls embedded in a page served over http do not
execute.

But I agree that the code for chrome urls when converting chrome-url to file-url
and then to local file should make sure that the resulting *local* file path
does not violate the boundaries of the chrome-url.

Comment 16

[Benjamin Smedberg]

http://lxr.mozilla.org/mozilla/source/chrome/src/nsChromeRegistry.cpp#390 might
be tricked into doing something evil here, with flat chrome.

http://lxr.mozilla.org/mozilla/source/netwerk/protocol/res/src/nsResProtocolHandler.cpp#281
doesn't check for ".." at all. I didn't check the code paths or try to do
anything harmful, though.

Comment 17

[Brodie]

I found this reference only: http://www.computerhope.com/cdhlp.htm
I can't find anything in MSDN which references it. 
I have tested it on Win98SE and it does work. 

My opinion is that we should recognize only . and .. as valid parts of paths 
(where appropriate). Other than that any path section consisting of only dots 
(more than 2) should either be ignored (treated same as ".") or cause an error. 
We should never recognize it or pass it through to the OS in any case.

Comment 18

[Brodie]

Windows XP just ignores multiple dots, treating them the same as a single dot. 
(when using cmd.exe). I agree that URL canonicalization shouldn't change 
since "..." is a valid segment, but this should be prevented from getting 
through to the local file system. 

Thus this bug as written is WONTFIX, and we need a new bug on nsLocalFileWin 
that Normalize should treat >2 dots as equal to single dot (i.e. ignore), and 
AppendRelativePath should fail for segments of >1 dot (.. is already disallowed 
re: the spec).

Comment 19

[Mats Palmgren (inactive)]

Can this be resolved as WONTFIX given that we don't support Windows 98 anymore?

Comment 20

[Dan Mellem]

This should be WONTFIX for file: (and INVALID for HTTP:).

I only mention HTTP because there's no problem with a directory "...". I just verified on an Apache server I can get to server.com/.../index.html. It doesn't make sense to me to have "..." behave differently depending on protocol, especially for a little-used DOS shortcut.