7u171 Update Release Notes

Java™ SE Development Kit 7, Update 171 (JDK 7u171)

January 16, 2018

The full version string for this update release is 1.7.0_171-b11 (where "b" means "build"). The version number is 7u171.

IANA Data 2017c

JDK 7u171 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 7u171 are specified in the following table:

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 7u171) will expire with the release of the next critical patch update scheduled for April 17, 2018.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 7u171) on May 17, 2018. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

New Features

security-libs/javax.crypto

Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits

Enhance the JDK security providers to support 3072-bit DiffieHellman and DSA parameters generation, pre-computed DiffieHellman parameters up to 8192 bits and pre-computed DSA parameters up to 3072 bits.

See JDK-8072452

security-libs/java.security

Support keystore type detection for JKS and PKCS12 keystores

To aid interoperability, the Java keystore type JKS now supports keystore compatibility mode by default. This mode enables JKS keystores to access both JKS and PKCS12 file formats. To disable keystore compatibility mode, set the Security property keystore.type.compat to the string value false.

See JDK-8062552

core-svc/java.lang.management

New system property for the remote JMX connector

New JMX agent property - jmxremote.host

A new property, com.sun.management.jmxremote.host, is introduced that specifies the bind address for the default JMX agent. If the latter is not specified, the default JMX agent will listen on all interfaces (0.0.0.0) and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of the InetAddress.getLocalHost() method.

• Name: com.sun.management.jmxremote.host
• Definition : Specifies the bind address for the default JMX agent. It can be specified via command line while starting the JVM or as part of agent config file (management.properties).
• Value: IP address of any network interface of the machine

See JDK-6425769

other-libs/corba

Add additional IDL stub type checks to org.omg.CORBA.ORBstring_to_object method

Applications that either explicitly or implicitly call org.omg.CORBA.ORB.string_to_object, and wish to ensure the integrity of the IDL stub type involved in the ORB::string_to_object call flow, should specify additional IDL stub type checking. This is an "opt in" feature and is not enabled by default.

To take advantage of the additional type checking, the list of valid IDL interface class names of IDL stub classes is configured by one of the following:

• Specifying the security property com.sun.CORBA.ORBIorTypeCheckRegistryFilter located in the file conf/security/java.security in Java SE 9 or in jre/lib/security/java.security in Java SE 8 and earlier.

• Specifying the system property com.sun.CORBA.ORBIorTypeCheckRegistryFilter with the list of classes. If the system property is set, its value overrides the corresponding property defined in the java.security configuration.

If the com.sun.CORBA.ORBIorTypeCheckRegistryFilter property is not set, the type checking is only performed against a set of class names of the IDL interface types corresponding to the built-in IDL stub classes.

JDK-8160104 (not public)

Changes

security-libs/javax.crypto

Provider default key size is updated

This change updates the JDK providers to use 2048 bits as the default key size for DSA instead of 1024 bits when applications have not explicitly initialized the java.security.KeyPairGenerator and java.security.AlgorithmParameterGenerator objects with a key size.

If compatibility issues arise, existing applications can set the system property jdk.security.defaultKeySize introduced in JDK-8181048 with the algorithm and its desired default key size.

JDK-8178466 (not public)

security-libs/javax.crypto

Stricter key generation

The generateSecret(String) method has been mostly disabled in the javax.crypto.KeyAgreement services of the SUN and SunPKCS11 providers. Invoking this method for these providers will result in a NoSuchAlgorithmException for most algorithm string arguments. The previous behavior of this method can be re-enabled by setting the value of the jdk.crypto.KeyAgreement.legacyKDF system property to true (case insensitive). Re-enabling this method by setting this system property is not recommended.

JDK-8185292 (not public)

security-libs/javax.crypto

Unlimited cryptography enabled by default

The JDK uses the Java Cryptography Extension (JCE) Jurisdiction Policy files to configure cryptographic algorithm restrictions. Previously, the Policy files in the JDK placed limits on various algorithms. This release ships with both the limited and unlimited jurisdiction policy files, with unlimited being the default. The behavior can be controlled via the new crypto.policy Security property found in the /lib/java.security file. Refer to that file for more information on this property.

See JDK-8170157

security-libs/javax.crypto

RSA public key validation

In 7u171, the RSA implementation in the SunRsaSign provider will reject any RSA public key that has an exponent that is not in the valid range as defined by PKCS#1 version 2.2. This change will affect JSSE connections as well as applications built on JCE.

JDK-8174756 (not public)

security-libs/javax.net.ssl

Restrict Diffie-Hellman keys less than 1024 bits

Diffie-Hellman keys less than 1024 bits are considered too weak to use in practice and should be restricted by default in SSL/TLS/DTLS connections. Accordingly, Diffie-Hellman keys less than 1024 bits have been disabled by default by adding DH keySize < 1024 to the jdk.tls.disabledAlgorithms security property in the java.security file. Although it is not recommended, administrators can update the security property (jdk.tls.disabledAlgorithms) and permit smaller key sizes (for example, by setting DH keySize < 768).

JDK-8148108 (not public)

security-libs/java.security

keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms

With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing TrustedCertificateEntry, either in the keystore directly operated on or in the cacerts keystore when the -trustcacerts option is specified for the -importcert command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file cert contains a CA certificate signed with a weak signature algorithm, keytool -printcert -file cert and keytool -importcert -file cert -alias ca -keystore ks will print out a warning, but after the last command imports it into the keystore, keytool -list -alias ca -keystore ks will not show a warning anymore.

An algorithm or a key is weak if it matches the value of the jdk.certpath.disabledAlgorithms security property defined in the conf/security/java.security file.

See JDK-8171319

core-libs/java.rmi

The RMI Registry filter is relaxed to allow binding arrays of any type

The RMI Registry built-in serial filter is modified to check only the array size and not the component type. The maximum array size is increased to 1,000,000. The override filter can be used to decrease the limit. Array sizes greater than the maxarray limit will be rejected and otherwise will be allowed. The java.security file contains more information about the sun.rmi.registry.registryFilter property and it will be updated in the conf/security/java.security configuration file to better describe the default behavior and how to override it.

See JDK-8185346

security-libs/javax.net.ssl

Disable exportable cipher suites

To improve the strength of SSL/TLS connections, exportable cipher suites have been disabled in SSL/TLS connections in the JDK by the jdk.tls.disabledAlgorithms Security Property.

See JDK-8163237

security-libs/java.security

Disable JARs signed with DSA keys less than 1024 bits

DSA keys less than 1024 bits have been added to the jdk.jar.disabledAlgorithms Security property in the java.security file. This property contains a list of disabled algorithms and key sizes for signed JAR files. If a signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:

1. Applets or Web Start Applications
2. Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

Running jarsigner -verify -verbose on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use this command : jarsigner -verify -verbose test.jar

If the file in this example was signed with a weak key such as 512 bit DSA, this output would be seen:

     
- Signed by "CN=weak_signer"
    Digest algorithm: SHA1
    Signature algorithm: SHA1withDSA, 512-bit key (weak)

To address the issue, the JAR file will need to be re-signed with a stronger key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the zip utility, as follows:

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

Periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/en/jre-jdk-cryptoroadmap.html for planned restrictions to signed JARs and other security components.

JDK-8185909 (not public)

xml/jax-ws

Added wsimport tool command line option -disableXmlSecurity

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:

• DOCTYPE declaration is disallowed in documents
• External general entities are not included by default
• External parameter entities are not included by default
• External DTDs are completely ignored

To restore the previous behavior:

• Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
• Use the wsimport tool command line option -disableXmlSecurity

JDK-8182873 (not public)

core-svc/javax.management

JMX Connections need deserialization filters

New public attributes, RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and RMIConnectorServer.SERIAL_FILTER_PATTERN have been added to RMIConnectorServer.java. With these new attributes, users can specify the deserialization filter pattern strings to be used while making a RMIServer.newClient() remote call and while sending deserializing parameters over RMI to server respectively.

The user can also provide a filter pattern string to the default agent via management.properties. As a result, a new attribute is added to management.properties.

Existing attribute RMIConnectorServer.CREDENTIAL_TYPES is superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and has been removed.

JDK-8159377 (not public)

security-libs/java.security

Add warnings to keytool when using JKS and JCEKS

When keytool is operating on a JKS or JCEKS keystore, a warning may be shown that the keystore uses a proprietary format and migrating to PKCS12 is recommended. The keytool's -importkeystore command is also updated so that it can convert a keystore from one type to another if the source and destination point to the same file.

JDK-8182879 (not public)

security-libs/java.security

keytool now prints out information of a certificate's public key

Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of Subject Public Key Algorithm: <size>-bit RSA key, where <size> is the key size in bits (ex: 2048).

See JDK-8029659

xml/jaxp

JDK Transform, Validation and XPath use the system-default parser

Java SE 9 changes the JDK's Transform, Validation and XPath implementations to use the JDK's system-default parser even when a third party parser is on the classpath. In order to override the JDK system-default parser, applications need to explicitly set the new System property jdk.xml.overrideDefaultParser.

1. Support through the API

   The overrideDefaultParser property is supported by the following APIs:

   1. TransformerFactory::setFeature
   2. SchemaFactory::setFeature
   3. Validator::setFeature
   4. XPathFactory::setFeature
2. Support as a System property

The overrideDefaultParser property can be set through the System.setProperty.

3. Support as a JAXP system property

The overrideDefaultParser property can be set in the JAXP configuration file jaxp.properties.

4. Scope and order

The overrideDefaultParser property follows the same rule as other JDK JAXP properties in that a setting of a narrower scope takes preference over that of a wider scope. A setting through the API overrides the System property which in turn overrides that in the jaxp.properties file.

JDK-8186080 (not public)

Bug Fixes

The following are some of the notable bug fixes included in this release:

hotspot/compiler

Compilers accept modification of final fields outside initializer methods

According to the Java VM Specification, final fields can be modified by the putfield byte code instruction only if the instruction appears in the instance initializer method <init> of the field's declaring class. Similar, static final fields can be modified by a putstatic instruction only if the instruction appears in the class initializer method <clinit> of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53, final fields can be modified in any method of the class declaring the field (not only class/instance initializers).

See JDK-8157181

This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 7u171 Bug Fixes page.