Closed Bug 240323 Opened 20 years ago Closed 11 years ago

java.security.AccessControlException: access denied when using applet

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: erin.treacy, Assigned: alfred.peng)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316

This bug is related to bug 146458.  When a fix was introduced for bug 146458, a 
new bug was introduced.  I am including comments from that bug here.  This bug 
prevents us from certifying one of our products at Oracle on Netscape
7/Mozilla/Firefox. We would like to move users from Netscape 4.x but cannot 
because of this issue.  

------- Additional Comment #91 From John Busfield 2004-03-19 14:19 PDT [reply] -
------ 
I just downloaded Mozilla 1.7b to check this bug fix. The 
OriginNotAllowedException no longer occurs. However there is now a new security 
exception for applets that open sockets back to the server from which they 
came. 
java.security.AccessControlException: access denied (java.net.SocketPermission 
live01.mediaplatform.com resolve)

The setup under which this occurs is:
1. The html page comes from a.com. 
2. The page embeds an applet from b.com. 
3. The applet tries to open a socket back to b.com, to the exact server that 
served the applet. 
4. The above security exception occurs.

Here is a test link that shows the error 
http://musedev.ivtweb.com/Test/appletfail.htm

Notice that the applet's codebase is live01.mediaplatform.com and it tries to 
open a socket back to live01.mediaplatform.com. This should be an allowed 
behavior of an applet regardless of the url of the page in which the applet 
exists. This page works correctly in both IE and Netscape 4.x.


------- Additional Comment #92 From Kyle Yuan 2004-03-19 15:43 PDT [reply] -----
-- 
Could you modify the applet's codebase from http://live01.mediaplatform.com/v203
to http://live01.mediaplatform.com and try again?

------- Additional Comment #93 From John Busfield 2004-03-19 15:53 PDT [reply] -
------ 
(In reply to comment #92)
> Could you modify the applet's codebase from 
http://live01.mediaplatform.com/v203
> to http://live01.mediaplatform.com and try again?

That same page's applet now has a codebase of http://live01.mediaplatform.com. 
It is still failing. I also tested putting the html page on a server in the 
same domain (although not on the same server). The error still occurred.



------- Additional Comment #94 From Brendan Eich 2004-03-19 18:37 PDT [reply] --
----- 
comment 91 through comment 93 belong in a different bug, please.

/be

------- Additional Comment #95 From Daniel Veditz 2004-03-19 21:59 PDT [reply] -
------ 
Why a different bug? The new symptoms are the flip side of this same problem,
our internal requirement that the page and applet be in the same domain. Now
a.com can talk to the b.com applet but it still can't *use* it (assume
non-trivial applet, otherwise it could just be copied to a.com) since the applet
no longer knows its true home.

Unless maybe they should go into the "remove hack" bug 237385 mentioned in
comment 88

------- Additional Comment #96 From Kyle Yuan 2004-03-20 16:21 PDT [reply] -----
-- 
re comment 95, I'm pretty sure this is a applet or java plugin bug, rather than
a mozilla bug. And bug 237385 can't help on this too.

re comment 93, could you use appletviewer to access the same page? If it is
still failing, the problem should not belong to neither mozilla nor java plugin.
If you send the simplified applet source code or post it in n.p.m.java, I can
help you to find out where the problem is.

------- Additional Comment #97 From Erin 2004-03-22 07:42 PDT [reply] ------- 
I downloaded 1.7b and I am also getting this new Security exception. 

  java.security.AccessControlException: access denied 
(java.net.SocketPermission resolve)
at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:270)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1042)
at sun.plugin.net.protocol.http.HttpURLConnection.checkPermission
(HttpURLConnection.java:193)
at sun.plugin.net.protocol.http.HttpURLConnection.connect
(HttpURLConnection.java:144)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream
(HttpURLConnection.java:516)


------- Additional Comment #98 From John Busfield 2004-03-22 10:20 PDT [reply] -
------ 
(In reply to comment #96)
The applet is not the problem. This applet is confirmed to work in both IE and 
Netscape 4.7 and is currently used in our production environment.

I believe that this issue belongs under the same bug and not as a new bug 
because I believe the code that was modified to fix the 
OriginNotAllowedException created this bug. The reason I say this is that in 
previous Mozilla versions we had a workaround where, by setting DNS entries in 
our HOSTS files, we could trick the applet into working. This workaround was 
not a solution for our customers because we could not ask our customers to 
modify their HOSTS files, but it did clarify the problem for us internally. 
Also, in the previous Mozilla versions, when the HOSTS file was modified we 
were able to make the connection back to the server that served the applet.  In 
the 1.7b release however, this connection is no longer possible. So unless 
there was some other security code that was modified for this release, it seems 
that the most likely conclusion would be that the change made to fix this bug 
has caused new problems.




------- Additional Comment #99 From Kyle Yuan 2004-03-22 19:58 PDT [reply] -----
-- 
This bug has already been closed. Please file another bug for this regression,
and a *simple* testcase is highly appreciated.

------- Additional Comment #100 From Stig Nygaard 2004-03-27 03:58 PDT [reply] -
------ 
I had hoped this would fix my problems with logging on to the Netbank of Danske
Bank (www.danskebank.dk / netbank.danskebank.dk), but with Mozilla 1.7b I get
simelar errors to those described in comment #91 and comment #97.

JavaScript Console:
-------------------
Error: uncaught exception: java.security.PrivilegedActionException:
java.security.PrivilegedActionException: 
java.lang.reflect.InvocationTargetException

Java Console:
-------------
java.security.PrivilegedActionException: 
java.lang.reflect.InvocationTargetException

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.plugin.liveconnect.SecureInvocation$2.run(Unknown Source)

	at java.security.AccessController.doPrivileged(Native Method)

	at sun.plugin.liveconnect.SecureInvocation.CallMethod(Unknown Source)

	at sun.plugin.liveconnect.SecureInvocation.access$300(Unknown Source)

	at sun.plugin.liveconnect.SecureInvocation$CallMethodThread.run(Unknown 
Source)

Caused by: java.lang.reflect.InvocationTargetException

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

	at java.lang.reflect.Method.invoke(Unknown Source)

	at sun.plugin.liveconnect.PrivilegedCallMethodAction.run(Unknown Source)

	... 6 more

Caused by: java.security.AccessControlException: access denied
(java.util.PropertyPermission com.ms.sysdir read)

	at java.security.AccessControlContext.checkPermission(Unknown Source)

	at java.security.AccessController.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPermission(Unknown Source)

	at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)

	at java.lang.System.getProperty(Unknown Source)

	at Utils.queryDefaultDrive(Utils.java:193)

	at CKeyPath.<init>(CKeyPath.java:26)

	at CDanskeSikkerCtrl.Init(CDanskeSikkerCtrl.java:347)

	at DanskeSikker.Init(DanskeSikker.java:296)

	... 11 more


I'm no Java expert and definetely no LiveConnect expert, but hope this
information is a little help anyway.

If this is problem is another bug now, which bug should I vote for?

Danske Bank is one of scandinavia largest banking concerns, including (among
others) BG Bank which use same netbank system.



Reproducible: Always
Steps to Reproduce:
1.
2.
3.
taking...
taking...
Assignee: general → kyle.yuan
Component: Browser-General → Java: OJI
Erin, do you have any test case for this issue? Otherwise I don't know how to
reproduce it.
(In reply to comment #3)
> Erin, do you have any test case for this issue? Otherwise I don't know how to
> reproduce it.

The test link I gave at the top is still valid
(In reply to comment #4)
> The test link I gave at the top is still valid

Can I see the applet's source code?
(In reply to comment #5)
> (In reply to comment #4)
> > The test link I gave at the top is still valid
> Can I see the applet's source code?

We can't give you our production code but here's the simplest test I can make. 
The url is http://musedev.ivtweb.com/Test/appletfail2.htm
The applet tag references the NetscapeTest.class and the source for that class 
is:

import java.awt.*;
import java.applet.*;
import java.net.*;

public class NetscapeTest extends Applet
{
	/**
	 * The entry point for the applet. 
	 */
	public void init()
	{
	}
	
	public void Go()
	{
		System.out.println("Begin");
		try
		{
			String host = getCodeBase().getHost();
			System.out.println("The host is: "+host);
			InetAddress iAddress = InetAddress.getByName(host);
		}
		catch(Exception e)
		{
			System.out.println(e.toString());	
		}
		System.out.println("End");
	}
}

The line  'InetAddress iAddress = InetAddress.getByName(host);' is the line 
that throws the exception.

By the way, I tested with a signed applet and the exact same error occurs.


Also for clarification this error occurs when the applet is hosted on a 
different domain from the page that embeds it. It does not occur when the 
applet is on the same server as the page that embeds it.

This is a java plugin bug, not caused by bug 146458. Bug 146458 just revealed
it. I've already filed a bug to java plugin team. Hopefully they can fix it in
the jre 1.5 final release.
Status: NEW → ASSIGNED
What is the bug number for the bug you filed?
(In reply to comment #9)
> What is the bug number for the bug you filed?

I'm guessing the bug he filed was 5032237 (applet can't connect to its home 
server during liveconnect call)

The current evaluation of that bug says

After talking to security team, we found that the critical point of the issue
is whether we should be allow the Javascript from a.com to have a SocketConnect
permission to b.com if the script in a.com has the UniversalBrowserRead
permission. The javascript document only says that with UniversalBrowserRead
previlege turned on, the script will be allowed to read the properties of the
windows and documents with the different origin. And I could hardly find out
the way I can get the IP address by holding the property of windows or any
related object such as location etc.


xxxxx@xxxxx 2004-05-05


So he we go again with another 2 years of trying to explain to these people the 
same arguments we made in bug 146458.



(In reply to comment #10)
> (In reply to comment #9)
> > What is the bug number for the bug you filed?
> 
> I'm guessing the bug he filed was 5032237 (applet can't connect to its home 
> server during liveconnect call)
> 
I tried to view bug 5032237 in the Sun BugDB but it says the bug isn't
available? Bug #5032230 is available and shows that it is marked as a duplicate
of 5032237. When you click on the link for bug 5032237 it says it's not
available. Any idea why?
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > What is the bug number for the bug you filed?
> > 
> > I'm guessing the bug he filed was 5032237 (applet can't connect to its home 
> > server during liveconnect call)
> > 
> I tried to view bug 5032237 in the Sun BugDB but it says the bug isn't
> available? Bug #5032230 is available and shows that it is marked as a 
duplicate
> of 5032237. When you click on the link for bug 5032237 it says it's not
> available. Any idea why?


I had a favorites link to it and it used to work. Now I get the same thing 
you're seeing. They must have removed it. So let's get the Mozilla team to 
revisit this issue again.

I can access 5032237 from our internal site, and it's not closed yet. Don't know
why it can't be accessed outside. This problem is in Java plugin side. We have
nothing to do in mozilla side.
I downloaded the latest Mozilla 1.7.2 and bug 146458 is NOT FIXED!  I ran our
app and we are still getting an OriginNotAllowedExcception, even though our JS
and JAR come from the exact same server.  Can someone reopen this bug and have a
look at it?
Assignee: yuanyi21 → pete.zha
Status: ASSIGNED → NEW
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
Sun provided a workaround that worked in our environment. Took us a while to actually try it out however.

"Developers can change the applet method
which is being called from their JavaScript code so
that the applet method asserts the applet's own
permissions regardless of who is calling it. It does
this by using a doPrivileged() call. This should
obviously be done carefully so that JavaScript from
a malicious origin host cannot easily include
an applet tag to the applet origin host and then
call into the applet method and connect back to the
applet's origin host in an unsafe manner."

We also had to sign the applet to get it to work.
is Bug 241520 a dupe of this?
Product: Core → Core Graveyard
Mass-closing bugs in the "OJI" component: OJI plugin integration was replaced with npruntime long ago, and these bugs appear to be irrelevant now. If there is in fact a real bug that remains, please file it new in the "Core" product, component "Plug-ins".
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.