X
  • Wednesday, October 16, 2013

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.

Join the discussion

Comments ( 23 )
  • guest Thursday, October 17, 2013

    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?


  • Mathieu Fortin Friday, October 18, 2013

    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.


  • guest Friday, October 18, 2013

    Hello,

    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!


  • costlow Friday, October 18, 2013

    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.


  • Mathieu Fortin Friday, October 18, 2013

    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.


  • costlow Friday, October 18, 2013

    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.


  • costlow Friday, October 18, 2013

    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.


  • guest Monday, October 21, 2013

    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 ?


  • guest Abdul Hussain Monday, October 21, 2013

    please contact with me for java 7 security ok.


  • costlow Monday, October 21, 2013

    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.


  • guest Tuesday, October 22, 2013

    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 !!


  • mkueng Wednesday, October 23, 2013

    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.


  • guest Tuesday, October 29, 2013

    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.


  • Gorshkov Leonid Friday, November 1, 2013

    Hello,

    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?


  • costlow Friday, November 1, 2013
  • Ryan Sawatzky Friday, November 1, 2013

    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.


  • costlow Monday, November 4, 2013

    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/


  • Brian D Tuesday, November 5, 2013

    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


  • Du&scaron;an Friday, November 8, 2013

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


  • sudha Monday, November 11, 2013

    Hi,

    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.


  • costlow Monday, November 11, 2013

    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.


  • JimN Monday, November 11, 2013

    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.


  • Brian D Tuesday, November 12, 2013

    Costlow,

    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/).


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha