RFR 9: JEP 290: Filter Incoming Serialization Data

[Roger Riggs]

Hi Brian,

On 7/25/2016 1:05 PM, Brian Goetz wrote:
> A few more comments:
>
>  - Do you want to tag OIF as a functional interface?  (I think yes, 
> you intend to use this with lambdas.)
ok
>
>  - Need explanation of what happens when someone returns UNDECIDED -- 
> and perhaps some motivating explanation of why it is there at all, 
> rather than just returning boolean.
I expanded on the explanation in the class javadoc[4].
A filter may be passed a class that is out of the intended scope of the 
filter and
would be misleading for it to report true or false when it did not have 
correct answer.
Or it may be passed no object, only the depth or number of refs and 
doesn't care about other parameters.
The enum result allows the filter to be explicit that it checked its 
conditions and did not make an arbitrary
decision about inputs if it did not care about any of them.

>
>  - Are we sure we want to pass a Class, rather than a class name, to 
> the filter?  Passing a Class means that the serialization layer may 
> cause the class to be loaded, even if the deserialization is 
> ultimately rejected -- and therefore a malicious stream can force 
> class loading (whose <clinit> may have side-effects.)  It would be 
> nicer if a rejected stream didn't cause extraneous classes to be loaded.
Serialization has mechanisms to resolve classes and those are carefully 
controlled to find the right
classloader, etc.   Serialization already does class lookups without 
triggering initialization to avoid early
execution.  Initialization is (AFAIK) deferred until an instance is created.

With a class, the filter can do more interesting and useful checks, for 
example checking the inheritance
and interfaces, and module without having to repeat (correctly) the work 
done to resolve the class in the right context.

Thanks, Roger

Links:

Webrev:
[1] http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/

SpecDiff:
[2] http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html

Javadoc (subset)
[3] 
http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html

[4] 
http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html



>
> On 7/19/2016 10:02 AM, Roger Riggs wrote:
>> Please review the design, implementation, and tests of JEP 290: 
>> Filter Incoming Serialization Data[1]
>>
>> It allows incoming streams of object-serialization data to be 
>> filtered in order to improve both security and robustness.
>> The JEP[1] has more detail on the background and scope.
>>
>> The core mechanism is a filter interface implemented by serialization 
>> clients and set on an |ObjectInputStream|. The filter is called 
>> during the deserialization process to validate the classes being 
>> deserialized, the sizes of arrays being created, and metrics 
>> describing stream length, stream depth, and number of references as 
>> the stream is being decoded.
>>
>> A process-wide filter can be configured that is applied to every 
>> ObjectInputStream.
>> The API of ObjectInputStream can be used to set a custom filter to 
>> supersede or augment the process-wide filter.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/
>>
>> SpecDiff:
>> http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html
>>
>> Javadoc (subset)
>> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html 
>>
>> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html 
>>
>>
>> Comments appreciated, Roger
>>
>> [1] JEP 290:   https://bugs.openjdk.java.net/browse/JDK-8154961
>>
>