Fix Version/s: 17
Compatibility Kind:binary, behavioral
Compatibility Risk Description:The compatibility risk is low.
Some of the behavior of JEP 290 has in been reimplemented in terms of a builtin FilterFactory that can be replaced by the applications.
Functions to create filters and combine filters are new and of themselves not a risk.
Interface Kind:Java API, System or security property
Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation.
Deserializing untrusted data is an inherently dangerous activity because the content of the incoming data stream determines the objects that are created, the values of their fields, and the references between them. In many typical uses the bytes in the stream are received from an unknown, untrusted, or unauthenticated client. By 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 can compromise the integrity of application objects, library objects, and even the Java runtime. The key to disabling deserialization attacks is to prevent instances of arbitrary classes from being deserialized, thereby preventing the direct or indirect execution of their methods.
Context-Specific Deserialization Filtering is used to select the filter for each stream when the stream is created, in the constructor or before first invocation to read objects. The filter factory can be provided by the application and is configured to apply across all threads and frameworks. The factory is designed and implemented for the specific application purpose and should take into account all deserialization execution contexts that are to be protected within the Java runtime. The filter factory is invoked in the constructor of ObjectInputStream to select and return the deserialization filter for the stream.
An application’s developer is in the best position to understand the structure and operation of the application’s components. This enhancement enables the application developer to construct and apply filters to every deserialization operation.
The ObjectInputFilter, ObjectInputFilter.Config, and ObjectInputStream classes have been updated and extended to specify the behavior described above and in JEP 415.
A new system property "jdk.serialFilterFactory" has been added to enable configuring the filter factory on the command line.
The methods included in ObjectInputFilter.Config: - Get and set the filter factory Static methods added to ObjectInputFilter: - Creation of filters based on Predicates on classes found in the stream - To merge the results of filters - To support rejecting classes that are not explicitly allowed or rejected.
The June 8 specdiff is attached with some editorial updates and changes to configuration properties and available for browsing at:
The spec and implementation review is in progress: