Closed Bug 37425 Opened 25 years ago Closed 24 years ago

system crash when viewing page in Win98

Categories

(Core :: Security, defect, P3)

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

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: jaagup.irve, Assigned: security-bugs)

References

(
URL
)

Details

(Whiteboard: [nsbeta3-][need info])

major win98 bug, but it should be handled on browser level, havent checked on win95. could also crash. trying to read from dir c:\con causes a crash in above url.
Installed patch for Win98 and had no effect whatsoever. Solid freeze of OS, did CAD to "end task" on Mozilla, blue screened, Dr Watson went nuts and had to cancel it. Hit RETURN key and system automagically rebooted. Nastiest crash I've witnessed in over a year.
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
More background: This is a security vulnerability in Windows 95/98 (see http://www.securityfocus.com/vdb/bottom.html?vid=1043 for background) and you should patch your OS to fix it http://www.microsoft.com/technet/Security/Bulletin/ms00-017.asp for links). Mozilla Win32 build 2000042708 on NT and Win2000 does not crash, but then again those OS's are not vulnerable to this problem. On systems it does crash, though, this is a fantastic denial of service attack.
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Adding crash to keywords
Keywords: crash
Changed summary to indicate Win98
Summary: system crash when viewing page → system crash when viewing page in Win98
Looks like the page referenced in this bug loads an image from HREF="c:\con\con". Loading anything from a local file should be disallowed anyway. The fix to bug 31650 will close this loophole. Except for that, any other aspects of this bug are Microsoft's responsibility, in my opinion.
Status: NEW → ASSIGNED
Depends on: 31650
Target Milestone: --- → M16
I don't think this should bother us; the security manager should prevent web code from loading a local file of any kind. I don't have a Win98 machine to test on, though. Changing QA contact to czhang. Cathy, could you try this on a Win98 machine and make sure the machine isn't hosed by this attack? If you see anything amiss, just reopen the bug. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
QA Contact: junruh → czhang
Resolution: --- → FIXED
my NT is not displaying anything, no crash either, this is the expected, I'll verify it on Win98.
I reproduced this bug on win98, it is a very bad bug, system fatal error, have to reboot the machine. the code for the html page is: <HTML> <HEAD> <TITLE></TITLE> </HEAD> <BODY> <img src="file:///c|/con/con"> <h1>Kui te seda kirja n&auml;ete, te kas ei kasuta Windowsit, v&otilde;i olete &otilde;nnega koos</h1> </BODY> </HTML>
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Tested with Build 2000053020 (talkback) on Win 98 SE Patch Keven Hecht mentioned is installed on OS. With the patch installed the system dosen't crash, But Mozilla freezes. Have to CTL-ALT-DEL to exit Mozilla. No Talkback was generated. Also tested with NN 4.72. NN dosen't crash, it just displays the broken link symbol. This bug is a dupe of bug 29079 which is currentally Resolved Remind. One of these two should remain open. At the least Mozilla souldn't freeze when the patch is installed.
I'm in the process of preventing Web content from accessing local file URL's. That should solve this problem. Is this a satisfactory solution? See the recent thread on n.p.m.security for more detail.
Preventing access to local files is the perfered solution. As for having a preferance to turn this feature on/off, On multi-user systems the root account should also have a preferance to disallow other users to change this setting.
Moving to M17. Not an M16 stopper.
Target Milestone: M16 → M17
Depends on: 40538
Assigning QA to czhang
THis bug is not a high priority, since the bug is actually in W98. However, I can forsee similar types of errors if we allow arbitrary loading of local (non-chrome) files through any means. For example, pointing to a /dev/* file on Unix could cause problems. Arbitrary file:// URLs are blocked in a few places, but there are a few more which need checks, HTTP refresh (bug 24739), IMG tags, and probably other tags which take an URL attribute. nsScriptSecurityManager::CheckLoadURI needs to be called in these places. nsbeta3.
Severity: critical → minor
Keywords: nsbeta3
Adding [nsbeta3-] notation, due to lower priority.
Whiteboard: [nsbeta3-]
Future.
Target Milestone: M17 → Future
Nominating for rtm.
Keywords: rtm
Pages that a user downloads to look at locally could conceivably exhibit this bug when following local relative URLs. So, there are probably still ways to cause this crash. It does seem like there should be a piece of code that sanity checks file paths at a fairly low level, perhaps in XPCOM or NSPR or NECKO, only for Win95/98. Of course, this requires that we know the complete list of illegal file path elements that cause the crash.
I was leaving this bug open as part of the file:// access issue, since blocking file:// for web content would cover up this problem. I figured that was good enough, because this is Microsoft's bug anyway, and apparently there's already a patch. If you think it's worth addressing at a lower level, though, we should probably also block the /dev/ directory on Unix machines. I tried a link to file:/// dev/zero. Seamonkey brought up a Save As dialog, and when I ckicked OK it happily started writing an infinitely large file of zeros. I imagine there are other surprises lurking in /dev/. Do we want to keep people from doing these dangerous things from local files, or is it enough to deny them to web content?
junruh, you didn't explain why you nominated this, could you do that? Have the file:// holes been plugged yet? If not, how serious are the remaining holes?
Whiteboard: [nsbeta3-] → [nsbeta3-][need info]
QA Contact: czhang → junruh
junruh or mstoltz, could you give a status update here? Do we have to do something for RTM here?
No longer reproducible. It may be a case of Netscape 6 being fixed, or my installing the critical updates package from Microsoft for Win98/95.
mstoltz, if you agree, pls mark [rtm-] or mark WFM.
I don't have a W98 machine to test on. I'll mark it WORKSFORME, can someone else pls. verify?
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Verified on 3 different Win98 machines.
Status: RESOLVED → VERIFIED
Keywords: crash
You need to log in before you can comment on or make changes to this bug.