Yesterday it was announced that Java SE 8u111 (SE 8 update 111) and Java SE 8u112 are available, and “Oracle strongly recommends that most Java SE users upgrade to the latest Java 8 update, which includes important security fixes.” See the October Advisory on security from Oracle.
Java SE 8u111 is a critical patch update (CPU), and Java SE 8u112 is a patch-set update (PSU), including all of 8u111 plus additional features.
Critical patch updates (a collection of patches for multiple security vulnerabilities) are released on the Tuesday closest to the 17 of January, April, July and October. They are the primary mechanism for the release of security patches for all of Oracle’s products. The JRE released expires with the release of the next critical patch update, this one will expire on the 17th January 2017.
Some of the changes in Java SE 8 update 111 are as follows:
The Java Cryptography Extension (JCE) is a framework for implementing encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. See this document for more information. To support longer key lengths and stronger signature algorithms, there is a new JCE Provider Code Signing root certificate authority. This will be the default from now on.
Service Menu services
The AWT Menu class represents pull-down menu components, deployed from a menu bar. In
client-libs/java.awt, there is a fix to improve state synchronisation between menus and their containers.
Disable Basic authentication for HTTPS tunnelling
Basic authentication scheme has been deactivated by default by adding
Basic to the
jdk.http.auth.tunneling.disabledSchemes networking property. This property can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS or proxying plain HTTP. It can be reactivated by removing
Basic from the
jdk.http.auth.tunneling.disabledSchemes networking property, or on the command line by setting the system property of the same name to empty (“”).
Restrict JARs signed with weak algorithms and keys
Signing a JAR allows you to grant verified users security privileges that they wouldn’t ordinarily have.
As part of the Oracle JRE and JDK Cryptographic Roadmap, the way signed JAR files are verified will be restricted. This release treats JAR files signed with the MD2 algorithm and RSA keys less than 1024 bits as unsigned. This list of disabled algorithms is controlled by the
jdk.jar.disabledAlgorithms property in the
java.security file. The property contains the list of disabled algorithms and key sizes for cryptographically signed JAR files.
Any JAR files affected will need to be re-signed with a stronger algorithm or key size. Otherwise an (unrecommended) option is to revert the restrictions by removing the applicable weak algorithms or key sizes from the
In the 17th January 2017 update, JARs signed with MD5 algorithms will be treated as unsigned.
Java SE 8u112
Additional changes are in the PSU: Java SE 8u112.
A change has been made to security-libs/java.security, so that
SecureRandom is no longer offered by default by the SunPKCS11 Provider.
Random, and is a cryptographically strong random number generator (RNG). It produces a non-deterministic output and complies with FIPS 140-2, Security Requirements for Cryptographic Modules.
On the Solaris operating system, it is now disabled by default as the native PKCS11 implementation has poor performance. It can be re-enable it by removing “
SecureRandom” from the disabledMechanisms list in
SecureRandom class has also had performance improvements made to it, allowing for synchronization to be removed from the
java.security.SecureRandom.nextBytes(byte bytes) method in the JDK implementation.
A number of bug fixes have also been made, including:
- Signed JWS application unexpectedly asks for permission to open a socket (JDK-8157785)
- Deadlock in Java Web Start application involving JNLPClassLoader (JDK-8161700)
- Jdk 8u71 fails to install with no error message (JDK-8148167)
The full list is here.