If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

file:///UNC and file:////UNC should not -> file://///UNC

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Networking: File
P3
critical
VERIFIED FIXED
18 years ago
15 years ago

People

(Reporter: Jesse Ruderman, Assigned: dougt)

Tracking

({hang, testcase})

Trunk
mozilla0.9.1
x86
Windows 98
hang, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
Steps to reproduce:  (about 60% reproducability)
1. Save your work so you don't panic if your OS freezes
2. Save URL or attachment to your hard drive
3. Load local copy of attachment file in mozilla
4. Leave the page (click home icon, close mozilla, etc.)

Notes: 

- other apps become unresponsive as well, and ctrl-alt-del takes more than a
  second to show up

- adding more bogus drive names increases crash length, but adding more
  filenames with the same drive name image files doesn't (not sure about this)

- /foo/bar.gif works as well as file:///foo/bar.gif
  (this is why it showed up on local copies of legit pages)

- freeze is most reproducable while leaving page, but can happen if page is
  open and you're working in another application
(Reporter)

Comment 1

18 years ago
Created attachment 8455 [details]
test case
(Reporter)

Comment 2

18 years ago
Marking as a crasher and raising severity because with many different bogus 
drive names, this freezes the OS for quite a while.
Severity: major → critical
Keywords: crash, testcase

Comment 3

18 years ago
->warren
Assignee: gagan → warren

Comment 4

18 years ago
I just use nsIFile.  => dougt
Assignee: warren → dougt
(Assignee)

Comment 5

18 years ago
This is a known windows 98 system problem.  I belive that Microsoft has patches 
via WindowsUpdate for this. 

Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 6

18 years ago
This may be known, and it is probably a bug, but I don't see any patches for 
it.  This bug is not bug 29079, which involved device driver names, whereas 
this one involves bogus drive names.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 7

18 years ago
pam, do you know of any problems loading images from a bad file url on windows 
98?

Comment 8

18 years ago
DT:

nope. Imglib doesn't care about files. It cares about data streams.
We use file specs for id'ing images, but we deal with data streams.
-P
(Assignee)

Comment 9

18 years ago
something must have changed.  works for me.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 10

18 years ago
verified WORKSFORME
Win98 2000070508
Status: RESOLVED → VERIFIED
(Reporter)

Comment 11

17 years ago
now freezes mozilla but not windows 98.  reopening.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Summary: Bogus drive name in file:/// url freezes Windows 98 → Bogus drive name in file:/// url freezes mozilla (no longer freezes Windows 98)
(Reporter)

Comment 12

17 years ago
oh, it does sometimes still freeze windows 98.
Summary: Bogus drive name in file:/// url freezes mozilla (no longer freezes Windows 98) → Bogus drive name in file:/// url freezes mozilla and sometimes freezes Windows 98
(Assignee)

Comment 13

17 years ago
Still can't reproduce.  QA, can you try/verify this again on a couple different
machines?
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 14

17 years ago
jesse, I'm not seeing any attachment in your 05-08 23:41 comment.  Was this 
basically the URL you saved locally as an html file?
(Reporter)

Comment 15

17 years ago
My comment really wasn't clear; thanks for pointing that out.  I was referring 
to what happens when I load a file that looks like

<img SRC="/foo1/bar" alt="1">
<img SRC="/foo2/bar" alt="2">
<img SRC="/foo3/bar" alt="3">
<img SRC="/foo4/bar" alt="4">
<img SRC="/foo5/bar" alt="5">
<img SRC="/foo6/bar" alt="6">
<img SRC="/foo7/bar" alt="7">

and load it in the browser.  (Hint: try it with fewer than 7 first.)

Note that

<img SRC="/foo1/bar1" alt="1">
<img SRC="/foo1/bar2" alt="2">
<img SRC="/foo1/bar3" alt="3">
<img SRC="/foo1/bar4" alt="4">
<img SRC="/foo1/bar5" alt="5">
<img SRC="/foo1/bar6%22 alt="6">
<img SRC="/foo1/bar7" alt="7">

is much less problematic.

Comment 16

17 years ago
ok, the way I understand this is that you are giving two examples of a lockup 
problem.  The first example uses a copy of the zdnet page stored locally, and 
the second example uses an html test file with the code listed in your last 
comment (with 7 img tags and the alt attribute).  

If that is correct I am still not reproducing this.  Could you possibly 
re-attach your test case?  thx

Comment 17

17 years ago
I typed that last comment to quickly.  What I can see is a lockup (on win 98) 
when I load a copy of the page from a local drive.  It is ok on win NT.  But I 
cannot narrow it down to the bogus directory using the html you provided.

Comment 18

17 years ago
Doug, copies of the files I am using are at 
  http://bubblegum/tever/bogus.html
  http://bubblegum/tever/bigpage.html
but you need to copy them locally.

Comment 19

17 years ago
Added 40 bogus directories to test case per Jesse's recomendation.  Still 
works on win98 for me.  

I do however see a slight pause when the page is loading.  Is it possible you 
are seeing this?   What is the speed / memory of the system you are you using?   
(Assignee)

Comment 20

17 years ago
reopening based on comments..
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 21

17 years ago
Created attachment 15442 [details]
test case
(Reporter)

Comment 22

17 years ago
Created attachment 15480 [details]
Many bogus drives instead of many files on a bogus drive
(Reporter)

Comment 23

17 years ago
I think I figured it out: Mozilla is interpreting file:///foo1/bar/ as 
\\foo1\bar\, meaning "ask computer foo1 on your local network for a directory 
called bar".  Windows 98 is very slow about network things (try start-r, 
\\foo115\bar) but apparently only freezes if asked to try to access several 
computers on the local network at once.

IE and Mozilla will both accept file://///watership/mp3/ typed into the 
location bar.  Mozilla will also accept file:///watership/mp3/ as an equivalent 
url for the url above, and will replace it with the 5-slash version if the 3-
slash version is typed into the url bar.  This should only happen when the url 
is typed by the user (see bug 34943 for a similar problem).

So we actually have two problems here:
- url error-corrrection happening when it shouldn't
- a bad crash, that afaict can't be exploited remotely

Netscape 4.75 doesn't accept file:///// urls.
(Reporter)

Comment 24

17 years ago
Re-summarizing.
Summary: Bogus drive name in file:/// url freezes mozilla and sometimes freezes Windows 98 → page with multiple file:///// images freezes Win98

Comment 25

17 years ago
This file url correction only happens on XP_PC if the stuff after file:/// can
not be identified as a syntactically valid drivename. It is a best guess on what
the user want's and sometimes that's false. This conversion is currently deeply
burried into the urlparser, no way of getting it out there without changing the
whole process of creating fixup URIs, as suggested many times before.
(Reporter)

Comment 26

17 years ago
Oops, this crash is remotely exploitable.

<a href="data:text/html,<script>for (i = 0; i < 4; ++i) document.write('<img 
src=file://///bogusdrive' + i + '/foo.jpg alt=' + i + '>');</script>" 
target="_blank">click here to freeze moz for a while</a>

Comment 27

17 years ago
any opinion on this, mstoltz?  Thanks.
(Assignee)

Comment 28

17 years ago
over to you mitch per our conversation.
Assignee: dougt → mstoltz
Status: REOPENED → NEW

Updated

17 years ago
Keywords: crash → freeze

Updated

17 years ago
Keywords: freeze → hang

Updated

17 years ago
Blocks: 63736

Comment 29

17 years ago
All of these testcase now work for me can anyone else verify that its now ok?

Platform: PC
OS: Windows 98
Mozilla Build: 2001022620
Setting milestone to Moz0.9.
Target Milestone: --- → mozilla0.9

Comment 31

17 years ago
Using 2001041104 on Win98, all of the test cases seem to work.

When loading a local file that contains:

<img SRC="/foo1/bar" alt="1">
<img SRC="/foo2/bar" alt="2">
<!-- ... -->
<img SRC="/foo9/bar" alt="9">

mozilla "thinks" for several seconds (5-10) but does not freeze.

Adding CheckLoadURI to IMG tags will keep this from being remotely exploitable,
which IMHO is acceptable. This is supposed to happen by 0.9. After that, if
anyone wants to address this crash/slowdown, that's cool, if not, that aspect of
the bug is a WONTFIX.
Status: NEW → ASSIGNED
OK, my part is done. It should be generally impossible to reference a file: URL
of any kind from Web content, at least it will be win Pavlov gets his fix in.
Meantime, I'm moving this over to Necko and pushing out the milestone to see if
anyone over there thinks the slowdown caused by asking Windows to search for a
network drive is worth treating as a denial-of-service issue.
Assignee: mstoltz → neeti
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 34

17 years ago
this is an annoying problem and should get fixed for the beta. giving to doug 
since he has been working on file transport related issues. 
Assignee: neeti → dougt
Keywords: nsbeta1+

Updated

17 years ago
Keywords: nsenterprise
(Assignee)

Comment 35

17 years ago
RFC 1738 states that the syntax of file:// URL is:

file://<host>/<path>

so, if there is a computer that is accessible via UNC named foo, the URL to that
computer is file://foo/.  Is the suggestion that the host name of a UNC mount in
a URL is always prepended by "//" or "///"?  



Comment 36

17 years ago
The host in the file-url has nothing to do the host in an UNC filepath. As the
name suggests, all of UNC is happening inside the path component of the URL. All
the urlparser can do is guess and add the appropiate number of slashes as
necessary. So to really be an UNC filepath it has to be file://///foo to work on
every OS. Two slashes for the protocol, one to delimit the non existing host and
then two to start the UNC filepath.

The file protocol is by definition a local protocol, even if the syntax might
suggest otherwise. The only possible host can be localhost, nothing else makes
really sense because there is no generic way to access a file a on remote
computer.

The problem during parsing is to distinguish a hostname from a directory. This
is easy on XP_PC where drives can be easily detected at the beginning of a path
and eyerything else *could* be a network name. Currently the urlparser doeas
just that. On unix/linux there is no way to syntactically distinguish a hostname
from a directory, so there is much less fixup possible.
(Assignee)

Comment 37

17 years ago
As near as I can tell, the bug is that we assue that if a file url does not have 
a drive specifier, it is a UNC path.  This, however, is incorrect.  We should be 
defaulting to the drive where the application is running from.

The code that check for UNC paths is here:

http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsNoAuthURLParser.cpp#2
72

So, I think one way of handling this is for the check in nsNoAuthURLParser.cpp 
to go away.  Then in nsStdUrl::GetFile(), where we convert the url path to 
native path, we have some logic to determine if it is a UNC path or if it is a 
path missing a drive spec.

I will attach a patch which addresses this.  I tested the path against 
the testcases and it performs well.  I also loaded file files and such, but I am 
not sure I am covering all bases.  

Andreas, could you tell me what I am missing?  
Status: NEW → ASSIGNED
(Assignee)

Comment 38

17 years ago
Created attachment 32759 [details] [diff] [review]
fix for aggressively accessing network volumes
(Assignee)

Updated

17 years ago
Keywords: patch

Comment 39

17 years ago
As far as I know there is no defaulting to the current drive with file urls. A
file url is either absolute and contains a full path (which includes a drive on
some OS) or is relative and maybe contains no drive but the base url has to (on
some OS).

But if this url guessing is to agressive, we should try and switch it off/apply
the patch. I currently have no working win32 build (totally rotten away), so I
can't check against my modified urltest-version. tever has the diffs. Maybe
someone else has time to test the patch.
(Assignee)

Comment 40

17 years ago
gagan, darin, please review.  

Comment 41

17 years ago
r=gagan

Comment 42

17 years ago
sr=darin (but make sure you get enough testing before landing this)
(Assignee)

Comment 43

17 years ago
Fix checked in.

Checking in nsNoAuthURLParser.cpp;
/cvsroot/mozilla/netwerk/base/src/nsNoAuthURLParser.cpp,v  <--  
nsNoAuthURLParser.cpp
new revision: 1.13; previous revision: 1.12
done
Checking in nsStdURL.cpp;
/cvsroot/mozilla/netwerk/base/src/nsStdURL.cpp,v  <--  nsStdURL.cpp
new revision: 1.72; previous revision: 1.71
done
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 44

16 years ago
-> file

So, is the fix that we do not take file:///<path> as UNC, and require file:///// 
paths now?
Component: Networking → Networking: File

Comment 45

16 years ago
Yes, we no longer stuff the url with / when we can't detect a drivename in file
urls and it is not a UNC-PATH. Instead we let it default to the current(?)
drive. This may be wrong as it is to always assume UNC-Paths if no drive is
present. But I think this may be the best compromise. Time will tell ....

Comment 46

16 years ago
Thanks for the clairification.

File URL's will be getting more attention in the next milestone release notes.

We'll find out one way or the other...
Keywords: relnote

Comment 47

16 years ago
VERIFIED:
Win98, Mozilla 0.9.4.

STEPS:
1- access file:///UNC
Viewed file.
2- attempted to access shorter file URLs by progressively removing slashes

file:///UNC and file:///UNC are non-existent files and treated as such. 
(correct)
file://UNC -> file://servername/path (correct)
file:/UNC -> file:///UNC, which is non-existent. (correct)
Status: RESOLVED → VERIFIED
Summary: page with multiple file:///// images freezes Win98 → file:///UNC should not -> file://///UNC

Comment 48

16 years ago
I can't count...
file://///UNC (5) works.

"file:///UNC and file:///UNC" should have been:
file:///UNC (3) and file:////UNC (4)"

Fixed summary too.
Summary: file:///UNC should not -> file://///UNC → file:///UNC and file:////UNC should not -> file://///UNC

Updated

15 years ago
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.