Closed Bug 9419 Opened 26 years ago Closed 25 years ago

Security vulnerability - parsing local non HTML files

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: joro, Assigned: morse)

References

(
URL
)

Details

There is a security vulnerability in Mozilla 5.0 M7 Win95 (guess all platforms) which allows executing of JavaScript code in the "file:" protocol. The problem is parsing local non HTML files and executing JavaScript code in them. This is achieved by URLs of the type: "file://c:/users50/mozProfile/cookies.txt?<A></A>.html" - Mozilla treats such URLs as HTML files even though the real file extension is not .html or .htm. One may inject a cookie with JS code in it and then parse the local cookies.txt Demonstration is available at: http://www.nat.bg/~joro/cookie50.html The demonstration assumes: 1) JavaScript is enabled 2) Cookies are enabled 3) The user directory is: c:/users50/mozProfile/ Possible vulnerabilities: browsing local directories, probably reading local files.
Target Milestone: M11
Blocks: 12633
Component: Browser-General → Security
QA Contact: leger → dshea
Updating component
Component: Security → Necko
Is this due to a Necko parsing problem?
Assignee: norris → gagan
Status: ASSIGNED → NEW
Assignee: gagan → neeti
Neeti is the cookies owner.
Assignee: neeti → morse
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
If I understand the bug report correctly, there is a demo page which will inject a cookie containing html code into the cookies file and open the cookies file in the browser. And when this happens, the html code in the cookie will execute So I copied the demo file, edited it to reflect where my actual cookies file is, and saved it away on my hard disk. Then I brought up that saved page in the 5.0 browser. It did indeed write the html cookie into the cookies file, and it did indeed open the cookies.txt file in the browser. But that was all. Nothing further happened at this point. The screen was blank. As a sanity check, I tried the same test in the 4.x browser. Lo-and-behold, the screen now contained a display of the entire cookies file, just as this bug report said it would. So the bug is definitely in the 4.x browser. But it is not in 5.0. Marking this as works-for-me. I presume someone has opened an equivalent bug in the 4.x bug-tracking system (bugsplat).
The bug is still present in Mozilla 5.0 build 1999092508. There are some changes since M7 which prevented the bug from working. Now I have updated the demonstration page, so the exploit works on build 1999092508. Please check it again.
Status: RESOLVED → REOPENED
Yep, with the revised demo page the bug is once again present in 5.0. How could I have doubted Guninski, he's never let us down before. Reopening bug report. Will investigate further.
Status: REOPENED → ASSIGNED
Resolution: WORKSFORME → ---
Simplified test case. Put the contents shown below into a local file, edit it so that the path indicated points to your actual cookie file, and then bring the page up in the browser. You will get the "Oops" message indicating that you are executing the javascript in the cookies.txt file. <html> <head> <script> document.cookie= "j3=<SCRIPT>alert('Oops')</" + "SCRIPT>; expires=Tuesday, 01-Apr-2000 08:00:00 GMT"; </script> </head> <body> <A HREF='file:///y|/mozilla/dist/users50/morse/cookies.txt?<A></A>.html'> Click here to test </A> </body> </html>
This bug is acually worse than what has been reported. You don't even need to do the trickery that fools the file: protocol into thinking you have an html file. Simply replacing the href line in the simplified test case with the following will also demonstrate the bug. <A HREF='file:///y|/mozilla/dist/users50/morse/cookies.txt'>
I just checked this in 4.x. There we are indeed restricted to an html file so the trickery of cookies.txt?<A></A>.html is required. But in 5.x the bug is much worse whereby javascript code can be executed from any file extension at all (I just tried it using an arbitrary extension and it also executed).
I just reported this more general bug. It's bug 14981
Depends on: 14981
Target Milestone: M11 → M14
This bug is blocked by bug 14981. Since I don't expect that bug to be fixed in M11, I have to later this bug.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Target Milestone: M14 → M15
Well if the bug I'm depending on (14981) just changed from to M15, I have to change this one as well. I wish we didn't keep routinely changing tfv's of bugs -- we should make a realistic estimate of the tfv initially and then slip it only in unusual and justifiable circumstances.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → WORKSFORME
Surprise, surprise. I just tested out my dependency bug (bug 14981) and it appears to be working even though the bug report was never closed out. So now I retried this bug. And it works too. By that I mean that the javascript doesn't work, which is the correct behavior. Clicking on the button on either Guninski's test page or with the simplified test case that I put in this report does not give the alert message. If I try the same thing in 4.x I do get the message. So the bug is in 4.x but not in 5.0. I'm closing this out as works for me. But I've been wrong on that once before. So if I'm confusing something and it really is still a problem, please feel free to reopen it again (I won't be offended).
Verified worksforme.
No longer blocks: 12633
Status: RESOLVED → VERIFIED
No longer depends on: 14981
You need to log in before you can comment on or make changes to this bug.