Closed
Bug 9419
Opened 25 years ago
Closed 25 years ago
Security vulnerability - parsing local non HTML files
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
M15
People
(Reporter: joro, Assigned: morse)
References
()
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Updated•25 years ago
|
Target Milestone: M11
Updated•25 years ago
|
Component: Security → Necko
Comment 2•25 years ago
|
||
Is this due to a Necko parsing problem?
Updated•25 years ago
|
Assignee: norris → gagan
Status: ASSIGNED → NEW
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 4•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Assignee | ||
Comment 6•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Resolution: WORKSFORME → ---
Assignee | ||
Comment 7•25 years ago
|
||
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>
Assignee | ||
Comment 8•25 years ago
|
||
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'>
Assignee | ||
Comment 9•25 years ago
|
||
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).
Assignee | ||
Comment 10•25 years ago
|
||
I just reported this more general bug. It's bug 14981
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M14
Assignee | ||
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14 → M15
Assignee | ||
Comment 13•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 14•25 years ago
|
||
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).
You need to log in
before you can comment on or make changes to this bug.
Description
•