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

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P2)

Description

[Chris Nelson]

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

[Richard Zach]

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

[Joseph Elwell]

on winNT build 2000022408 it WORKSFORME.

Comment 3

[Chris Nelson]

Witnessed this bug in the 2000022308 Win98 build.

Comment 4

[Masatoshi Kimura [:emk]]

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

Comment 5

[Christine Begle]

[e-mail]:  Please quote the security report that applies to this 
bug.   A reproducible crash is not invalid, no matter what.

I'm reopening for now.  [e-mail], please let us know what 
module MOzilla is crashing in.  

Comment 6

[Chris Nelson]

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

[Asa Dotzler [:asa]]

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

Comment 8

[Asa Dotzler [:asa]]

forgot to mention tested on 022509 build under win98.

Comment 9

[Doron Rosenberg (IBM)]

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

[Andreas Behnert]

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

Comment 11

[Doron Rosenberg (IBM)]

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

Comment 12

[Christine Begle]

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 [e-mail] who wrote the 
nsIFile stuff to see what he thinks we ought to do about this.

Comment 13

[gem6404]

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

[gem6404]

For [e-mail]'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

[Doug Turner (:dougt)]

nsIFile could try to prevent this.  Marking as milestone m16.

Comment 16

[Jesse Ruderman]

what prevents similar things from happening on unix platforms?

Comment 17

[Jesse Ruderman]

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

Comment 18

[Andreas Behnert]

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

Comment 19

[Masatoshi Kimura [:emk]]

>[e-mail]:  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

[Doug Turner (:dougt)]

There are patches available from MS that fix this security hole in *thier* 
operating system.  Marking invalid.

Comment 21

[Jesse Ruderman]

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

[Doug Turner (:dougt)]

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 [e-mail]'s question?

Comment 23

[Doug Turner (:dougt)]

marking remind and helpwanted.

Comment 24

[Mike Shaver (:shaver emeritus)]

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

[Jesse Ruderman]

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.

Comment 26

[Mike Shaver (:shaver emeritus)]

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

[Norris Boyd]

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

[Jesse Ruderman]

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

Comment 29

[Peter "jag" Annema]

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

Comment 30

[Ben Bucksch (:BenB)]

> 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

[leger]

Adding crash keyword

Comment 32

[timeless]

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.

Comment 33

[Jesse Ruderman]

Reopening as future to make sure this shows up on relnote queries.

Comment 34

[Jesse Ruderman]

Updating summary.

Comment 35

[Doug Turner (:dougt)]

over to you mitch per our conversation

Comment 36

[Mitchell Stoltz (not reading bugmail)]

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. 

Comment 37

[timeless]

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

Comment 38

[Lasse Kärkkäinen]

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.

Comment 39

[Mitchell Stoltz (not reading bugmail)]

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

[benc]

-relnoteRTM

Comment 41

[benc]

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.

Comment 42

[Mitchell Stoltz (not reading bugmail)]

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

[benc]

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

Comment 44

[Mitchell Stoltz (not reading bugmail)]

Changing description:
Block URL access to device special files

Comment 45

[Matthias Versen [:Matti]]

*** Bug 144871 has been marked as a duplicate of this bug. ***

Comment 46

[Jo Hermans]

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

Comment 47

[Jim Race]

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

Comment 48

[Kevin Berkheiser]

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

[Anders Pedersen]

(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

[OstGote!]

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

Comment 51

[OstGote!]

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

Comment 53

[Benjamin Smedberg]

I can't reproduce... any chance there has been a fix in the meantime?

Comment 54

[Jesse Ruderman on Windows]

Fixed by bug 103468?  The function MangleTextToValidFilename introduced by that patch disallows specific filenames such as "aux" and "con", among other things.

Comment 55

[Lucas Adamski [:ladamski]]

Closing as it appears to be fixed, unless someone finds a working repro.