The default bug view has changed. See this FAQ.

Block URL access to device special files [CON, AUX]

RESOLVED FIXED in mozilla2.0

Status

()

Core
XPCOM
P2
critical
RESOLVED FIXED
17 years ago
3 years ago

People

(Reporter: Chris Nelson, Unassigned)

Tracking

(Blocks: 1 bug, {crash})

Trunk
mozilla2.0
x86
Windows 98
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
Open Mozilla. Enter the URL below into the address bar of the browser and hit 
enter. Mozilla will crash, and then the system will freeze up (Win98).

The URL:

file:///c|/con/con/con

Comment 1

17 years ago
There was the similar bug 23885, which was reported to have stopped happening
somewhere around 1/28.  If you are running M13, you'd have a build from before
that.  What build are you running?  And if it is M13, can you check with a
recent nightly build, please?

Comment 2

17 years ago
on winNT build 2000022408 it WORKSFORME.
(Reporter)

Comment 3

17 years ago
Witnessed this bug in the 2000022308 Win98 build.
This is an Operating System flaw, not specific to Mozilla.
Marking INVALID.
Please consult Microsoft Security Adviser for further report.
http://www.microsoft.com/security/default.asp
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 5

17 years ago
VYV03354@nifty.ne.jp:  Please quote the security report that applies to this 
bug.   A reproducible crash is not invalid, no matter what.

I'm reopening for now.  suttree@bellatlinatic.net, please let us know what 
module MOzilla is crashing in.  
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 6

17 years ago
I can't tell you which module, because Mozilla disappears immediately with no 
crash dialog, followed quickly by an Operating System crash.

--chrisn

Comment 7

17 years ago
OK, I'm confirming this (chrisn, shouldn't your bugs automatically start off as 
NEW?)  I crash nasty when loading the above URL.  Mozilla is instantly replaced 
by a windows blue screen of death.  The blue screen says:
"A fata exception OE has occurred at 0028:C0049233 in VDX VFAT(01) + 0000B897.  
The current application will be terminated.
*Press any key to terminate the current application.
*Press ctrl+alt+del to restart your computer."

If I try to keep going my system fails to respond.  This sucks. :(
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

17 years ago
forgot to mention tested on 022509 build under win98.

Comment 9

17 years ago
moving to Networking component.

note on bug - if you go to an existing directory and add 1 invalid subcategory,
I think that works.

Comment 10

17 years ago
This crash is a bug in Win98, and has nothing to do with Mozilla!
In Win98:
-Click on START and then "Execute" (or however this is called in the english
 version of Win98)
-enter C:\con\con\con\foo.exe
-click "OK" and watch the blue screen diplaying something about VDX VFAT(01)

or enter "file:///c:\con\con\con" in Netscape 4.7 -> same result

Andreas
andreas - thanks, did not know this. so, this should be marked a invalid?

Comment 12

17 years ago
this doesn't happen with just any non-existent file though, right?  is it just 
this special file, or are there other files that will cause this to happen?

updating component to xpcom and owner to dougt@netscape.com who wrote the 
nsIFile stuff to see what he thinks we ought to do about this.
Assignee: cbegle → dougt
Component: Browser-General → XPCOM

Comment 13

17 years ago
More detailed information is coming on the web.
Please visit http://www.oct.zaq.ne.jp/yufu/browser/2000/02.en.html#26_03

Comment 14

17 years ago
For cbegle@mozilla.org's comment
Exactlly. Any MS-DOS reserved word may cause this bug, prn, nul, etc, regarding 
with the file is not existing. 
While MS has announced these words can not be used as a file name on MS-
Windows95/98 file system, the company has never refered to that this bug will 
cause such a serious problem. I am afraid, it may result in some kind of moral 
hazard in the Internet community. We should pressure MS to fix the bug 
immediately.

Comment 15

17 years ago
nsIFile could try to prevent this.  Marking as milestone m16.
Target Milestone: M16

Comment 16

17 years ago
what prevents similar things from happening on unix platforms?

Comment 17

17 years ago
can opening those bogus files actually mess up a filesystem or is that an 
exaggeration?

Comment 18

17 years ago
*** Bug 31607 has been marked as a duplicate of this bug. ***
>VYV03354@nifty.ne.jp:  Please quote the security report that applies to this 
bug.   
http://www.microsoft.com/technet/Security/Bulletin/ms00-017.asp
Again, this is NOT a Mozilla specific problem.

Comment 20

17 years ago
There are patches available from MS that fix this security hole in *thier* 
operating system.  Marking invalid.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID

Comment 21

17 years ago
Would it be nontrivial for mozilla to send a dialog box to a user of a system 
without the patch, warning them that a security hole in their operating system 
might be remotely exploitable through the browser?  This would only have to be 
done once, or when the prefs file is created or something, so it shouldn't be 
hard to keep the code from slowing down the browser in general.

Again I ask, what prevents similar things from happening on linux systems?  
Couldn't someone remotely drain your entropy by reading /dev/random or 
something? (ianalu)

Comment 22

17 years ago
I would review, and probably check in a dialog patch that did this.  I will 
reopen and mark remind.

Adding shaver and blizzard.  Could you answer davidr8@home.com's question?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 23

17 years ago
marking remind and helpwanted.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Keywords: helpwanted
Resolution: --- → REMIND
Draining the entropy in /dev/random doesn't really gain you anything other than
denial of service, and file://dev/zero gets you a long way there anyway.

I long wanted to check in code for 4.x that prevented file: URLs from opening
device files, controlled by a pref.  Someone want to whip up a necko patch to
check S_ISBLK/S_ISCHR for file:?

Comment 25

17 years ago
Since it took me a while to figure this out, I'm going to ask and answer this 
question before someone like me (but not me) writes a stupid flame.

Q: If you block access to file:///dev/* on linux, why not block access to 
file:///*/con/*, etc?  Aren't you being hypocritical?
A: There's no easy way to list the device names in DOS or Win32 (see the MS 
security bulletin whose URL is given above).

The linux dev/ thing should be a different bug, but please mention the bug 
number of the dev/ bug here if you find or create it, and vice versa.
If someone wants to block specific filenames on Win98, I guess we could do that.

Also, it might make sense to add a security policy knob (defaulted to the
``safe'' setting) which prevented content loaded from remote sources from
accessing file: content, such as via <img src=>.  Norris?

Comment 27

17 years ago
Currently content is prohibited from opening scripts or html documents from
file:. There's no reason we couldn't extend the check to IMAGE SRC=. Look at

http://lxr.mozilla.org/seamonkey/search?string=CheckLoadURI

for instances where we perform these checks.

Comment 28

17 years ago
MS finally put the fix on windowsupdate. 
http://www.microsoft.com/technet/security/bulletin/ms00-017.asp

Comment 29

17 years ago
*** Bug 31607 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
> Again I ask, what prevents similar things from happening on linux systems?

I don't know what (code) is responsible, but 4.x freezes at opening
<file:///dev/random> :-((, but Mozilla just loads infinitely :). Good work
(assuming it is not special acsing which prevents a freeze in Mozilla).

Comment 31

17 years ago
Adding crash keyword
Keywords: crash

Comment 32

17 years ago
Please relnote this.
~ Windows 9x 
http://www.microsoft.com/technet/Security/Bulletin/ms00-017.asp
accessing a path that contains multiple dos devices may crash your system, this 
is a system feature and does not relate to mozilla. The security bulletin has 
links to patches.
Keywords: relnote, relnoteRTM

Comment 33

17 years ago
Reopening as future to make sure this shows up on relnote queries.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Target Milestone: M16 → Future

Comment 34

17 years ago
Updating summary.
Summary: file:/// urls to dummy directories will *crash* a Win98 system (not just the browser) → file:///c|/con/con/con crashes an unpatched Win98 system (not just the browser)

Updated

17 years ago
Whiteboard: relnote-user

Comment 35

17 years ago
over to you mitch per our conversation
Assignee: dougt → mstoltz
Status: REOPENED → NEW
This was previously filed as 37425 and marked WORKSFORME, presumably because all
three Win98 systems used for testing had the patch from MS which prevents this.
However, as JR posted above, similar things are possible on Unix. I tried
pointing a link at /dev/zero, and Mozilla brought up a save dialog and happily
started saving an infinitely large file of zeros. Granted, most Unix users would
probably catch on to this, but there may be more dangerous things lurking in
/dev. For the most part, we prevent all access to local files, which fixes this
class of problem on all platforms. There are a few places (notably images) where
we don't do this check. I'm trying to track them down and add the check. This is
bug 55237, and I've noted the dependency. 
Status: NEW → ASSIGNED
Depends on: 55237

Comment 37

16 years ago
*** Bug 84327 has been marked as a duplicate of this bug. ***

Comment 38

16 years ago
Why this flaw ("file://"-links in IMG-tags of webpages in the net) still exists,
if you have known about this for a long time?

In my opinion anything loaded from http or ftp shouldn't be able to link (in any
tag) to file://-URLs. That would fix all relevant issues mentioned in this bug.
Easier said than done, my friend. The reason is that adding the check for images
causes some regressions, and to fix the regressions would mean weakening the
security check. I'm still trying to come up with an optimal solution. Instead of
complaining about why this bug is still open, you could help us come up with a
fix that doesn't break other things. 

Comment 40

16 years ago
-relnoteRTM

Keywords: relnoteRTM

Comment 41

16 years ago
qa to me - cleared whiteboard

if file URLs are the only obvious path to this bug, I'll do qa and relnote for 
it. If more entry points arrive, I'll create a file ONLY bug and block it with 
this bug.

I expect some number of people to turn off checkloadURI for various reasons 
discussed elsewhere. 

Since we still support Win 95 and 98 customers, I think we should consider a 
mask that prevents this. I've proposed a similar mask for UNIX.

QA Contact: asa → benc
Summary: file:///c|/con/con/con crashes an unpatched Win98 system (not just the browser) → file:///DEVICE crashes an unpatched Win98 system
Whiteboard: relnote-user
This is pretty low priority now. We could even consider WONTFIXing it,
considering that it affects only Win98 and Microsoft released a patch ages ago.

If we do still want to address this problem, I like the idea of a mask which
blocks these sorts of accesses at the Necko level. This is still a concern for
Unix and I'd love to see a Necko-level device-file blocker for Unix go in as
well. It might eliminate the need to call CheckLaodURI in some situations, and I
think that would make a lot of people happy. Ben, do you have another bug for
your Unix patch?

Comment 43

16 years ago
There is a bug, I'll put you on the cc and make a comment here (I'm almost done
w/ a big cleanup of "file" bugs...)
Changing description:
Block URL access to device special files
Summary: file:///DEVICE crashes an unpatched Win98 system → Block URL access to device special files
*** Bug 144871 has been marked as a duplicate of this bug. ***
Summary: Block URL access to device special files → Block URL access to device special files [CON, AUX]

Comment 46

14 years ago
*** Bug 212064 has been marked as a duplicate of this bug. ***

Comment 47

14 years ago
Reopened Bug 212064 as Moz fails with patch in Comment 28 applied.

Updated

14 years ago
Blocks: 193255

Comment 48

13 years ago
Cannot duplicate in my patched XP SP1 system.

If I click the URL link above, nothing at all happens.  If I enter the URL
manually I get a alert box that says "The file /c|/con/con/con cannot be found.
 Please check the location and try again."

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

Comment 49

13 years ago
(In reply to comment #48)
> Cannot duplicate in my patched XP SP1 system.
> 
> If I click the URL link above, nothing at all happens.  If I enter the URL
> manually I get a alert box that says "The file /c|/con/con/con cannot be found.
>  Please check the location and try again."
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316

(In reply to comment #0)
> Open Mozilla. Enter the URL below into the address bar of the browser and hit 
> enter. Mozilla will crash, and then the system will freeze up (Win98).
> 
> The URL:
> 
> file:///c|/con/con/con

WFM, cannot reproduce... 

All I get is the following window:

Alert

The file /c|/con/con/con cannot be found. Please check the location and try again.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040330
Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 50

12 years ago
*** Bug 278943 has been marked as a duplicate of this bug. ***

Comment 51

12 years ago
It is clear that all the file links don't work from remote documents (see Bug
69070). 

If I enter file:///c|/con/con/con manually in the location bar I get an alert
box that says "The file /c|/con/con/con cannot be found. Please check the
location and try again."

But if I enter file:///c|/aux (or file:///c:\aux) in the location bar, Mozilla
does search forever but responds to all other tasks and you can stop it. But if
you close Mozilla completely the process will remain in memory as zombie.

Mozilla 1.8b build 2005011805 on WinNT4 (same for Firefox 1.0, see duplicate).
Assignee: security-bugs → nobody
Status: ASSIGNED → NEW
QA Contact: benc → xpcom
Duplicate of this bug: 390537
I can't reproduce... any chance there has been a fix in the meantime?
Keywords: helpwanted, relnote → qawanted
Priority: P3 → P2
Target Milestone: Future → mozilla1.9.3
Fixed by bug 103468?  The function MangleTextToValidFilename introduced by that patch disallows specific filenames such as "aux" and "con", among other things.
Closing as it appears to be fixed, unless someone finds a working repro.
Status: NEW → RESOLVED
Last Resolved: 17 years ago8 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.3 → mozilla2.0
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.