反序列化漏洞的末日？JEP290机制研究

0x00 前言

先说一下JEP290这个增强建议本身其实在2016年就提出来了，本身是针对JAVA 9的一个新特性，但是随后官方突然决定向下引进该增强机制，分别对JDK 6,7,8进行了支持：

https://blogs.oracle.com/java-platform-group/filter-incoming-serialization-data-a-little-of-jdk-9-goodness-available-now-in-current-release-families

当时pwntester大神还专门发了个推标庆祝了一下：

所以官方从8u121，7u13，6u141分别支持了这个JEP。

我为什么现在才来说这个case，因为最近测一个RMI的漏洞过程中，发现居然默认情况下把反序列化给拦截掉了，看了异常信息，发现是JDK本身造成的。后来才知道，原来这个java 9 的特性早就移植到6,7,8了。因此打算着重讨论下这个新的机制对RMI序列化的影响。

0x01 JEP290介绍

JEP290主要描述了这么几个机制：

（1）提供一个限制反序列化类的机制，白名单或者黑名单

（2）限制反序列化的深度和复杂度

（3）为RMI远程调用对象提供了一个验证类的机制

（4）定义一个可配置的过滤机制，比如可以通过配置properties文件的形式来定义过滤器

实际上就是为了给用户提供一个更加简单有效并且可配置的过滤机制，以及对RMI导出对象执行检查。

其核心实际上就是提供了一个名为 ObjectInputFilter 的接口，用户在进行反序列化操作的时候，将 filter 设置给 ObjectInputStream 对象。这里就是调用 setInternalObjectInputFilter 即可：

每当进行一次反序列化操作时，底层就会根据 filter 中的内容来进行判断，从而防止恶意的类进行反序列化操作。此外，还可以限制反序列化数据的信息，比如数组的长度、字节流长度、字节流深度以及使用引用的个数等。filter 返回 accept，reject 或者 undecided 几个状态，然后用户根据状态进行决策。

而对于RMI来说，主要是导出远程对象前，先要执行过滤器逻辑，然后才进行接下来的动作，即对反序列化过程执行检查。

此外，还提供了两种可配置过滤器的方式：

（1）通过设置jdk.serialFilter这个System.property

（2）直接通过conf/security/java.properties文件进行配置

具体规则方面的内容可以直接参考原始链接：

http://openjdk.java.net/jeps/290

0x02 RMI的过滤机制

RMI这个就不多介绍了，给出一张原理图：

RMI将网络通信的部分进行了抽象，这部分逻辑对于用户来说是透明的，其实是通过动态代理机制来实现的，通过Stub和Skel这两个代理对象，完成了对远程对象的调用。

扯远了，我们还是看看RMI中新加入的过滤机制。

首先先要复现该问题，自己写一个 RMI Server，然后启动起来。之后，写一个 RMI Client，调用 bind 方法将恶意的类发送给 Server。结果直接抛出异常：

同时 Server 的控制台打印出来错误日志：

可以看到，是在处理远程对象代理的时候，没有通过 filter 的校验从而报错。

我使用的是 8u131 进行调试，直接来到 RegistryImpl_Skel 类中的46行代码，这里就是导出远程对象：

readObject 正是在执行反序列化操作，单步跟进，就来到了 ObjectInputStream 的 readObject 方法中，调用的是 readObject0 方法：

接下来是 readOrdinaryObject-> radClassDesc->readProxyDesc，然后获取里面的接口并调用 filterCheck 方法一个个检查，最后再对对象本身进行一次检查：

来到filterCheck方法中：

可以看到这里调用了 ObjectInputStream 中的 serialFilter 属性的 checkInput 方法，最后真正检查的是 RegistryImpl.registryFilter 方法，针对远程对象的检查条件如下：

return String.class != var2 &&   
!Number.class.isAssignableFrom(var2) &&   
!Remote.class.isAssignableFrom(var2) &&   
!Proxy.class.isAssignableFrom(var2) &&   
!UnicastRef.class.isAssignableFrom(var2) && !RMIClientSocketFactory.class.isAssignableFrom(var2) && !RMIServerSocketFactory.class.isAssignableFrom(var2) && !ActivationID.class.isAssignableFrom(var2) &&   
!UID.class.isAssignableFrom(var2) ? Status.REJECTED : Status.ALLOWED;  

可以看到直接把 AnnotationInvocationHandler 给禁用掉了，所以这个方法肯定是要返回 REJECTED 状态了，因此直接就抛了异常出来。

0x03 思考

ObjectInputFilter 的引入是给了用户一个非常方便并且很官方的反序列化过滤机制，因此用好它可以很方便的写出过滤代码，思考一下反序列化刚出现的那会儿，还得自己去编码实现过滤机制，稍有不慎就会出问题。但是有了 Filter 机制，并不代表一定不会出问题，原因是开发者使用黑名单机制还是有可能漏掉一些lib或者有新的 gadgets 出现。所以以后反序列化漏洞还是可以玩一段时间，毕竟底层开发者技术跟进需要时间。

最后说一句，RMI 这种粗暴的过滤我实在保留意见，因为可能会让很多基于 RMI 的程序面临兼容性问题。

本文由 华域联盟 原创撰写：华域联盟 » 反序列化漏洞的末日？JEP290机制研究

转载请保留出处和原文链接：https://www.cnhackhy.com/106051.htm