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

Status: RESOLVED FIXED

(Core :: Security, defect, P3)

Description

[Mitchell Stoltz (not reading bugmail)]

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

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

public class showdoc extends Applet {

public void start()
{
  try
   {
   URL u=new URL(getParameter("URL"));
   getAppletContext().showDocument(u,"A");
   }
    catch(Exception x){System.out.println(x.toString());}
}
}
--------------------------

--showdoc.html------------
<APPLET CODE="showdoc.class" WIDTH=700 HEIGHT=300 MAYSCRIPT> <PARAM NAME="URL"
VALUE="file:///c|/test.html"> </APPLET> --------------------------

Comment 1

[John Unruh]

Mass changing QA to ckritzer.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Less important bugs retargeted to 0.9.9

Comment 4

[Bradley Baetz (:bbaetz)]

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

[Ben Bucksch (:BenB)]

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

[Mitchell Stoltz (not reading bugmail)]

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

[Ben Bucksch (:BenB)]

> 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

[Joe Chou]

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

[Mitchell Stoltz (not reading bugmail)]

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

[Bradley Baetz (:bbaetz)]

Can they open chrome urls? Or javascript ones? If they run js ones, what
principal do we use?

Comment 11

[Joe Chou]

Mitchell considered this is a Java bug, and requested to reassign this bug to
Java group.
Re-assign to Java plugin.

Comment 12

[Zhengyu Gu]

Sun bugtraq: #4705348

Comment 13

[Dennis Gu]

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

[Mitchell Stoltz (not reading bugmail)]

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

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[georgi - hopefully not receiving bugspam]

Netscape 7 beta with java Java(TM) Plug-in 1.3.1_02-b02 
is still affected by this bug.

Comment 18

[Peter Lubczynski]

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?

Comment 19

[Arun Ranganathan]

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

[serge (gone)]

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?

Comment 21

[Peter Lubczynski]

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?

Comment 22

[Mitchell Stoltz (not reading bugmail)]

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

[Mitchell Stoltz (not reading bugmail)]

OK, the place we would need to add a check is at
nsPluginHostImpl::GetURLWithHeaders (thanks Patrick). 

Comment 24

[Mitchell Stoltz (not reading bugmail)]

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

[Peter Lubczynski]

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/

Comment 26

[Mitchell Stoltz (not reading bugmail)]

Comment on attachment 119020 [details] [diff] [review]
Tentative fix

Thanks, Peter, will do.

Heikki, can you sr?

Comment 27

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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)

Comment 28

[Mitchell Stoltz (not reading bugmail)]

Bug 120373 will address your first point, and I'll fix the nit.

Comment 29

[Mitchell Stoltz (not reading bugmail)]

Fix checked in.

Comment 30

[Daniel Veditz [:dveditz]]

Bugs published on the Known-vulnerabilities page long ago, removing confidential
flag.