Closed Bug 29079 Opened 25 years ago Closed 15 years ago

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

Categories

(Core :: XPCOM, defect, P2)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0

People

(Reporter: suttree, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: crash) 

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
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?
on winNT build 2000022408 it WORKSFORME.
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
Closed: 25 years ago
Resolution: --- → INVALID
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 → ---
I can't tell you which module, because Mozilla disappears immediately with no 
crash dialog, followed quickly by an Operating System crash.

--chrisn
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
forgot to mention tested on 022509 build under win98.
moving to Networking component.

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

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?

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
More detailed information is coming on the web.
Please visit http://www.oct.zaq.ne.jp/yufu/browser/2000/02.en.html#26_03
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.
nsIFile could try to prevent this.  Marking as milestone m16.
Target Milestone: M16
what prevents similar things from happening on unix platforms?
can opening those bogus files actually mess up a filesystem or is that an 
exaggeration?
*** 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.
There are patches available from MS that fix this security hole in *thier* 
operating system.  Marking invalid.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → INVALID
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)
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 → ---
marking remind and helpwanted.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 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:?

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?

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.

MS finally put the fix on windowsupdate. 
http://www.microsoft.com/technet/security/bulletin/ms00-017.asp
*** Bug 31607 has been marked as a duplicate of this bug. ***
> 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).
Adding crash keyword
Keywords: crash
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
Reopening as future to make sure this shows up on relnote queries.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Target Milestone: M16 → Future
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)
Whiteboard: relnote-user
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
*** Bug 84327 has been marked as a duplicate of this bug. ***
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. 
-relnoteRTM
Keywords: relnoteRTM
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?
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]
*** Bug 212064 has been marked as a duplicate of this bug. ***
Reopened Bug 212064 as Moz fails with patch in Comment 28 applied.
Blocks: clu
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 #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
*** Bug 278943 has been marked as a duplicate of this bug. ***
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).
URL: file:///c|/con/con/con → file:///c|/aux
Assignee: security-bugs → nobody
Status: ASSIGNED → NEW
QA Contact: benc → xpcom
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
Closed: 24 years ago → 15 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.