Fix Version/s: 17
Compatibility Risk Description:Filter Factory API and behavior is new and has not been released.
Interface Kind:Java API
Remove "OVERRIDE" special handling of
in JEP 415: Context-specific Deserialization Filters.
The restriction on replacing a filter factory using the <code class="prettyprint" data-shared-secret="1656993121423-0.18957872995546887">Config.setSerialFilterFactory</code> makes it harder to use and only marginally safer.
* <p> If only `jdk.serialFilter` is set and not `jdk.serialFilterFactory` the builtin * filter factory, compatible with previous versions, is set and can not be replaced, * use "OVERRIDE" to override the builtin filter factory.
The problematic part of this is the coupling between the jdk.serialFilter property
and using the <code class="prettyprint" data-shared-secret="1656993121423-0.18957872995546887">Config.setSerialFilterFactory</code> method. In that case, the method
cannot be used without including
jdk.serialFilterFactory=OVERRIDE on the command line.
The coupling is an attempt to prevent the application from disabling the command line
jdk.serialFilter by supplying a faulty or insecure filter factory,
perhaps surreptitiously. The window of opportunity to install such a filter factory
is very small because the filter factory can only be set before the first
<code class="prettyprint" data-shared-secret="1656993121423-0.18957872995546887">ObjectInputStream</code> is created; after that it can not be changed so no amount
of clever gadgetry could change it as the result of some deserialization.
A filter factory defined on the command line with
is not replaceable using the
Reviews of the application use of deserialization and filter factory should be able
to assert correct use and behavior.
Past/Current Use of the JVM-wide Filter
The out-of-the-box behavior is compatible with the implementation of JEP 290 in JDK 9-16.
However, that behavior is not robust to effectively protect complex applications.
It utilizes an overly simplified model of a single reject and allow list and
the filter can be overridden on a stream-by-stream basis, with no assurance that
the JVM-wide filter defined by
jdk.serialFilter is not ignored.
Expected Use of Filter Factory
It is expected that filter factories will be developed and deployed that assemble and incorporate reject and allow-lists for individual modules or jar files based on context-specific information to supply a filter for each deserialization stream. The allow and reject lists can be maintained in a database or web service and updated dynamically.
The jdk.serialFilter property on the command line will be used primarily as a stop-gap reject list for temporary or emergency use.
In this and similar use cases, the filter factory for the application would be built-in
to the application initialization using the Config.setSerialFilterFactory
and that factory would incorporate the filter supplied by
JEP 415 should promote use of richer protection mechanisms and not make them more difficult to use.
Remove descriptions of "OVERRIDE" in ObjectInputFilter, ObjectInputFilter.Config.
Specdiff attached in filterfactory-diffs-16_Jun_21.zip