Updated Security Baseline (7u45) impacts Java 7u40 and before with High Security settings

The Java Security Baseline has been increased from 7u25 to 7u45.  For versions of Java below 7u45, this means unsigned Java applets or Java applets that depend on Javascript LiveConnect calls will be blocked when using the High Security setting in the Java Control Panel.

This issue only affects Applets and Web Start applications. It does not affect other types of Java applications.

The Short Answer

Users upgrading to Java 7 update 45 will automatically fix this and is strongly recommended.

The More Detailed Answer

There are two items involved as described on the deployment flowchart:

  1. The Security Baseline – a dynamically updated attribute that checks to see which Java version contains the most recent security patches.
  2. The Security Slider – the user-controlled setting of when to prompt/run/block applets.

The Security Baseline

Java clients periodically check in to understand what version contains the most recent security patches. Versions are released in-between that contain bug fixes. For example:

  • 7u25 (July 2013) was the previous secure baseline.
  • 7u40 contained bug fixes. Because this did not contain security patches, users were not required to upgrade and were welcome to remain on 7u25.
  • When 7u45 was released (October, 2013), this critical patch update contained security patches and raised the secure baseline. Users are required to upgrade from earlier versions.
For users that are not regularly connected to the internet, there is a built in Expiration Date. Because of the pre-established quarterly critical patch updates, we are able to determine an approximate date of the next version. A critical patch released in July will have its successor released, at latest, in July + 3 months: October.

The Security Slider

The security slider is located within the Java control panel and determines which Applets & Web Start applications will prompt, which will run, and which will be blocked.

One of the questions used to determine prompt/run/block is, “At or Above the Security Baseline.”

The Combination

JavaScript calls made from LiveConnect do not reside within signed JAR files, so they are considered to be unsigned code. This is correct within networked systems even if the domain uses HTTPS because signed JAR files represent signed "data at rest" whereas TLS (often called SSL) literally stands for "Transport Level Security" and secures the communication channel, not the contents/code within the channel.

The resulting flow of users who click "update later" is:

  • Is the browser plug-in registered and allowed to run? Yes.
  • Does a rule exist for this RIA? No rules apply.
  • Does the RIA have a valid signature? Yes and not revoked.
  • Which security prompt is needed?
    • JRE is below the baseline. This is because 7u45 is the baseline and the user, clicked "upgrade later."
  • Under the default High setting, Unsigned code is set to "Don’t Run" so users see:

Additional Notes

As a reminder, in the future, Java 7u51 (January 2014) will block unsigned and self-signed Applets & Web Start applications by default.


Thank you for these helpful blog posts.

You include a link to the earlier post which discusses the requirements for RIAs in 7u51, one of which is that we will be required to set the "Permissions" attribute in the Manifest.

However, the 7u45 release notes state that using pack compression and Permissions can cause the applet to fail to load. Will this problem be fixed before 7u51?

Posted by guest on October 16, 2013 at 07:11 PM PDT #

So... according to this article, as soon as the security baseline is upgraded, EVERY applet called by javascript, even if correctly signed, WILL be blocked until clients upgrade to 7u45?

Wondering if this is really the intended behaviour as major sites using applets/javascript are progressively being blocked right now, and rendered useless. This is equivalent to all versions prior to 7u45 being EOL'd without any warnings.

Posted by Mathieu Fortin on October 17, 2013 at 07:30 PM PDT #


The last months are a nightmare for applet developers and customers ! Every new update, developers have to be in a rush to correct the production software and all customers call helpdesk all the day.
Is it possible to get a pre-release version before the big bang ?

I think there is a bug regarding the tray icon in 7u45, when browser is closed, the icon remains in tray bar and worse the java.exe process as well. Then there is a caching issue ...

I hope this bug will be correct in the 7u51!

Posted by guest on October 17, 2013 at 10:38 PM PDT #

I'm looking into the pack compression; I will try to post back here once I've gotten the details.

Matthieu, updates to the security baseline create are intentionally incompatible with reported vulnerabilities. This can have an unfortunate side-effect when legitimate applications make use of the same features. In the case of the recent LiveConnect changes, we were required to put restrictions in place that could be overridden by the developers/admins.
The role of upgrading end-users is designed to limit what’s referred to as the “window of exposure.” While I understand the frustration, analogies to an EOL are over-stated: client programs still ran, network services still operated, regular applets were still available. Only applets using LiveConnect were affected.
And even still, users who absolutely refuse to update to the security baseline, can still accept the warnings depending on their security settings.

Posted by costlow on October 18, 2013 at 08:48 AM PDT #

A correction to my last post. It seems only users running on 7u25 and 7u40 have LiveConnect calls being blocked. So, I agree my EOL comparison is over-stated.

But still, while I think everyone agrees to increasing security, the frustration comes from the fact that we know of these changes only when they come out.

Posted by Mathieu Fortin on October 18, 2013 at 09:00 AM PDT #

One of the reasons we created this blog is that it gives us a way of providing as much information as we can, even more than it already done on the various OpenJDK mailing lists.

There are some changes that we can't provide advance notice about, and my hope is to keep that to a minimum.
For other changes, not only are we posting about them here, I am actually going out into other projects and not only telling them, but (as appropriate) making contributions. See https://issues.apache.org/bugzilla/show_bug.cgi?id=55542 for an example.

Posted by costlow on October 18, 2013 at 10:07 AM PDT #

I checked into pack compression: there is a bug filed and it's planned to be fixed for 7u51. Thank you for bringing this up.

For the system tray, there is an option in the Java control panel to "Place icon in system tray" but it's off by default as well as my machine's basic install. Maybe yours is turned on.

Posted by costlow on October 18, 2013 at 10:57 AM PDT #

I am trying to adjust our 7u45-based jnlp application to follow the new security rules but it appears I still have an obstacle. Things I have done successfully include (1) Migrated from self-signing to a Verisgn-based signature on our jar files (2) Introduced Permissions into the manifest of each of the jars. However, I have also attempted to embed the jnlp file, named as APPLICATION.JNLP within JNLP-INF as specified by Oracle, into the jar containing the main class, in order to qualify it as a digitally signed jnlp. If the jnlp contains an explicit codebase attribute, everything works fine. However, by design, our product does not know its codebase ahead of time, which is a problem that others besides me have alluded to. If I do not define the codebase attribute, the user still gets a warning whose 'more information' states "Although the application has a digital signature, the application's associated file (JNLP) does not have one...." . Is there any workaround to this annoying message ?

Posted by guest on October 21, 2013 at 08:07 AM PDT #

please contact with me for java 7 security ok.

Posted by guest Abdul Hussain on October 21, 2013 at 12:27 PM PDT #

For signing a JNLP file (JSR-56), there is a post on the tutorials' blog over at https://blogs.oracle.com/thejavatutorials/entry/signing_a_jnlp_file that can provide more information. I understand the ISV's role of not knowing Codebase ahead of time, which is why that's optional.

Abdul, there is a general security page over on http://www.oracle.com/technetwork/java/javase/overview/default-2031554.html that may help you find more information depending on what you're looking for.

Posted by costlow on October 21, 2013 at 01:29 PM PDT #

I'm the 'guest' who wrote initially yesterday about 7u45-based jnlp security issues, Oct 21, 2013 at 8:07 AM...

Continuing on today, after confirming that I correctly (1) Sign our jnlp application's jar files with a Verisign certificate ,(2) Set the Permissions to "all-permissions" attributes in the manifest, (3) Set Caller-Allowable-Codebase to "*" in the manifest, I now get an annoying security popup after the JNLP application has fully loaded and has begun to execute. The popup indicates that “the connection to this web site is untrusted” together with a note that the JAR file manifest doesn’t contain the Permissions attribute with a threat that things will stop working in a future release. This occurs after attempting to access the web server programmatically via https with Java code in one of the jar files that has been legitimately signed and duly acknowledged as such by the user in the first security popup Java presents when loading the jnlp. Why am I obliged to additionally sign the web site separately ? The first popup that the user acknowledged already said “Run this application only if you trust the location and publisher above”.

And by the way, all our jars contain the Permissions attribute, so the popup about them not containing it is wrong. We package our jnlp application on a network device that we sell and cannot be expected to provide a unique web site signature for each and every device. This is a show-stopper for us !! Please help !!

Posted by guest on October 22, 2013 at 07:25 AM PDT #

A preview isn't enough. All these security changes neglect the fact that from the users perspective there are 3 different types of applets: the ones that run on arbitrary websites, dedicated sites that provide complex web applications the user works with and intranet applications.
At least you should provide a way so that the security settings on the client side can be chosen differently: high for unknown sites and lower for dedicated domains (which would include intranet sites) in automatic client installation.

Posted by mkueng on October 23, 2013 at 04:12 AM PDT #

I agree wholeheartedly with the last post. Is there some reason different categories can't be established for the different types of applets? Internet Explorer at least provides the ability to set certain sites as Intranet and Trusted Sites - letting you customize the level of security for each, respectively.

There are sites that some of our executive partners go to that we would like to turn off Java security prompts completely, while maintaining high security settings for all others. It makes little sense to have all Java security settings apply to a single, all-encompassing basket. Nag multiple times, nag a single time, or don't nag me at all - for everything - doesn't seem like a good solution.

Posted by guest on October 29, 2013 at 09:00 AM PDT #

I have question about, but comments closed.

Will this security fixes backported to early java families?
If customer use jadk 1.6, applet will be blocked?

Posted by Gorshkov Leonid on November 01, 2013 at 03:55 AM PDT #

See http://www.oracle.com/technetwork/java/eol-135779.html for information about JDK6.

Posted by costlow on November 01, 2013 at 09:36 AM PDT #

This update seems fine, and we are updating all of our JAR files accordingly; however, 7_45 incorrectly reports that a JAR's manifest file is missing the Permissions attribute if the 'version' attribute is specified on the <jar> element in a JNLP file. If we simply remove the version number from the JAR file name and remove the 'verison' attribute from the <jar> element in the JNLP file, then JWS does not complain about the missing attribute. Same JAR file, same manifest information.

This gives us cause for concern especially if JWS will incorrectly block our application in Jan 14 if we continue to use the 'version' attribute. We have submitted a bug report, but have not heard back. This bug is very easy to recreate.

Posted by Ryan Sawatzky on November 01, 2013 at 09:59 AM PDT #

Ryan, what is the bug number of your filing? Bug reporting is handled separately on either https://bugs.openjdk.java.net/browse/JDK or http://bugs.sun.com/

Posted by costlow on November 04, 2013 at 09:41 AM PST #

I submitted the same bug (and I believe the same Ryan and I have discussed it at length in the OTN forums: https://forums.oracle.com/thread/2594060).

I submitted it to bugs.sun.com (saw no way to open an issue bugs.openjdk.java.net, in fact many of the relevant issues there require authorization to even view) and got an email confirmation report with an ID of 9007850.

I also submitted two other issues:

9007851 LiveConnect deployment rule requires opening hole for any applet
9007849 DeploymentRuleSet.jar is not found under MacOS X

Posted by Brian D on November 05, 2013 at 02:39 PM PST #

Hey Ryan, I have exactly the same problem - could you provide bug number or if you managed a workaround? =)

Posted by Dušan on November 08, 2013 at 03:06 AM PST #

We have updated our Jre version to 7U45. With this update, I was getting an error that our java applet will be blocked in the next versions of Jre. SO I added the permissions attribute to the manifest file Like "permissions: all-permissions". After having added this, I am not getting that error. But there is new warning message saying the applet is not from a trusted source. I tried adding the following attributes to the applet.
codebase: *
Caller-Allowable-CodeBase: *
Application-Library-Allowable-Codebase: *

Even after adding these attributes, warning message still persists.
Please note: The certificate used to sign the applet is valid and is from the trusted publisher.
Kindly let me know if there is anything that I have to add in addition to the above attributes Or any other solution.

Thanks in advance.

Posted by sudha on November 11, 2013 at 01:27 AM PST #

Thanks. I looked at the forum discussion and filed JDK-8028144 for your mac issue. After filing, I used a different unauthenticated browser to make sure I could see the bug (answer: yes). The OpenJDK bug system requires an account for some actions but not all, and plenty of non-Oracle contributors have accounts.

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

I also see the same problem that Ryan reported (version-based protocol causes false warning for Permissions attribute). Can someone give me a link to view the aforementioned bug database entry (9007850)? I can't seem to find the bug database anymore.

Posted by JimN on November 11, 2013 at 03:30 PM PST #


Thanks for filing JDK-8028144. Your description there says:

"...The configuration areas are listed on docs.oracle.com/javase/7/docs/technotes/guides/jweb/properties.html and shows Mac to use /Library/Application Support/Oracle/Java/Deployment/"

This mentioned document is referring to deployment.properties (which is ~/Library/Application Support/Oracle/Java/Deployment/ not /Library/Application Support/Oracle/Java/Deployment/ as you cited), NOT the DeploymentRuleSet.jar location (which should be /Library/Application Support/Oracle/Java/Deployment/).

Posted by Brian D on November 12, 2013 at 11:21 AM PST #

Post a Comment:
Comments are closed for this entry.

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.


« April 2014