Closed Bug 59767 Opened 21 years ago Closed 18 years ago

Loading file:// URLs with java - security policy discrepancy


(Core :: Security, defect, P3)






(Reporter: security-bugs, Assigned: security-bugs)


(Blocks 1 open bug)


(Whiteboard: [sg:mustfix])


(1 file)

It is possible to load file:// URLs using java's showDocument() while it
is not possible to load such urls using javascript's

The code is:
import java.applet.Applet;
import netscape.javascript.*;

public class showdoc extends Applet {

public void start()
   URL u=new URL(getParameter("URL"));
    catch(Exception x){System.out.println(x.toString());}

VALUE="file:///c|/test.html"> </APPLET> --------------------------
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
Group: netscapeconfidential?
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.
Group: security?
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?
Whiteboard: [was-public][file-access]
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
CC list accessible: true
Accessible to reporter
Whiteboard: [was-public][file-access]
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.
Can they open chrome urls? Or javascript ones? If they run js ones, what
principal do we use?
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
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.

Please try opening the URL "javascript:alert(Components.classes)" using this
method. If you see an alert, that indicates a serious security bug, because it
means URLs opened by Java in this manner are running with full system
privileges. What you should see instead is na exception in the Javascript
console window.
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
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 uses to prevent opening file URLs from
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
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:

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). 
Target Milestone: mozilla1.4alpha → mozilla1.4beta
Blocks: clu
Attached patch Tentative fixSplinter Review
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:

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:
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.


+    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.
Attachment #119020 - Flags: superreview?(heikki) → superreview+
Fix checked in.
Closed: 18 years ago
Resolution: --- → FIXED
Bugs published on the Known-vulnerabilities page long ago, removing confidential
Group: security
You need to log in before you can comment on or make changes to this bug.