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

最新推荐文章于 2024-11-21 17:20:36 发布

原创最新推荐文章于 2024-11-21 17:20:36 发布 · 1.1w 阅读

5 ·

CC 4.0 BY-SA版权

web渗透测试同时被 2 个专栏收录

56 篇文章

订阅专栏

java安全

18 篇文章

订阅专栏

本文探讨了JEP290为Java引入的反序列化过滤机制，特别是针对RMI远程调用的影响。JEP290不仅提供了黑名单和白名单功能，还增强了对RMI导出对象的验证，有效地提升了系统的安全性。

 
 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的程序面临兼容性问题。
 