620773 - java.security.AccessControlException when calling privileged Java methods from chrome

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Simon Kornblith]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_5; en-us) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101221 Firefox/4.0b9pre

On mozilla-central nightlies from 11/20/10 on, it appears that the global java object is no longer privileged when it is accessed from chrome code. This will break Firefox extensions that rely upon executing privileged Java methods. I've confirmed that this issue exists on mozilla-central on OS X and Linux. mozilla-1.9.2 on Linux also seems to be affected, although mozilla-1.9.2 on Mac OS X is not. I have not tested on Windows. This probably has something to do with bug 611910 and its associated patches.

Reproducible: Always

Steps to Reproduce:
Run new java.net.URLClassLoader([]); from a chrome URI. (Simple XUL file is attached.)
Actual Results:  
The following error is thrown:

java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader)



Expected Results:  
Code should run without error.

Comment 1

[Simon Kornblith]

Attachment: Simple XUL file that will produce error (must be loaded from chrome://)

Comment 2

[Benjamin Smedberg]

This is probably a result of using the NPRuntime java, instead of OJI, and is either intentional or not likely to be fixed.

Comment 3

[Simon Kornblith]

It works in all released Firefox 3.6 versions and it also works on the 11/19/10 mozilla-central nightly, but not the 11/20/10 mozilla-central nightly, so it seems like the regression is too recent to attribute to the NPRuntime switch. OTOH, I don't know whether this is an intentional side effect of the fix for bug 611910.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> OTOH, I don't know whether this is an intentional side effect of the
> fix for bug 611910.

I'll add some debugging code to my patch for bug 611910 and test with
it using your testcase (probably tomorrow).  That should give me a
better idea whether or not your testcase should be allowed to "work".

Comment 5

[Simon Kornblith]

Great. I should probably add that, on mozilla-central, you need to disable out-of-process Java or the global java object will be undefined and this won't work at all (see bug 563891/bug 573180).

Comment 6

[Simon Kornblith]

Attachment: Patch v1

This appears to fix the issue. I don't know whether there are security ramifications, since I don't have access to bug 611910.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> Simple XUL file that will produce error (must be loaded from chrome://)

Sorry for my ignorance.  How do you load this "from chrome://"?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Attachment: Extension that allows loading local files "from chrome://"

> Sorry for my ignorance.  How do you load this "from chrome://"?

Never mind, I've figured it out.

Here's an extension which, after you install it, lets you use
chrome://tests/content/[filename] to load
file:///tmp/testfiles/[filename].  I modified it slightly from one
posted by Martijn Wargers at bug 576332 comment #14.

I've used it to confirm this bug report.  But now I've run out of
time, and haven't been able to do any more.  I'll pick this bug up
once again after I come back from Christmas vacation (in about a
week).

Comment 9

[Steven Michaud [:smichaud] (Retired)]

What follows are (more or less) notes to myself, reminding me of what
needs to be done after I get back from Christmas vacation:

I've just discovered something I hadn't realized before --
Sun/Oracle/Apple's Java plugin has handlers for "chrome://" URLs (in
deploy/src/common/share/classes/com/sun/deploy/net/protocol/chrome/,
in deploy.jar).  (Deploy.jar also has handlers in the same general
location for "about://", "javascript://", and "rmi://" URLs.)

Before I do anything else on this bug, I'll need to figure out how the
Java plugin handles these URLs, and what the security implications are
of that.  Only then will I be able to tell whether or not we can add
"chrome://" (or any of these other URL schemes) to our URL scheme
whitelist (in nsNetUtil.h's NS_CheckIsJavaCompatibleURLString()).

Comment 10

[Simon Kornblith]

This bug will break the code at https://developer.mozilla.org/en/Java_in_Firefox_Extensions and all Firefox extensions that use Java, in a point release. Is there a possibility of blocking 1.9.2.14 on this? Pending further knowledge of the security implications of permitting these accesses, either this should be fixed, or it should be explicitly documented that Java Firefox extensions will no longer be supported.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

I will do my best to fix this bug (once I get back from Christmas
vacation) ... but first (as I've said) I myself need to understand the
security implications of fixing it.

> This bug will break the code at
> https://developer.mozilla.org/en/Java_in_Firefox_Extensions and all
> Firefox extensions that use Java, in a point release.

By the way, it will only break extensions that use privileged
JavaScript-to-Java LiveConnect (not those that don't require special
access).  It might help to post a list of the most popular Firefox
extensions that use Java and require privileged access.

Comment 12

[Simon Kornblith]

This won't break Firefox extensions that embed Java applets, but any Firefox extension that loads a class out of a jar file using the global java object will be affected, since creating a class loader requires privileges. AFAIK, virtually every Firefox extension that makes use of Java functionality via JavaScript-to-Java LiveConnect does this, whether or not the loaded Java code needs privileges, simply because it's a much more elegant solution than loading a hidden Java applet.

Our extension (Zotero OpenOffice Integration) has approximately 16,000 active installations (based on our update.rdf requests). The CNRI Handle Extension (http://www.handle.net/hs-tools/extensions/firefox_hdlclient.html) would also break, as would XqUSEme (https://addons.mozilla.org/en-US/firefox/addon/5515/) and Firegoose (http://gaggle.systemsbiology.net/docs/geese/firegoose/). Piggy Bank (http://simile.mit.edu/wiki/Piggy_Bank) also used Java, but it seems as though it was never updated for Firefox 3.5+. The extensions mentioned in bug 563891 are also likely to be affected, unless they don't load any classes. There are probably others as well, but these are what I know off the top of my head.

Comment 13

[LegNeato]

We'll want this fixed for .14 (the next 1.9.2 release). It would be bad to ship this regression.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Attachment: Trunk patch

Simon, here's a variant of your patch that updates the comments on
NS_CheckIsJavaCompatibleURLString().  This patch is only suitable for
the trunk (where we've dropped support for the OJI plugin).  I'll post
branch patches in later comments.

As best I can tell, it's safe to add "chrome://" URLs to our URL
scheme whitelist for Java Plugin2 (though not for the OJI plugin):

Java Plugin2 does understand "chrome://" URLs, and does (deliberately)
grant enhanced permissions to code whose "origin" is a "chrome://" URL
(in JavaNameSpaceDelegate.getJSProtectionDomain(URL url), in
/deploy/src/plugin/share/classes/sun/plugin2/main/client/LiveConnectSupport.java).
Since "chrome://" URLs are invariably privileged in Mozilla browsers,
this seems to be legitimate.

So the only remaining question is can someone (or some code) fake
having a "chrome://" origin without legitimately having been granted
enhanced privileges by Mozilla's security infrastructure.  I'm pretty
sure the answer is "no".  But I'm not an expert in this, so others
should correct me if I'm wrong.

Note that Java Plugin2 (unlike the browser-side OJI/LiveConnect code
called by the OJI plugin) no longer uses CAPS interfaces to find the
current script's security principal.  So it can no longer check
whether or not this is the system principal.  As best I can tell, Java
Plugin2's only way (in Mozilla browsers) to find out whether or not
it's running in "system code" is to check whether or not the code's
origin is a "chrome://" URL.

I'm making tryserver builds of this patch.  But the tryservers seem to
be having trouble, so I'm not sure when these builds will be ready.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Attachment: Branch patch

Here's a patch that only adds "chrome://" URLs to the Java URL
whitelist for Java Plugin2 (not for the OJI plugin).

This doesn't leave this bug partially unfixed, because this bug
doesn't effect the OJI plugin:

nsCSecurityContext::GetOrigin() does return a "fake" origin for
"chrome://" URLs.  But this result gets overridden by other code that
checks whether or not the current subject principal is the system
principal.  The nsCSecurityContext constructor makes this check, and
if it passes sets nsCSecurityContext.m_HasUniversalJavaCapability to
PR_TRUE.  Then when nsCSecurityContext::Implies() gets called
(indirectly) from the OJI plugin with 'target' set to
"UniversalJavaPermission", *bAllowedAccess always gets set to PR_TRUE.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

> This doesn't leave this bug partially unfixed, because this bug
> doesn't effect the OJI plugin:

It doesn't effect the JEP, either.  The JEP never calls
nsCSecurityContext::GetOrigin(), and always (on every
JavaScript-to-Java call) checks whether or not the current script
principal is the system principal.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

It's conceivable that (in the future) we'll want to add other schemes
(ones that Java understands) to our Java scheme whitelist.

For example I mentioned in my revised comments (to
NS_CheckIsJavaCompatibleURLString()) that Java Plugin2 seems to handle
"about" URLs correctly.  And I've discovered a place (in code common
to both Java Plugin2 and the OJI plugin) where privileges are added to
connect to and receive connections from the "host" (if any) in a
"jar:" URL.  (This code is in URLClassLoader.getPermissions() in
j2se/src/share/classes/java/net/URLClassLoader.java.  This class and
method are both documented.  An example of a "jar:" URL that has a
"host" is 'jar:http://www.foo.com/bar/baz.jar!/'.)

But I'd prefer not to do this until we know that it's necessary.

It's difficult to know for sure what are the implications of adding a
particular scheme to the Java scheme whitelist.  So I'd like to have
good reasons for doing so.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 501453 [details] [diff] [review]
Trunk patch

Here are tryserver builds made with my patch from comment #14:

Linux
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-b36b0842474b/try-lnx/firefox-4.0b9pre.en-US.linux-i686.tar.bz2

Linux (64-bit)
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-b36b0842474b/try-lnx64/firefox-4.0b9pre.en-US.linux-x86_64.tar.bz2

OS X
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-b36b0842474b/try-osx64/firefox-4.0b9pre.en-US.mac64.dmg

Windows
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-b36b0842474b/try-w32/firefox-4.0b9pre.en-US.win32.zip

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 501453 [details] [diff] [review]
Trunk patch

r=me

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 501468 [details] [diff] [review]
Branch patch

r=me.

The sadmakingness of java never ceases.  :(

Comment 21

[Steven Michaud [:smichaud] (Retired)]

I'm told jst is unlikely to be able to review these patches anytime
soon.  So I'm going to land my branch patch on the 1.9.2 branch, and
seek approval for the trunk and 1.9.1 branches.

If jst finds a problem, we can deal with that later.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 501468 [details] [diff] [review]
Branch patch

Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/138b83e93dff

Comment 23

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 501453 [details] [diff] [review]
Trunk patch

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/f8330dec502b

Comment 24

[Steven Michaud [:smichaud] (Retired)]

Marking this bug FIXED, even though it hasn't yet been fixed on the 1.9.1 branch.

Comment 25

[Al Billings [:abillings - ex-MoCo]]

(In reply to comment #0)

> Steps to Reproduce:
> Run new java.net.URLClassLoader([]); from a chrome URI. (Simple XUL file is
> attached.)
> Actual Results:  
> The following error is thrown:
> 
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission createClassLoader)


Where does this output appear within Firefox or do I need to use a debug build and look in console output? This is on OS X 10.6.6.

Comment 26

[Simon Kornblith]

The error appears in the error console, provided that javascript.options.showInConsole is set to true. On mozilla-central, devtools.errorconsole.enabled may also need to be set to true.

Comment 27

[Al Billings [:abillings - ex-MoCo]]

(In reply to comment #26)
> The error appears in the error console, provided that
> javascript.options.showInConsole is set to true.

I set this in my Firefox 3.6.13 on OS X. I load the test.xul file using the extension that lets me load it from my /tmp directory. I get an alert stating "success" but nothing in my error console.

Comment 28

[Steven Michaud [:smichaud] (Retired)]

You'll probably need to do this:

Run Applications : Utilities : Java Preferences.
Click on the Advanced tab.
Under "Java console" choose "Show console"

Comment 29

[Steven Michaud [:smichaud] (Retired)]

Also note that you need to test with Java Plugin2, not the JEP that you're currently testing with.

To make branch FF use Java Plugin2 on OS X, remove the following from your distro's Contents/MacOS/plugins directory:

MRJPlugin.plugin
JavaEmbeddingPlugin.bundle

Comment 30

[Daniel Veditz [:dveditz]]

(In reply to comment #22)
> Landed on the 1.9.2 branch:
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/138b83e93dff

Branches always require explicit approval, even blockers. This has not changed in years.

Comment 31

[Daniel Veditz [:dveditz]]

Comment on attachment 501468 [details] [diff] [review]
Branch patch

Approved for 1.9.1.17, a=dveditz for release-drivers

retroactive a1.9.2.14+

Comment 32

[Steven Michaud [:smichaud] (Retired)]

> Branches always require explicit approval, even blockers. This has not changed
> in years.

Sorry, I'd forgotten.  I guess it's been a while since I landed a branch patch for a branch blocker.

Comment 33

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 501468 [details] [diff] [review]
Branch patch

Landed on the 1.9.1 branch:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9377dc785159

Comment 34

[Henno Täht]

This seems to be the only Java security related change in 3.6.14.

After upgrading from 3.6.13 to 3.6.14 our customer's Java applet which is responsible for printing to a specialized Zebra ticket printer displayed black canvas and the following lines appeared to a Java console:

exception: Permission denied: null.
java.lang.SecurityException: Permission denied: null
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Exception: java.lang.SecurityException: Permission denied: null
java.net.MalformedURLException: no protocol: /java/PrintApplet.jar?1285551055
	at java.net.URL.<init>(Unknown Source)
	at java.net.URL.<init>(Unknown Source)
	at sun.plugin.util.GrayBoxPainter.setProgressFilter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.setupGrayBoxPainter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.showAppletException(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I confirmed that downgrading to 3.6.13 makes the problem go away. Java itself is 1.6.0_24-b07 (no change).

Can anyone shed some light on this?

Comment 35

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #34)

> This seems to be the only Java security related change in 3.6.14.

Actually, the patch for bug 611910 is much more likely to have
triggered this problem.

The patch for bug 611910 landed on the 1.9.2 branch on 2010-11-22, so
it will appear in nightlies dated 2010-11-23 or later.

The patch for bug 620773 landed on the 1.9.2 branch on 2011-01-10.

Please test with the relevant nightlies to find the regression range.

Comment 36

[Steven Michaud [:smichaud] (Retired)]

Henno, please open a new bug on your problem and cc me.

We'll need a publicly accessible testcase that reproduces the problem
-- otherwise it's unlikely that we'll be able to fix it.

Comment 37

[Ananth Vasudevan]

Hi,

We also have some issues with our Java applets after upgrading to 3.6.14. We use LiveConnect and below is the exceptions that we get:

netscape.javascript.JSException: JavaScript error while getting property "document"
	at sun.plugin2.main.client.MessagePassingJSObject.newJSException(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.waitForReply(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.doMemberOp(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.getMember(Unknown Source)
	at sun.plugin2.main.client.MessagePassingExecutionContext.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getCodeBase(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.verifyJarVersions(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.getClassLoaderCacheEntry(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.getAppletAppContext(Unknown Source)
	at sun.plugin2.main.client.PluginMain.handleMessageStartApplet(Unknown Source)
	at sun.plugin2.main.client.PluginMain.mainLoop(Unknown Source)
	at sun.plugin2.main.client.PluginMain.run(Unknown Source)
	at sun.plugin2.main.client.PluginMain.main(Unknown Source)

Ignored exception: java.lang.IllegalArgumentException: name
netscape.javascript.JSException: JavaScript error while getting property "document"
	at sun.plugin2.main.client.MessagePassingJSObject.newJSException(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.waitForReply(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.doMemberOp(Unknown Source)
	at sun.plugin2.main.client.MessagePassingJSObject.getMember(Unknown Source)
	at sun.plugin2.main.client.MessagePassingExecutionContext.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getDocumentBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.getCodeBase(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.setupGrayBoxPainter(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager.access$600(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I'll try to get an example of the applet tags that we use and live connect calls.

I'm actually seeing the following exception in one of out applets where we don't use LiveConnect. It happens when you open the applet (we open the applet as a popup in a new window), then close the applet and hit refresh to reload the applet again:

ava.lang.IllegalArgumentException: name
	at sun.plugin2.applet.Applet2ClassLoader.addJar(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.loadJarFiles(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Comment 38

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #37)

Please open a new bug and cc me.

In the new bug, be sure to provide a publicly accessible testcase (with sourcecode).

Comment 39

[LegNeato]

(In reply to comment #38)
> Please open a new bug and cc me.

The bug covering the regression is bug 629030. Please move conversations about that problem to the new bug -- thanks!

Comment 40

[LegNeato]

I backed this out of 1.9.2: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/621313245c42

Comment 41

[Daniel Veditz [:dveditz]]

(In reply to comment #37)
> We also have some issues with our Java applets after upgrading to 3.6.14. We
> use LiveConnect and below is the exceptions that we get:
> 
> netscape.javascript.JSException: JavaScript error while getting property
> "document"

Anath: your error message is completely different than the others reported here, and looks much more like I'd expect from something that ran afoul of bug 611910 rather than the patch in this bug. That bug creates a whitelist of protocol schemes that we know Java understands; it's possible you're using an uncommon one that we did not test.

Comment 42

[Ananth Vasudevan]

Hi Daniel,

Sorry for the late response.

Our web application loads an applet after the user logs in with his credentials. Once the clicks on the "logout" link to logout the applet gets unloaded/destroyed and tries to log in back using the same browser instance, the applet doesn't load with the exceptions I posted above. The user has to close all open Firefox instances and launch a new one. This was not the behavior before 3.6.14, the same browser could be used to load the same applet again.

As an example, please try the following:

Open a new TAB in Firefox 3.6.14 and Go to this URL to use the Java Applet and click on this link "test the currently installed version of Java":

http://www.java.com/en/download/testjava.jsp

Applet is loaded and works fine. Now close the tab and open a new TAB and go to same URL and try to load the applet:

You'll see a "General Exception" and the Applet is not loaded with the following when you click the details button:

java.lang.IllegalArgumentException: name
	at sun.plugin2.applet.Applet2ClassLoader.addJar(Unknown Source)
	at sun.plugin2.applet.Applet2Manager.loadJarFiles(Unknown Source)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Comment 43

[Daniel Veditz [:dveditz]]

Comment on attachment 501468 [details] [diff] [review]
Branch patch

We took this out of 3.6.14 and released 3.6.15 without this patch in case this was the cause of the Java failures.