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

RESOLVED FIXED in mozilla1.4beta

Status

()

Core
Security
P3
normal
RESOLVED FIXED
17 years ago
13 years ago

People

(Reporter: Mitchell Stoltz (not reading bugmail), Assigned: Mitchell Stoltz (not reading bugmail))

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.4beta
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:mustfix])

Attachments

(1 attachment)

4.62 KB, patch
Peter Lubczynski
: review+
Heikki Toivonen (remove -bugzilla when emailing directly)
: superreview+
Details | Diff | Splinter Review
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

17 years ago
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
(Assignee)

Comment 2

17 years ago
Mass changing milestone to Moz1.0 - stuff targeted for late spring/early summer.
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 3

16 years ago
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?

Comment 5

16 years ago
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?

Updated

16 years ago
Whiteboard: [was-public][file-access]
(Assignee)

Comment 6

16 years ago
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

16 years ago
> 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.
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.2
(Assignee)

Updated

15 years ago
Status: NEW → ASSIGNED
CC list accessible: true
Accessible to reporter
Whiteboard: [was-public][file-access]

Comment 8

15 years ago
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.


(Assignee)

Comment 9

15 years ago
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?

Comment 11

15 years ago
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

Comment 12

15 years ago
Sun bugtraq: #4705348

Comment 13

15 years ago
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.

(Assignee)

Comment 14

15 years ago
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 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.
Whiteboard: [sg:mustfix]

Comment 18

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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?
(Assignee)

Comment 22

15 years ago
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
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
(Assignee)

Updated

15 years ago
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
(Assignee)

Comment 23

15 years ago
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
(Assignee)

Updated

15 years ago
Blocks: 193255
(Assignee)

Comment 24

15 years ago
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?
(Assignee)

Updated

15 years ago
Attachment #119020 - Flags: review?(peterlubczynski)

Comment 25

15 years ago
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+
(Assignee)

Comment 26

15 years ago
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)
(Assignee)

Comment 28

15 years ago
Bug 120373 will address your first point, and I'll fix the nit.
Attachment #119020 - Flags: superreview?(heikki) → superreview+
(Assignee)

Comment 29

15 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Bugs published on the Known-vulnerabilities page long ago, removing confidential
flag.
Group: security
You need to log in before you can comment on or make changes to this bug.