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
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. firstname.lastname@example.org, please let us know what module MOzilla is crashing in.
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. :(
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 email@example.com who wrote the nsIFile stuff to see what he thinks we ought to do about this.
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 firstname.lastname@example.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.
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.
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 email@example.com's question?
marking remind and helpwanted.
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
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.
Reopening as future to make sure this shows up on relnote queries.
over to you mitch per our conversation
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.
*** 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.
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.
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
*** Bug 144871 has been marked as a duplicate of this bug. ***
*** Bug 212064 has been marked as a duplicate of this bug. ***
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).
I can't reproduce... any chance there has been a fix in the meantime?
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.