LiveConnect changes in 7u45

Java 7 update 45 (October 2013) introduces a new warning to users of LiveConnect applications. LiveConnect is a technology for Rich Internet Applications that allows JavaScript on a web page to make calls into an RIA, allowing the two to work together and load content. RIAs that do not use LiveConnect are unaffected by this change.

What changed: Users are prompted to confirm a domain when it makes its first LiveConnect call.
How is this different: Previously, LiveConnect calls were allowed by default.

For the first LiveConnect call (per-site), the Java plugin will ask the user if they want to allow interactions from [this domain] to interact with the currently running RIA. This allows the user to confirm known sources (such as the hosting site) and block alternate sources, such as on-page advertising networks or browser plugins. Prompts will displayed when that a web page performs a LiveConnect call. Prompts about LiveConnect cannot be made beforehand because the caller does not exist.

The LiveConnect warning looks like this:
LiveConnect Dialog: Allow access to the following application from this web site?

Developers looking to avoid this warning within their applications may use the optional Caller-Allowable-Codebase attribute within their JAR file’s Manifest.  The Caller-Allowable-Codebase attribute provides a list of domains that can make LiveConnect calls in to the application. This is different than the optional Codebase attribute, which describes the domains from which JAR files may be loaded, although both use similar syntax.

META-INF/MANIFEST.MF

Manifest-Version: 1.0
Created-By: 1.7.0_45
…
Caller-Allowable-Codebase: example.com *.example.net

RIA developers looking to understand which messages will appear as a result of the end-user’s security slider may consult the Rich Internet Deployment Process flowchart. This chart depicts the checks that will be performed on a user’s system, from version-update checks through checking the signature and appropriate Manifest Permissions. The checks are split into two categories: Before your RIA and With your RIA.

Before your RIA:

  1. Is Java registered in the browser?
  2. Does a rule exist on the user’s system to whitelist this RIA? (e.g. a Deployment Rule Set)
  3. Is the user’s Java version at or above the security baseline?

With your RIA:

  1. Does the RIA have a valid code signature?
  2. Does the RIA meet requirements of the user’s security slider?
  3. Are LiveConnect calls from [this domain] allowed?
Comments:

Adding "Caller-Allowable-Codebase: *" to the JAR's manifest file isn't making the error go away. Any ideas?

Posted by guest on October 15, 2013 at 04:45 PM PDT #

Ditto. I have tried various combinations of URIs and cannot get rid of the security warning.

Posted by guest on October 15, 2013 at 11:23 PM PDT #

Same problem for us.
Caller-Allowable-Codebase seems have not any effect

Posted by guest on October 16, 2013 at 01:01 AM PDT #

Tried multiple variants, adding Caller-Allowable-Codebase to manifest file with sites does not suppress the warning.

Posted by guest on October 16, 2013 at 01:22 AM PDT #

Same problem here, I have added all the manifest entries, tried different combinations for Caller-Allowable-Codebase, but still no luck.

Posted by guest on October 16, 2013 at 03:16 AM PDT #

Area: Deployment/Plugin
Synopsis: Caller-Allowable-Codebase may be ignored when used with Trusted-Library.

If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.

This works, but now earlier versions causes as security concern to popup.

Posted by Pieter on October 16, 2013 at 03:58 AM PDT #

Hi, I used following syntax, a nothing changed:

Manifest-Version: 1.0
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Application-Name: applet name
Permissions: all-permissions
Caller-Allowable-Codebase: *
Codebase: *

Is there any reliable idea how to solve this issue?
Thanks.

Posted by jf on October 16, 2013 at 04:00 AM PDT #

There appears to be a bug in the current implementation (7u45) - it conflicts with the Truster-Library attribute:
http://stackoverflow.com/questions/19393826/java-applet-manifest-allow-all-caller-allowable-codebase

Posted by guest on October 16, 2013 at 04:14 AM PDT #

Oracle writes:

If a trusted, signed jar is using the Caller-Allowable-Codebase manifest attribute along with Trusted-Library then the Caller-Allowable-Codebase manifest entry will be ignored and, as a result, a JavaScript -> Java call will show the native LiveConnect warning. The workaround is to remove the Trusted-Library manifest entry.

Posted by guest on October 16, 2013 at 04:29 AM PDT #

For those developers like us who were blindsided by this change, and now have end users across the world getting horrible security warnings with our software, and from what I am reading, the proposed fixes are not working for people, how can we get advanced warning of Oracle breaking our software?

Posted by guest on October 16, 2013 at 06:14 AM PDT #

If an end user declines the security warning (as many of our end users have already), what do they need to do to undo this so they can actually use our application?

Posted by guest on October 16, 2013 at 06:20 AM PDT #

It seems that Caller-Allowable-Codebase doesn't work if Trusted-Library is present.

see http://stackoverflow.com/questions/19393826/java-applet-manifest-allow-all-caller-allowable-codebase

Posted by guest on October 16, 2013 at 06:32 AM PDT #

It seems that Caller-Allowable-Codebase doesn't work if Trusted-Library is present.

see http://stackoverflow.com/questions/19393826/java-applet-manifest-allow-all-caller-allowable-codebase

Posted by guest on October 16, 2013 at 06:32 AM PDT #

Yet another way to scare users off of using the Java plug-in. What is the rationale for this?

Posted by guest on October 16, 2013 at 07:14 AM PDT #

Same problem with * wildcard

Posted by guest on October 16, 2013 at 09:04 AM PDT #

Is there a way to tell Java that I trust a specific Java applet so I don't have to click this every day until the website I'm using updates the applet?

Posted by guest on October 16, 2013 at 09:15 AM PDT #

Consider that removing " Trusted-Library " attribute will cause other warning regarding mixed code execution when using liveconect... So we can't consider it as a valid workaround.

Posted by guest on October 16, 2013 at 10:38 AM PDT #

Has anyone else tried this solution regarding the Trusted-Library issue:

http://stackoverflow.com/a/19404777

Posted by guest on October 16, 2013 at 11:27 AM PDT #

There's a set of options that System Administrators can do to whitelist applications on https://blogs.oracle.com/java-platform-group/entry/what_to_do_if_your -- please take a look at that while I look into the Trusted-Library post from Stack-Overflow.

Specifying "Caller-Allowable-Codebase: *" is a bit wide because that would mean that JavaScript from any domain (including the ones described in the above news article) would be able to call in.

Also a few points about the blog:
* I have to click to approve comments, which I am doing.
* There's a typepad integration for spam that's flagging a few posts. I think because a number of comments cited similar stackoverflow URLs within a short time on the same blog.

Posted by costlow on October 16, 2013 at 12:08 PM PDT #

I just want to point out (I'm the guy who asked above about how to trust an applet). The site we use (www.accuplacer.org) is external to us and not something we have control over (and not something we can stop using either). We can't fix the .jar by signing it ourselves since it's coming from Accuplacer's servers.

I don't foresee them (Accuplacer) doing anything on their end anytime soon as their stance on things like that is that we should just stay on the previous version (they still only officially support Firefox 19 for example). So until they finally (if ever?) update the applet our students (I work for a college) are seeing this warning every single time they take a placement test. Many of them say "Don't Allow" because they're used to saying no to stuff like that at home. Even if we tell them ahead of time what to click.

Previously, there was a "grant always" option that would pop the applet into trusted.certs and I could push that out to the other 49 computers so that students weren't prompted.

For now, I have a program watching for the Security Warning window and it clicks "Allow" immediately. Not an ideal solution, but it seems to be a good workaround.

Posted by guest on October 16, 2013 at 12:40 PM PDT #

I have been using * for testing, not production, just to prove things work as expected.

The workaround of removing Trusted-Library works for me. Is it being deprecated as it now seems redundant? What about users from update 21 who need the Trusted-Library attribute - forced upgrade? Better if update 46 went out ASAP that fixed this properly, however I can't find this issue listed in the bug database.

I like the new changes but they're buggy/rushed and seems it's all too little to late (NPAPI being deprecated, etc).

Posted by guest on October 16, 2013 at 05:27 PM PDT #

It would be great if 745 could remember what site was allowed vs clicking allow all day long. Please..Pretty Please

Posted by tonyc on October 16, 2013 at 05:31 PM PDT #

Within university computers or other areas with a known community, you can place a Deployment Rule Set on those machines to whitelist known applets. See https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets for the original post.

Posted by costlow on October 16, 2013 at 05:36 PM PDT #

Removing the Trusted-Library manifest entry doesn't seem to work for us. When we attempt to load our applet with that entry removed, we get the following exception:

java.lang.SecurityException: class "MyApplet" does not match trust level of other classes in the same package

Posted by guest on October 16, 2013 at 05:52 PM PDT #

Why was Caller-Allowable-Codebase Attribute not an applet <PARAM> like so many other plugin directors???

We have a generic Applet that is used by any number of domains and pages and surely the most functionally appropriate (let alone sensible) place to throttle LiveConnect is at the <OBJECT> or <APPLET> stage?

Posted by Richard Maher on October 16, 2013 at 08:27 PM PDT #

This is a real pain! At least let us users allow and save trusted sites and avoid this warning.

Posted by rfmtm on October 17, 2013 at 09:36 AM PDT #

costlow wrote:

"Specifying "Caller-Allowable-Codebase: *" is a bit wide because that would mean that JavaScript from any domain (including the ones described in the above news article) would be able to call in."

For a commercial product that gets installed at the customer site, I don't see any other option than using '*' as the allowable codebase, since we don't know the domain where the product will be installed.

Further, neither of the other options is really acceptable. Our customers cannot push out a Deployment Rule Set to desktops they don't control (eg, business partners that might run our product from the customer's site), and customers do not wish to re-sign our jars with their own certificate because it's not their product.

Perhaps a useful setting for the "Caller-Allowable-Codebase" would have the meaning, "allow LiveConnect only if the domain of the script matches the domain of the jar".

Posted by guest on October 17, 2013 at 10:14 AM PDT #

I have an applet which uses the all-permissions model and I need to use liveconnect to call that applet from javascript, albeit the JS will always come from the same domain as where the applet jar resides, but the domain varies among our customers-

What do I need?

Prior to 7u45 I signed the applet and used Trusted-Library.

http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html#newft reads as if I either sign the jar and use Caller-Allowable-Codebase or not sign and not use Caller-Allowable-Codebase?

However the later seems not to work and for the former I need to omit Trusted-Library because of the 7u45 bug which will give problems in versions less 7u45...

Any other ideas?

Posted by Wolfgang Röckelein on October 17, 2013 at 02:49 PM PDT #

'Perhaps a useful setting for the "Caller-Allowable-Codebase" would have the meaning, "allow LiveConnect only if the domain of the script matches the domain of the jar".'

I would second this. I am in the same situation and the current possible settings are note satisfying.

Posted by Wolfgang Röckelein on October 18, 2013 at 12:20 AM PDT #

Please keep 'improving' the applet experience Oracle, each time you 'improve' things it makes it easier for me to justify removing applets from our solution. This 'fix' seems incredibly poorly thought out, badly/untested and yet another nail in the applet/webstart coffin.

Posted by guest on October 18, 2013 at 01:25 AM PDT #

Oracle is really making it difficult for end users to run Java applets. The last couple of years have been a slow but steady death for applets.

Posted by guest on October 18, 2013 at 04:42 AM PDT #

This issue and a number of others are making my organisation seriously question the value of providing our products to clients including java applets.

There does not seem to have been a java 7 release that hasn't led to additional popups or dialogs that our end users need to respond to. These then significantly impact our clients perception of our product as they perceive these as being security faults in our software where the reality is that our software is no less secure than it was previously.

Further worsening this is that our mostly non-technical client base doesn't understand the usual security alert which leads to further load on our already overworked support team.

There needs to be a mechanism where organisations like mine can get early access to these releases so that we can forewarn customers of any issues or provide better solutions for them. As it stands we generally hear about these problems once clients are impacted which is far too late. I understand that this blog post and others like it is intended to address this but looking at the dates of the posts they are coming far too late for us to be able to proactively support our customers.

So to summarise I have three recommendations:

1. Provide early access to java releases in an easily downloadable format.
2. Review security alerts and the text included in them for understandability from a typical non technical end users perspective.
3. More carefully review the security changes being made with each release as to potential impact on third party developers and their products.

Posted by guest on October 20, 2013 at 10:37 PM PDT #

I can only agree to the above statements that this fix is poorly thought through especially for applications that are deployed on customer infrastructures. The best would be to check if the javascript domain matches the jar domain and optionally another domain can be specified for special situations.

Posted by mkueng on October 22, 2013 at 01:12 AM PDT #

It does not work for me, if I use the Caller-Allowable-Codebase and I have no Trusted-Library in the jar manifest. Also I have set the value for Caller-Allowable-Codebase to * , Still I get the Live Connect Issue. I cannot call a java method from the Java script

Posted by guest on October 22, 2013 at 02:35 AM PDT #

I still have an issue, where the value for Caller-Allowable-Codebase is * and I am not using the Trusted-Library in the manifest file. I get the Live connect issue, when calling the java method from the javascript.

Posted by guest on October 22, 2013 at 02:36 AM PDT #

The java script live connect only appears if other option than Later was pressed at the pop-up for installing new java release. It will force the users to install the new java otherwise no applet called by javascript will work.

Posted by guest on October 22, 2013 at 02:43 AM PDT #

How do I properly populate the

Application:
Publisher:

fields in the new security warning prompt? Are they extracted from the manifest file, or from the certificate which is used to sign the JAR with? Can someone provide a link where these values are actually populated?

Posted by SpiderWeb on October 22, 2013 at 03:23 AM PDT #

Richard Maher: Allowing the caller to say "yes, I really am allowed to call this, honest guv'" would defeat the point of it.
It's an option for the publisher of the applet to specify who can call it. Not the user.

Posted by Deanna on October 22, 2013 at 04:42 AM PDT #

I can not use my applet any more after java 7u45 was released.
I use java 7u25,
this is the log from java console

basic: Applet initialized
basic: Starting applet
basic: completed perf rollup
basic: Applet made visible
basic: Applet started
basic: Told clients applet is started
network: Created version ID: 1.7.0.25
network: Created version ID: 1.7.0.45
security: LiveConnect (JavaScript) blocked due to security settings.

Please help me on this.I have signed all the jar ,
Why it was blocked?I use the java u 25, why the log shows java 7u45.

Is it possible to use javascript to java calling?
Thanks

Posted by Joshua Lyn on October 23, 2013 at 01:12 AM PDT #

I can only agree to the above statements - the script domain has to be matched against the applet domain automatically. Anything else is not acceptable for web applications with applets that are installed on customer infrastructures.
The "Caller-Allowable-Codebase" is nice optional feature for special situations.

Posted by guest on October 23, 2013 at 02:12 AM PDT #

Wolfgans & Richard, I understand the comments above and acknowledge that "same domain" type matching would be convenient. The challenge with that is for applications which CAN whitelist the Caller-Allowable-Codebase because it guards against repurposing. An example would be a case where the application itself contains a vulnerability that isn't accessible on your own environment -- by moving the application and sending someone to it, your signature is unchanged but a new attack surface is exposed and same-domain is matched.

Joshua, there's an explanation for what you're seeing with the solution on https://blogs.oracle.com/java-platform-group/entry/updated_security_baseline_7u45_impacts

Posted by costlow on October 23, 2013 at 10:15 AM PDT #

A few people contacted me about getting emailed all comments versus approved non-spam ones to ask that this be fixed. I'm looking into doing that but in the mean-time I had to disable email notifications.
While this is going on, I'll check to approve comments more often and turn them back on once I can.

Posted by costlow on October 23, 2013 at 10:30 AM PDT #

Deanna: It's not a matter of [Allowing the caller to say "yes, I really am allowed to call this, honest guv'"] it's allowing the authour of the document base to say "Hey, I'm including a whole lot of script files from other domains and I don't want them to be able to script this Applet". [would defeat the point of it] I'm not sure Oracle have articulated what "the point of it" is. Is it CopyRight Protection or marketing mechanism or is it a security mechanism? [It's an option for the publisher of the applet to specify who can call it.] You mean like they've always been able to do by interogating the results of Applet.getDocumentBase()?

The whole idea of having to ship/package/manufacture a separate Applet for each customer is ludicrous!

costlow: [because it guards against repurposing] Fine. *IF* the check scrutinized the domain of individual.JS files then I could see the sense in it, but my quick testing says it ONLY checks the Document Base. Please communicate exactly what you were trying to accomplish.

On the subject of communication please feel free to assume a fair portion of responsibility for user-base feelings like this: -
https://bugzilla.mozilla.org/show_bug.cgi?id=914690

Cheers Richard Maher

PS. Why don't I get any pop-up when I dynamically include an unsigned Applet at run-time with innerHTML="<OBJECT. . .".

Posted by Richard Maher on October 23, 2013 at 03:40 PM PDT #

Caller-Allowable-Codebase is about checking where JavaScript calls come from. Codebase is about the applet itself, though both are optional. I tried to point out the cause above in regards to on-page advertising networks with the news article, but some additional more technical research is at http://www.cio.wisc.edu/Shreeraj_Shah_DOM_Hacking.pdf or http://justinsomnia.org/2012/04/hotel-wifi-javascript-injection/ - nothing to do with copyright or marketing.
Per the Mozilla bug, you can see Donald Smith on that thread at comment 68.

Posted by costlow on October 23, 2013 at 04:14 PM PDT #

costlow: You're ability to listen seems to be suffering from the same impairment as Mozilla. Actually, they're busy rolling back their crime against the client-base whereas Oracle have just turned-down their hearing aids :-(

[Caller-Allowable-Codebase is about checking where JavaScript calls come from.] Please explain what Oracle thinks determines where the JS is "from".

1) The domain from the URL src that loaded the JavaScript
2) The domain of the hosting page (Dosument Base)
3) The domain of a page in the iFrame
4) The domains of all the pages in a Frameset
5) Which domain does EVAL() inherit

Where is the documentation that answers these questions and helps developers arrive at deterministic outcomes?

If everyone turns around AS THEY ARE and enters "Callable-Allowable-Codebase: *" what have you achieved apart from annoying a whole lot of people and forcing the signing of Applets that don't need it? You don't even mandate httpS for Pete's sake. What's the point of that?

Will Oracle now demand a white-list of all domains with SQL coming into its Databases? All Apex clients must be white-listed?

Please copy FireFox, step back from the abyss, and think this through.

And finally, again, Why don't I get any pop-up when I dynamically include an unsigned Applet at run-time with innerHTML="<OBJECT. . ."? Be very aware that partial initialization init() IS taking place!

Posted by Richard Maher on October 23, 2013 at 06:32 PM PDT #

A couple of definitions from Javadocs to add to the Glossary after "from": -

CodeBase: The base URL. This is the URL of the directory which contains this applet.

DocumentBase: The URL of the document in which this applet is embedded.

I have been using the terms deliberately and not interchangeably in my posts.

Posted by Richard Maher on October 23, 2013 at 06:57 PM PDT #

This feature really does look like a very poorly thought through fix.
As another user stated, what about applications that are installed into a customer site where the domain is set by the customer.

I would state the requirement is:
"Allow the signed Java applet to interact only with Javascript which are served from the same server" - and optionally the server has to be in the intranet or trusted sites list

Posted by ColinB on October 24, 2013 at 09:41 AM PDT #

This workaround doesn't seems to be the solution.

I was trying to solve this problem with the Caller-Allowable-Codebase and no Trusted-library in the manifest (7.45 version), without success.

I've already tried with the Deployment Rule Set configuration, to finally realize that the DeploymentRuleSet.jar needs to be trusted signed. And in first place, all this work did just because I can't have a trusted certificate.

So, to summarize, I think the only way I can get rid of this (the several warnings, not just this one), is to have a trusted signed applet jar?

Posted by guest on October 29, 2013 at 06:31 AM PDT #

What works for me is simply having the html and applet in the same domain. But then I don't get any pop-ups and activation simply fails silently otherwise. (Console log reveals error).

Oracle seem to be pursuing a policy security through obscurity and only discussing this on a need-to-know basis :-(

Posted by Richard Maher on October 30, 2013 at 12:25 AM PDT #

I'm not clear on how obscurity is a factor here. That term refers to things like "telnet is safe because I changed the port." These changes convert the parameters from a boolean "is untrusted code allowed, yes or no" to a matcher, "is untrusted code allowed, if so from where."
Regarding the basis for communication, I've done several posts about this issue. For other planned changes, I have actually gone out to build tools and open source projects to either tell them or provided patches directly.

Posted by costlow on October 31, 2013 at 09:35 AM PDT #

I have tried various combinations of URIs and cannot get rid of the security warning. how to get rid of this warning in ma code what alterations are required

Posted by guest on November 06, 2013 at 03:18 AM PST #

Oracle Forms 11g is run in an applet(delivered in an Oracle signed jar) and supports a JavaScript API that allows JS calls to the applet code.

How is Oracle going to deliver these Forms Jar files to clients to maintain the integrity of the applet using manifest attributes?

Posted by Peter on November 06, 2013 at 10:09 PM PST #

Peter, the Java group is intentionally separate from other Oracle product teams to avoid potential conflicts. We do talk to them but I am not able to provide answers for them. I suggest filing a support ticket or investigating Deployment Rule Sets to whitelist their applets without any changes.

Posted by costlow on November 11, 2013 at 10:10 AM PST #

Is there any way to add a trusted user with this feature on the client side? There doesn't seem to be a remember my response or a save this action button.

Posted by Curious on November 11, 2013 at 01:36 PM PST #

Costlow,

Please have a look at forums.oracle.com/thread/2595634. According to JDK-8021826, my LiveConnect calls directly to the applet should be okay (even under Very High security) with a deployment rule set that covers just the applet with a certificate hash. However, it does not. A rule covering the codebase of the JavaScript calls directly is still required. I think this is a bug that needs to be reported with high priority.

Posted by Brian D on November 12, 2013 at 01:47 PM PST #

Post a Comment:
Comments are closed for this entry.
About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
8
9
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today