• Categories
  • Search
Tuesday, October 18, 2016

Oracle JRE will no longer trust MD5-signed code by default

Update notice

When this blog was originally posted the change was
scheduled to occur with the January 2017 Critical Patch Update.   In response
to requests for additional time to prepare for this change Oracle now
plans to deliver this change with the April 2017 Critical Patch Update. 
The blog has been updated accordingly.

Beginning with the April 2017 Critical Patch Update, JAR files
signed using MD5 will no longer be considered as signed by the Oracle
JRE.  Affected MD5-signed JAR files will no longer be considered trusted
and as a result will not be able to run by default, such as in the case
of Java applets, or Java Web Start applications.

This change in the JRE behavior is required because MD5 is no
longer considered secure and is widely considered unsuitable for
security use.  In fact, the MD5 with RSA algorithm stopped being the
default JAR signing option with Java SE 6 released back in 2006.  It is
critical that weak hashing algorithms (such as MD5) be deprecated when
they are known to be weak so as to maintain the trust in the
verification mechanism they provide.  

This change affecting MD5-signed JARS will be enabled by default no
sooner than with Oracle Java SE 8u131 which will be released with the
April 2017 Critical Patch Update, as well as in the corresponding
releases of Oracle Java SE 7, Oracle Java SE 6 and Oracle JRockit R28,
which will be available to qualified customers through My Oracle
Support.

In order to prepare for this upcoming change, developers need to
verify that their JAR files have not been signed using MD5.  You can do
this with your own JARs by verifying your build process signs JARs using
Java 6 or later without having deliberately chosen MD5.  If you are
using JARS you did not sign or build yourself, you need to contact your
vendor for more information.  If it can no longer be established if a
JAR you are using has been signed with MD5, the recommended practice is
to re-sign affected JAR files using a more modern algorithm.  Be sure to
remove any existing MD5 signatures first before re-signing using the
zip utility as follows:

zip -d test.jar 'META-INF/*.SF'
'META-INF/*.RSA' 'META-INF/*.DSA'

More technical information can be found in the October 2016 Critical Patch Update Release Notes for Java SE.

Oracle has already informed a number of software vendors, including
source licensees, of the upcoming changes.  Users concerned about the
effect of this change on third party applications should contact their
respective vendor.

Cryptography is a dynamic field.  In order to keep users and
developers informed about upcoming changes in this area, Oracle has
recently published a new web page at java.com/cryptoroadmap
This page provides information about upcoming cryptographic changes in
Oracle JRE and Oracle JDK, and related technical instructions.

Join the discussion

Comments ( 4 )
  • guest Friday, October 21, 2016

    Is it possible to validate with "jarsigner -verify" or "keytool -printcert" or any other JDK-shipped tools what algorithm is used in an existing JAR file? I have a few JARs that have been signed with a custom tool (not jarsigner) and I have no idea what algorithm that tool uses... (but I assume it is fine since it supports timestamping and IIRC timestamping was added after the change from MD5 to SHA1)


  • Erik Costlow Friday, October 21, 2016

    Yes, I will post about that along with some other things later.

    Use the recent 8u111+ and add a flag:

    jarsigner -verify -J-Djava.security.debug=jar

    In January (when the change above happens), this should move into the normal -verbose option.


  • Paul Bransford Monday, October 31, 2016

    Will it be possible to disable this, or perhaps allow specific signers? I'm concerned about defunct vendors who will not be around to update their jars themselves, and where we may not be able to modify the jar ourselves (eg to strip and resign) - such as embedded devices.


  • Erik Costlow Monday, October 31, 2016

    Yes to disabling/changing, no to specific signers since the issue is with the signing algorithm.

    The instructions to revert the change are at the crypto roadmap under the MD5 change for January and involve changing the jdk.jar.disabledAlgorithms property. I wouldn't recommend that approach though.

    Assuming you're running the signed apps as Web Start or Applets, you should have an easier time whitelisting them.

    Within an organization, use a Deployment Rule Set and create a run rule for the app's location. This is "does a rule exist for this application" on http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_flow.html

    For unmanaged individuals, they can use their own Exception Site List which may not work as well due to its location on the flowchart.


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

Visit the Oracle Blog

 

Contact Us

Oracle

Integrated Cloud Applications & Platform Services