January 16, 2018
The full version string for this update release is 1.8.0_161-b12 (where "b" means "build"). The version number is 8u161.
JDK 8u161 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u161 are specified in the following table:
|JRE Family Version||JRE Security Baseline |
(Full Version String)
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 8u161) 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 8u161) 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.
Support has been added for the TLS session hash and extended master secret extension (RFC 7627) in JDK JSSE provider. Note that in general, server certificate change is restricted if endpoint identification is not enabled and the previous handshake is a session-resumption abbreviated initial handshake, unless the identities represented by both certificates can be regarded as the same. However, if the extension is enabled or negotiated, the server certificate changing restriction is not necessary and will be discarded accordingly. In case of compatibility issues, an application may disable negotiation of this extension by setting the System Property
false in the JDK. By setting the System Property
false, an application can reject abbreviated handshaking when the session hash and extended master secret extension is not negotiated. By setting the System Property
false, an application can reject connections that do not support the session hash and extended master secret extension.
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.
The JDK SunJSSE implementation now supports the TLS FFDHE mechanisms defined in RFC 7919. If a server cannot process the
supported_groups TLS extension or the named groups in the extension, applications can either customize the supported group names with
jdk.tls.namedGroups, or turn off the FFDHE mechanisms by setting the System Property
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
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.
In 8u161, 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.
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").
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.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.
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.
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. Please refer to that file for more information on this property.
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.
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.
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:
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/cryptoroadmap for planned restrictions to signed JARs and other security components.
New public attributes,
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.
RMIConnectorServer.CREDENTIAL_TYPES is superseded by
RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and has been removed.
The following are some of the notable bug fixes included in this release:
Web-start applications cannot be launched when clicking JNLP link from IE 11 on Windows 10 Creators Update when 64-bit JRE is installed. Workaround is to uninstall 64-bit JRE and use only 32-bit JRE.
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 8u161 Bug Fixes page.