Clarification for adding classes shipped with JDK to sun.rmi.registry.registryFilter property in java.security file

Thu Feb 1 22:04:08 UTC 2018

Hi Nasser,

There is a tradeoff between convenience and security. The risk can be 
reduced, in part, by
keeping the set of trusted classes as small as possible. White-lists 
should be application specific,
with the selected classes carefully reviewed and only include what is 
needed.

Regards, Roger

On 1/29/2018 8:08 AM, Nasser Ebrahim wrote:
> Hi Roger,
>   
> Thank you for your inputs. I agree with you that logging the filtering
> action can help developers to easily identify the classes which are failed
> due to the new filtering mechanism.
>   
> However, it may not be fair to ask the application developers to add the
> basic JDK classes when Java introduced the filtering mechanism. For
> application classes, it makes sense for developer to use the logging
> mechanism to identify the classes to be added to the white list.
>   
> I think JDK should add all its standard classes (at least the base
> packages) to white list by default rather than asking each end user to add
> to the white list.
>   
> Please clarify whether there is any reason for not adding the standard JDK
> classes by default to the white list as they are trusted code.
>   
> Thank you,
> Nasser Ebrahim
>
>
>
> From:   Roger Riggs <Roger.Riggs at Oracle.com>
> To:     core-libs-dev at openjdk.java.net
> Date:   01/19/2018 08:50 PM
> Subject:        Re: Clarification for adding classes shipped with JDK to
> sun.rmi.registry.registryFilter property in java.security file
> Sent by:        "core-libs-dev" <core-libs-dev-bounces at openjdk.java.net>
>
>
>
> Hi Vipin,
>
> A couple of suggestions to make working with serialization filters easier.
>
> JEP 290 enabled logging of filtering actions by setting
> java.io.serialization.level =  FINEST.
> Add that to the logging.properties and supply it on the command line with
> "-Djava.util.logging.config.file=logging.properties".
> If set to FINEST, it will log every call to the filter with the
> arguments of class, array size, etc.
> If set to FINE, it will log only the cases where the filter rejects
> based on its arguments.
>
> The pattern based filters can allow or disallow entire packages.
> For example, "java.net.**" will allow any class in any package with a
> "java.net." prefix.
>
> For development purposes, serialized classes for the registry could be
> identified using a filter of "*"
> with logging enabled as FINEST and examining the log.
>
> Expanding the white list for the registry is a possibility with a very
> conservative
> evaluation of specific cases.
>
> Regards, Roger
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_jeps_290&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yiMdG4h7wT1IHGC_YAWYv5USAuyCyINm1bo82D5y5bY&m=12RWeCnDad-pQO_PzN0K_mAliSGWmNyH_hOob40MLlA&s=HSk5hl04g1T39ZWtVoEpYFo0CYAkuLPyfQlKA2eh5Us&e=
>
>
>
> On 1/16/2018 7:21 AM, Vipin Mv1 wrote:
>> Hi,
>>
>> After upgrading to oracle 8u121-b12, I get following Exception when
> running
>> the following testcase.
>>
>> import java.io.*;
>> import java.net.InetAddress;
>> import java.rmi.*;
>> import java.rmi.registry.*;
>> import java.security.Security;
>>
>> /* @test
>>    * @run main/othervm RegistryFilterTest
>>    */
>>
>> public class RegistryFilterTest {
>>
>>           private static int port = 12345;
>>           private static Registry registry;
>>
>>           static class RemoteObj implements Serializable, Remote {
>>                   private static final long serialVersionUID = 01L;
>>
>>                   final Object obj;
>>
>>                   RemoteObj(Object obj) {
>>                           this.obj = obj;
>>                   }
>>
>>
>>           }
>>
>>
>>           public static void main(String[] args) throws Exception{
>>
>>               InetAddress in = InetAddress.getLocalHost();
>>               LocateRegistry.createRegistry(port);
>>               Registry registry = LocateRegistry.getRegistry("localhost",
>> port);
>>               registry.bind("InetAddress", new RemoteObj(in));
>>               registry.unbind("InetAddress");
>>               System.out.println("RMI Registry Test Passed");
>>
>>           }
>>
>> }
>>
>> TestResults
>> -----------------------
>> Jan 12, 2018 5:32:18 PM java.io.ObjectInputStream filterCheck
>> INFO: ObjectInputFilter REJECTED: class java.net.InetAddress, array
> length:
>> -1, nRefs: 5, depth: 2, bytes: 216, ex: n/a
>> Caused by: java.io.InvalidClassException: filter status: REJECTED
>>       at
> java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1406)
>>       at java.io.ObjectInputStream.readNonProxyDesc
>> (ObjectInputStream.java:1997)
>>       at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1877)
>>       at java.io.ObjectInputStream.readOrdinaryObject
>> (ObjectInputStream.java:2170)
>>       at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1698)
>>       at java.io.ObjectInputStream.defaultReadFields
>> (ObjectInputStream.java:2415)
>>       at java.io.ObjectInputStream.readSerialData
>> (ObjectInputStream.java:2339)
>>       at java.io.ObjectInputStream.readOrdinaryObject
>> (ObjectInputStream.java:2197)
>>       at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1698)
>>       at
> java.io.ObjectInputStream.readObjectImpl(ObjectInputStream.java:540)
>>       at java.io.ObjectInputStream.readObject(ObjectInputStream.java:475)
>>       ... 16 more
>>
>> I understand it is due to the new serialization Filtering mechanism
>> introduced to RMI Registry and Distributed Garbage Collection as a part
> of
>> the following fixes.
>>
>> JDK-8160108 Implement Serialization Filtering
>> JDK-8156804: Better constraint checking(not public)
>>
>> As a result, a new default white list has been introduced for
> RMIRegistry
>> which allows deserialization only to limited set of classes by default.
>> Which are
>>
>> String.class
>> java.lang.Number.class
>> java.rmi.Remote.class
>> java.lang.reflect.Proxy.class
>> sun.rmi.server.UnicastRef.class
>> java.rmi.server.RMIClientSocketFactory.class
>> java.rmi.server.RMIServerSocketFactory.class
>> java.rmi.activation.ActivationID.class
>> java.rmi.server.UID.class
>> and their subclasses.
>>
>> It also enabled provisions to increase the default white list by
>>
>> 1. updating property "sun.rmi.registry.registryFilter" in java.security
>> file
>> 2. adding -Dsun.rmi.registry.registryFilter in java command line
>>
>> Though the current solution is straight forward, it is difficult from an
>> application point of view to identify such classes without running the
>> application multiple times to come up with comprehensive list to be
>> allowed. This would be a overhead to the developer and should be avoided
> at
>> least for classes shipped with JDK (for example, java.net.InetAddress as
>> used in testcase).
>>
>> I assume that default list is very limited to reduce the chances of
> getting
>> exploited by serialization vulnerability. I think, we can spare public
>> packages shipped with JDK by adding them to
>> "sun.rmi.registry.registryFilter" in java.security file out of the box.
>>
>> Please let me know your views.
>>
>> Thanks & Regards,
>> Vipin MV
>
>
>
>