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

[Nasser Ebrahim]

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