We are facing a problem with lastest JRE 6 update 22 and 23. The problem is we are running a site which uses Java Applet to stores/retrieve datas by calling a PHP file. For last 7 years we never had a single issue but now with latest JRE are we having a problem. The Java applet is loaded fine but failed to connect our sever (unix server) which suppose to call the PHP file.

Note: We use Javascript to call a Java function to connect our server, to retrieve data from the PHP file.

Here is the error message found in Java console:

basic: Applet started
basic: Told clients applet is started
Retreiving cmi for sco=778 from ATutor server
network: Connecting .php with proxy=DIRECT
network: Cache entry not found [url: /crossdomain.xml, version: null]
network: Connecting /crossdomain.xml with proxy=DIRECT
network: Connecting :80/ with proxy=DIRECT
network: Server /crossdomain.xml requesting to set-cookie with "SESSdba781ab68368f3b7b29ce28e33a2679=983ded5e21e40047871b1f3ce5c259d7; expires=Monday, 07-Mar-11 20:45:53 GMT; path=/"
ATutor cmi retrieval failed.
java.security.AccessControlException: access denied (java.SocketPermission xxx.xxx.xxx.xxx:80 connect,resolve)

Oracle has released a note and addressing this issue with a solution, Website: .html

The fix for CVE-2010-3560 could cause certain Java applets running in the new Java Plug-in to stop working if they are embedded in web pages which contain JavaScript that calls into Java in order to perform actions which require network security permissions. These applets may fail with a network security exception under some circumstances if the name service which resolved the original web page URL host name does not return a matching name as the result of a reverse address lookup. This is most likely to occur for the new Java Plug-in running on Solaris and Linux when configured to use NIS for host to network address resolution with maps containing host names which are in short form (rather than as a fully qualified domain name).

If an applet is suspected of failing due to this change you can verify that by setting the logging level of the Java Console to 5 and looking for logging strings beginning with "socket access restriction" which will describe the specific cause of the mismatch and will help in identifying the correct workaround to use as described below:

Add a new host name forward map entry (in /etc/hosts, NIS, or DNS) in a special form which is recognized by Java for the purpose of validating IPv4 and IPv6 name service mappings. The IPv4 general name form followed by an /etc/hosts file fragment example for IP address 10.11.12.13 is:

host.auth.dddc.bbb.aaa.in-addr.arpa

# /etc/hosts example
10.11.12.13    foo.bar.auth.13.12.11.10.in-addr.arpa

There is an equivalent form for IPv6 addresses which uses the IP6.ARPA domain root format defined in RFC 3596.

For DNS, these would be A (IPv4) or AAAA (IPv6) entries.

Pre-pend a fully qualified host name before other mappings to the same address. For example, in /etc/hosts format:

#10.11.12.13   foo loghost
10.11.12.13    foo.bar foo loghost  

As an alternative to updating name service records, it may be possible to safely modify the applet to perform the network action using only it's own permissions independent of the web page which contains it by using the doPrivileged() method of the java.security.AccessController class.

I am PHP developer and I have very little knowledge on Java. I couldn't understand the solution provided by the Oracle. They want to add new host name in /etc/hosts file, can anyone please explain with more clear example what to add in /etc/hosts.

Also I don't know where to add doPrivileged() method, please help.

Thanks

We are facing a problem with lastest JRE 6 update 22 and 23. The problem is we are running a site which uses Java Applet to stores/retrieve datas by calling a PHP file. For last 7 years we never had a single issue but now with latest JRE are we having a problem. The Java applet is loaded fine but failed to connect our sever (unix server) which suppose to call the PHP file.

Note: We use Javascript to call a Java function to connect our server, to retrieve data from the PHP file.

Here is the error message found in Java console:

basic: Applet started
basic: Told clients applet is started
Retreiving cmi for sco=778 from ATutor server
network: Connecting http://www.example./training/scorm/read.php with proxy=DIRECT
network: Cache entry not found [url: http://xxx.xxx.xxx.xxx/crossdomain.xml, version: null]
network: Connecting http://xxx.xxx.xxx.xxx/crossdomain.xml with proxy=DIRECT
network: Connecting http://xxx.xxx.xxx.xxx:80/ with proxy=DIRECT
network: Server http://xxx.xxx.xxx.xxx/crossdomain.xml requesting to set-cookie with "SESSdba781ab68368f3b7b29ce28e33a2679=983ded5e21e40047871b1f3ce5c259d7; expires=Monday, 07-Mar-11 20:45:53 GMT; path=/"
ATutor cmi retrieval failed.
java.security.AccessControlException: access denied (java.SocketPermission xxx.xxx.xxx.xxx:80 connect,resolve)

Oracle has released a note and addressing this issue with a solution, Website: http://www.oracle./technetwork/java/javase/6u22releasenotes-176121.html

The fix for CVE-2010-3560 could cause certain Java applets running in the new Java Plug-in to stop working if they are embedded in web pages which contain JavaScript that calls into Java in order to perform actions which require network security permissions. These applets may fail with a network security exception under some circumstances if the name service which resolved the original web page URL host name does not return a matching name as the result of a reverse address lookup. This is most likely to occur for the new Java Plug-in running on Solaris and Linux when configured to use NIS for host to network address resolution with maps containing host names which are in short form (rather than as a fully qualified domain name).

If an applet is suspected of failing due to this change you can verify that by setting the logging level of the Java Console to 5 and looking for logging strings beginning with "socket access restriction" which will describe the specific cause of the mismatch and will help in identifying the correct workaround to use as described below:

Add a new host name forward map entry (in /etc/hosts, NIS, or DNS) in a special form which is recognized by Java for the purpose of validating IPv4 and IPv6 name service mappings. The IPv4 general name form followed by an /etc/hosts file fragment example for IP address 10.11.12.13 is:

host.auth.dddc.bbb.aaa.in-addr.arpa

# /etc/hosts example
10.11.12.13    foo.bar..auth.13.12.11.10.in-addr.arpa

There is an equivalent form for IPv6 addresses which uses the IP6.ARPA domain root format defined in RFC 3596.

For DNS, these would be A (IPv4) or AAAA (IPv6) entries.

Pre-pend a fully qualified host name before other mappings to the same address. For example, in /etc/hosts format:

#10.11.12.13   foo loghost
10.11.12.13    foo.bar. foo loghost  

As an alternative to updating name service records, it may be possible to safely modify the applet to perform the network action using only it's own permissions independent of the web page which contains it by using the doPrivileged() method of the java.security.AccessController class.

I am PHP developer and I have very little knowledge on Java. I couldn't understand the solution provided by the Oracle. They want to add new host name in /etc/hosts file, can anyone please explain with more clear example what to add in /etc/hosts.

Also I don't know where to add doPrivileged() method, please help.

Thanks

• java
• javascript
• security
• applet

2 Answers 2

Paŭlo,

Server admin uploaded a crossdomain.xml file to the root web directory of the site that resolve the public ip. This is the only information I received.

Here is the crossdomain.xml file,

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia./xml/dtds/cross-domain-policy.dtd"> 
<cross-domain-policy>
   <allow-access-from domain="*" /> 
</cross-domain-policy> 

This fixed the problem and no errors appears in Java console logs.

These errors are fixed,

network: Cache entry not found [url: http://xxx.xxx.xxx.xxx/crossdomain.xml, version: null]


java.security.AccessControlException: access denied (java.SocketPermission xxx.xxx.xxx.xxx:80 connect,resolve)

Java applets are only allowed to call their own origin host, and it seems that from the change mentioned by your citation above that Javascript code calling into the applet has no networking rights at all, to avoid that hostile scripts use your applet to connect to your server with the privileges of the applet instead of its own.

If you are sure that no malicious things could happen if your applet method is called (even if called by a malicious script), you can use in this method this call to AccessController.doPrivileged(...), like this:

public String retrieveData(final String params) {
   return AccessController.doPrivileged(new PrivilegedAction<String>() {
           public String run() {
               // here the rest of your networking code
           }
       };
}

Instead of wrapping the whole method in doPrivileged, maybe only wrap the networking parts (like openConnection() or such).