Content area
Full Text
Java 17 has moved to a second and final release candidate stage as of August 19. Among the capabilities set for the new version of standard Java are context-specific deserialization filters support, which is a security enhancement, and a preview of pattern matching for switch statements and expressions.
Due as a production release on September 14, Java Development Kit (JDK) 17 will be a long-term-support (LTS) release, with extended support from Oracle expected for several years. The feature set was frozen on June 10 when JDK 17 reached an initial rampdown phase. A second rampdown phase, focused mostly on fixing bugs, was announced on July 15. The stabilization repo, jdk17, is open for critical bug fixes with approval.
Features filed as part of OpenJDK’s JDK 17 include the following:
* Context-specific deserialization filters allow applications to configure context-specific and dynamically selected deserialization filters via a JVM-wide filter factory invoked to select a filter for each serialization operation. In explaining the motivation behind this proposal, Oracle said deserializing untrusted data is an inherently dangerous activity because the content of the incoming data streams determines the objects that are created, the values of their fields, and references between them. In many uses, the bytes in the stream are received from an unknown, untrusted, or unauthenticated client. With careful construction of the stream, an adversary can cause code in arbitrary classes to be executed with malicious intent. If object construction has side effects that change state or invoke other actions, those actions could compromise the integrity of application objects, library objects, and the Java runtime. The key to disabling serialization attacks is to prevent instances of arbitrary classes from being deserialized, thereby preventing the direct or indirect execution of their methods. Deserialization filters were introduced in Java 9 to enable application and library code to validate incoming data streams before deserializing them. This code supplies validation logic as a java.io.ObjectInputFilter when it creates a deserialization stream. However, relying on a stream’s creator to explicitly request validation has limitations. JDK Enhancement Proposal 290 addressed these limitations by introducing a JVM-wide deserialization filter that can be set via an API, system properties, or security properties, but this approach also has limits, particularly in complex applications. A better approach is to...