Closed Bug 59767 Opened 21 years ago Closed 18 years ago
Loading file:// URLs with java - security policy discrepancy
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.
Target Milestone: --- → mozilla1.0
Less important bugs retargeted to 0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9
Mass change: It appears that several bugs got accidentally opened up as part of a mass change - see bug 107718 (now fixed). Moving back to security-sensitive group. These were open for about 10 days.
Am I wrong or does this bug allow an attacker to read an arbiatry file on the hd? Shouldn't it be of much higher priority then?
No, it allows an applet to display file:// URLs on screen, not read their contents. This may have been fixed by now, anyone care to test it? Ben?
> it allows an applet to display file:// URLs on screen, not read their contents. I thought that the applet or the js code has access to everything displayed, using reflection, DOM or whatever. You say no - all the better. > This may have been fixed by now, anyone care to test it? Ben? I have no JRE installed. I'll probably do so soon and test this.
Target Milestone: mozilla0.9.9 → mozilla1.2
Status: NEW → ASSIGNED
CC list accessible: true
Accessible to reporter
I tried the test case with a little change in the html. For the URL, instead of "file:///c|/test.html", I changed it to "file://showdoc.html" (because a popup window saying could not find "file:///c|/test.html"). After the change, when I click on showdoc.html, wow, a directory tree was opened! With "file://showdoc.html/" in the location box, below is a portion of the page displayed, and I could go into each dir to open its files: adm 12/21/00 17:39:45 bin 04/17/02 13:29:04 ... Looks pretty scary to me. Did I do something wrong? I was using moz1.0 with JRE 1.4.1 on Solaris.
It's not that bad - just because the applet can open a window containing a local directory tree doesn't mean the applet can read data from that window, right? I'm not sure you did the test correctly. What you want to do is compile the applet, and put it and showdoc.html on a Web server (not your local drive). Put an html file on your local drive and replace file:///c|/test.html (in showdoc.html) with the file URL that points to your local html file. See if that local file gets opened in a new window.
Mitchell considered this is a Java bug, and requested to reassign this bug to Java group. Re-assign to Java plugin.
Assignee: mstoltz → James.Melvin
Status: ASSIGNED → NEW
Sun bugtraq: #4705348
This is not a security bug. Even the applet can open a window containing a local directory tree, the applet can't grep the content in the new window. Sun bug #4705348 will mark CLOSED.
This is an important bug for the reason Mitch gave when he opened it: we don't allow Web pages to load file: URLs into windows or frames, but Java is undermining that policy. The reason we don't allow it is because it reduces the impact of any same-origin bugs that may appear in the future. showDocument() should apply exactly the same same-origin checks that window.open does. Please reopen the Sun bug.
Note that all we need the JVM plugin to do is to call CheckLoadURI the same way our other document loaders do, which lets us control the security policy.
Netscape 7 beta with java Java(TM) Plug-in 1.3.1_02-b02 is still affected by this bug.
Plugins may have this problem too if they call NPN_GetURL (and friends) with a file:// URL. Perhaps nsPluginHostImpl::GetURLWithHeaders (and maybe POST??) needs the same kind of check window.open uses to prevent opening file URLs from http?
This is further to peterlubczynki's Comment 18: traditionally, NPAPI plugins (DLLs such as Flash) have not been restricted in what they can and cannot do via NPN_GetURL (or any other API call). Ought we implement the same-origin check only for Java? We can determine what kind of plugin is being invoked from MIME type. N4.x is prone to this via NPAPI plugins, and we've traditionally taken the stance that what you can do on a plugin is your business. Java has always been the exception for obvious reasons. Peter L., are you now advocating that we change this stance to include NPAPI plugins?
any plugins are running in browser proc, why we should disable NPN_GetURL (file:/// if in general plugin code can access any local resources available for mozilla process?
Well certainly a plugin has access to the local disk, but could scripting a plugin exploit a file:/// URL to be opened and read by untrusted JS? So I've been playing around with this with the NPAPI tester plugin: http://lxr.mozilla.org/mozilla/source/modules/plugin/tools/tester/testcase/index.html http://warp.mcom.com/u/peterlubczynski/testcases/frames/frame1.html I found that if I used NPN_GetURL to open a file:/// URL in a frame and use cross-frame scriping from an HTTP served frameset to access the DOM of the local document, I get: Permission denied to call method HTMLDocument.getElementsByTagName So it looks like even though a plugin can open a local URL, I think other security prevents access from remote pages, at least with framesets. If data can't be read from remote, what's the harm in allowing plugins to just show local files?
Patrick and I found the source of the problem - we should add a CheckLoadURI call in the LiveConnect code. I'll handle this.
Assignee: James.Melvin → mstoltz
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
OK, the place we would need to add a check is at nsPluginHostImpl::GetURLWithHeaders (thanks Patrick).
Status: NEW → ASSIGNED
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Some things I need to verify: 1. The security check function I added returns failure whenever one of the bits of data it needs is null. This is the safest way, but it may be overzealous. Are there any conditions under which the plugin instance peer, owner, document, document URL, or base URL will be null? What should we do in those cases? 2. I need a testcase of a non-Java plugin that calls GetURL, to make sure it works as before. 3. Does Java ever call PostURL? If so, I'd like to test that too. How would I invoke it? 4. Does Java ever call GetURL other than in response to a ShowDocument call? Do we need to make an exception for those cases?
Attachment #119020 - Flags: review?(peterlubczynski)
Comment on attachment 119020 [details] [diff] [review] Tentative fix You'll be fine with #1, I don't think any of those are ever null but maybe throw in an NS_WARNING just to be safe. For #2, try the tester plugin: http://lxr.mozilla.org/seamonkey/source/modules/plugin/tools/tester/ As for #3 and #4 I'm not really sure. Perhaps someone at Sun could help or maybe look at the 1.3.1 plugin source: http://peterl.mcom.com/builds/java131src/j2sdk1.3.1/ext/plugin/oji-plugin/src/m otif/navig5/
Attachment #119020 - Flags: review?(peterlubczynski) → review+
Comment on attachment 119020 [details] [diff] [review] Tentative fix Thanks, Peter, will do. Heikki, can you sr?
Attachment #119020 - Flags: superreview?(heikki)
My main issue with this patch is the added dependency to JS. I think we could avoid that. It seems like CheckLoadURI() function has no dependendy to JS, so could we create a new script security manager interface that has no dependency to JS, and use that where appropriate? We might be able to cut down some dependencies elsewhere as well! I would be ok to make that a separate bug (to be fixed within 1.4b timeframe) if alecf is ok with it. Nit: + nsresult rv2; + nsCOMPtr<nsIJVMPluginInstance> javaInstance(do_QueryInterface(instance, &rv2)); + + if (NS_SUCCEEDED(rv2)) Rewrite that as (2 instances): + nsCOMPtr<nsIJVMPluginInstance> javaInstance(do_QueryInterface(instance)); + + if (javaInstance)
Bug 120373 will address your first point, and I'll fix the nit.
18 years ago
Attachment #119020 - Flags: superreview?(heikki) → superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Bugs published on the Known-vulnerabilities page long ago, removing confidential flag.
You need to log in before you can comment on or make changes to this bug.