RFR: 8264859: Implement Context-Specific Deserialization Filters [v7]

Chris Hegarty chegar at openjdk.java.net
Tue May 25 11:40:23 UTC 2021


On Mon, 24 May 2021 21:57:50 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> JEP 415: Context-specific Deserialization Filters extends the deserialization filtering mechanisms with more flexible and customizable protections against malicious deserialization.  See JEP 415: https://openjdk.java.net/jeps/415.
>> The `java.io.ObjectInputFilter` and `java.io.ObjectInputStream` classes are extended with additional
>> configuration mechanisms and filter utilities.
>> 
>> javadoc for `ObjectInputFilter`, `ObjectInputFilter.Config`, and `ObjectInputStream`:
>>     http://cr.openjdk.java.net/~rriggs/filter-factory/java.base/java/io/ObjectInputFilter.html
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move merge and rejectUndecidedClass methods to OIF.Config
>   As default methods on OIF, their implementations were not concrete and not trustable

src/java.base/share/classes/java/io/ObjectInputFilter.java line 73:

> 71:  *     var filter = ObjectInputFilter.Config.createFilter("example.*;java.base/*;!*")
> 72:  *     ObjectInputFilter.Config.setSerialFilter(filter);
> 73:  * }</pre>

It's good to have a straightforward example, but it has an implicit assumption - that the built-in filter factory is in operation ( and will not change ). I wonder if there is a way to update the example (without too much fuss), or otherwise add a textual qualification. Though, I'm not sure what this would look like.

src/java.base/share/classes/java/io/ObjectInputFilter.java line 400:

> 398:      * {@link BinaryOperator {@literal BinaryOperator<ObjectInputFilter>}} interface, provide its implementation and
> 399:      * be accessible via the {@linkplain ClassLoader#getSystemClassLoader() application class loader}.
> 400:      * The filter factory configured using the system or security property during initialization

What is the expected behaviour if the factory property is to set to a non-class or non-accessible class? The current implementation does (it probably should be more graceful) :

$ java -Djdk.serialFilterFactory=allow T
Exception in thread "main" java.lang.ExceptionInInitializerError
	at java.base/java.io.ObjectInputFilter$Config.<clinit>(ObjectInputFilter.java:537)
	at java.base/java.io.ObjectInputStream.<init>(ObjectInputStream.java:394)
	at T.main(T.java:5)
Caused by: java.lang.ClassNotFoundException: allow
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:636)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:466)
	at java.base/java.io.ObjectInputFilter$Config.<clinit>(ObjectInputFilter.java:519)
	... 2 more

-------------

PR: https://git.openjdk.java.net/jdk/pull/3996


More information about the core-libs-dev mailing list