Last Comment Bug 59767 - Loading file:// URLs with java - security policy discrepancy
: Loading file:// URLs with java - security policy discrepancy
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
P3 normal (vote)
: mozilla1.4beta
Assigned To: Mitchell Stoltz (not reading bugmail)
: ckritzer (gone)
: David Keeler [:keeler] (use needinfo?)
Depends on:
Blocks: clu
  Show dependency treegraph
Reported: 2000-11-10 12:36 PST by Mitchell Stoltz (not reading bugmail)
Modified: 2004-07-20 04:45 PDT (History)
19 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Tentative fix (4.62 KB, patch)
2003-03-31 17:56 PST, Mitchell Stoltz (not reading bugmail)
peterlubczynski-bugs: review+
hjtoi-bugzilla: superreview+
Details | Diff | Splinter Review

Description User image Mitchell Stoltz (not reading bugmail) 2000-11-10 12:36:08 PST
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> --------------------------
Comment 1 User image John Unruh 2000-11-14 10:19:33 PST
Mass changing QA to ckritzer.
Comment 2 User image Mitchell Stoltz (not reading bugmail) 2001-03-08 17:12:01 PST
Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.
Comment 3 User image Mitchell Stoltz (not reading bugmail) 2001-10-31 15:03:00 PST
Less important bugs retargeted to 0.9.9
Comment 4 User image Bradley Baetz (:bbaetz) 2001-11-10 07:26:30 PST
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.
Comment 5 User image Ben Bucksch (:BenB) 2001-11-12 05:59:31 PST
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?
Comment 6 User image Mitchell Stoltz (not reading bugmail) 2001-11-12 10:58:38 PST
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?
Comment 7 User image Ben Bucksch (:BenB) 2001-11-12 13:09:12 PST
> 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.
Comment 8 User image Joe Chou 2002-06-13 18:22:21 PDT
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.

Comment 9 User image Mitchell Stoltz (not reading bugmail) 2002-06-13 18:58:47 PDT
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.
Comment 10 User image Bradley Baetz (:bbaetz) 2002-06-13 20:59:21 PDT
Can they open chrome urls? Or javascript ones? If they run js ones, what
principal do we use?
Comment 11 User image Joe Chou 2002-06-18 10:42:42 PDT
Mitchell considered this is a Java bug, and requested to reassign this bug to
Java group.
Re-assign to Java plugin.

Comment 12 User image Zhengyu Gu 2002-06-20 10:19:47 PDT
Sun bugtraq: #4705348
Comment 13 User image Dennis Gu 2002-06-28 11:41:44 PDT
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.

Comment 14 User image Mitchell Stoltz (not reading bugmail) 2002-07-29 16:57:29 PDT
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.
Comment 15 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-18 11:50:58 PDT
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.
Comment 16 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-18 14:18:06 PDT
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.
Comment 17 User image georgi - hopefully not receiving bugspam 2002-10-03 02:34:08 PDT
Netscape 7 beta with java Java(TM) Plug-in 1.3.1_02-b02 
is still affected by this bug.
Comment 18 User image Peter Lubczynski 2002-10-15 12:05:49 PDT
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
Comment 19 User image Arun Ranganathan 2002-10-15 14:00:07 PDT
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? 
Comment 20 User image serge (gone) 2002-10-15 15:57:41 PDT
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
Comment 21 User image Peter Lubczynski 2002-10-15 17:37:04 PDT
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?
Comment 22 User image Mitchell Stoltz (not reading bugmail) 2002-10-31 15:01:19 PST
Patrick and I found the source of the problem - we should add a CheckLoadURI
call in the LiveConnect code. I'll handle this.
Comment 23 User image Mitchell Stoltz (not reading bugmail) 2003-02-20 14:49:34 PST
OK, the place we would need to add a check is at
nsPluginHostImpl::GetURLWithHeaders (thanks Patrick). 
Comment 24 User image Mitchell Stoltz (not reading bugmail) 2003-03-31 17:56:15 PST
Created attachment 119020 [details] [diff] [review]
Tentative fix

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?
Comment 25 User image Peter Lubczynski 2003-03-31 18:32:16 PST
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:
Comment 26 User image Mitchell Stoltz (not reading bugmail) 2003-04-01 10:53:26 PST
Comment on attachment 119020 [details] [diff] [review]
Tentative fix

Thanks, Peter, will do.

Heikki, can you sr?
Comment 27 User image Heikki Toivonen (remove -bugzilla when emailing directly) 2003-04-01 11:26:38 PST
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)
Comment 28 User image Mitchell Stoltz (not reading bugmail) 2003-04-02 16:16:44 PST
Bug 120373 will address your first point, and I'll fix the nit.
Comment 29 User image Mitchell Stoltz (not reading bugmail) 2003-04-03 13:36:48 PST
Fix checked in.
Comment 30 User image Daniel Veditz [:dveditz] 2004-07-20 04:45:58 PDT
Bugs published on the Known-vulnerabilities page long ago, removing confidential

Note You need to log in before you can comment on or make changes to this bug.