前段时间分析了JBoss 3873和4446端口下的反序列化，受影响的版本最晚已经是2011年发布的，而JBoss EAP 6.X及WildFly\JBoss AS 7.X等后续版本，它们反序列化相关的CVE就很少了。归根结底，是因为以上所说的后续版本弃用了原来的Remoting2协议，启用了Remoting3协议。本文以Remoting3的反序列化相关问题展开分析。
Remoting3是JBoss Remoting的下一代协议，它在具备上一代协议所具有的功能的同时，还引入了以下一些性功能。
可拓展的传输协议
可以在运行时检测其他的协议
可拓展的打包策略（Marshalling Strategies）
使用强大的JBoss打包库
相比明文的Java序列化更高效
安全功能
支持SSL协议，可以保护传输数据的完整性和机密性，同时也可用来认证服务端
支持SASL框架，可进行客户端认证和授权
通过抓包对比，正如官网介绍所说，Remoting3协议不同于Remoting2的几乎明文的Java序列化数据，并且在默认配置下需要先进行客户端的认证才可使用后续的EJB3服务。
1
前面所说的可拓展的传输协议，体现在JBoss上即为HTTP服务8080端口的。Remoting3协议支持两种EJB3服务监听模式：直接监听一个端口和复用HTTP服务的端口。前者是JBoss EAP 6.X和JBoss AS 7.X使用的模式，对应的scheme是remote://，而后者是JBoss EAP 7.X和WildFly使用的模式，对应的scheme是http-remoting://或http://（视版本而定）。
端口复用这块从流量这看是比较简单，客户端先发送一个带Upgrade: jboss-remoting头的HTTP请求，然后服务端返回101状态码切换协议，后续流量则与监听端口的模式无异。
Remoting3协议服务于EJB3，而EJB3与RMI类似，支持对象传参，涉及到对象参数必然会与序列化和反序列化扯上关系。要研究Remoting3协议的反序列化机制，首先得部署一个EJB3的服务。本文后续的分析均以WildFly 8.2.1.Final为例，下载相应的版本，在启动前先使用bin/add-user.sh脚本添加一个用户。
将以下两个类编译为Jar包，并从9990端口登录到控制台，部署打包好的Jar包。
`package com.illucit.ejbremote.server; import javax.ejb.Remote; @Remote public interface ExampleService { public Object greet(Object object); } `
`package com.illucit.ejbremote.server; import javax.ejb.Stateless; @Stateless public class ExampleServiceImpl implements ExampleService { @Override public Object greet(Object object) { return object; } } `
新建一个Java项目，并将WildFly的bin/client目录下的jar包复制到项目的lib目录，同时将以上两个类也加入到项目中。然后在resource目录下添加jboss-ejb-client.properties，填入以下配置内容。
`remote.connections=default remote.connection.default.host=192.168.78.132 remote.connection.default.port = 8080 remote.connection.default.username=<username> remote.connection.default.password=<password> `
最后添加以下类作为客户端，调用远程EJB3服务。
`import com.illucit.ejbremote.server.ExampleService; import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.NamingException; import java.util.Date; import java.util.Hashtable; public class Client { public static void main(String[] args) throws Exception { System.out.printf(String.valueOf(lookupExample().greet2(new Date()))); } private static ExampleService lookupExample() throws NamingException { final Hashtable<String, String> jndiProperties = new Hashtable(); jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming"); final Context context = new InitialContext(jndiProperties); String url = "ejb:/ejb-remote-server/ExampleServiceImpl!" + ExampleService.class.getName(); System.out.println(url); return (ExampleService) context.lookup(url); } } `
首先用一个在服务端不存在的类作为参数，调用EJB3服务。在客户端抛出的异常信息的调用栈中，可以看到org.jboss.marshalling.AbstractObjectInput的readObject方法被调用。
在服务端该方法下断点，当前的类是AbstractObjectInput的子类org.jboss.marshalling.river.RiverUnmarshaller，反序列化调用自身的doReadObject方法处理。
跟进到doReadObject方法，代码中会有一个switch循环体，根据从输入流获取到的字节进入不同的分支。后续会被调用到的doReadNewObject和doReadClassDescriptor也会有一个switch循环体，想必就是官方所说的可拓展的打包策略。
通过控制输入流进入到switch循环判断的字节，从而可以控制返回类示例或者反序列化对象。笔者梳理了这些switch循环体的分支，整理了几个会返回反序列化对象的流程，他们无一例外的会直接readObject反序列化或loadClass反射类实例，此时他们的类加载器都是ModuleClassLoader。
这是一个很特殊的类加载器，反序列化利用链中常见的类，比如UnicastRef、CC链（程序中实际有用到这个依赖），甚至于原生反序列化链中的一些类都是无法加载的。
实测只有两个module路径下jar包里的部分类和jdk部分原生类可以被这个类加载器加载。在可以加载的类中能找到一些Sink类，比如ValueExpressionImpl、MethodExpressionImpl，在RichFaces的CVE-2018-12533中有用到这两个Sink类的反序列化链，但Source和Gadget类虽然有，但ModuleClassLoader类加载器并不能加载。
反序列化这条路行不通，回看调用栈中处理消息的方法processMessage。开头用反序列化获取appName、moduleName、distinctName和beanName，也就是客户端lookup查询的url。虽说这种用法存在风险，在不知道部署了什么EJB3服务的情况下，也可以进行反序列化，但目前看来有难度，所以暂时也没有什么问题。
接着看后面的代码，有一个反射Method的操作，从EJB3部署信息获取到的ComponentView，根据方法名和方法参数反射Method。回溯Method的来源，发现是与反序列化的locator有关。这个locator其实就是封装了客户端EJB3服务接口的EJBLocator，那可以客户端使用恶意的EJB3服务接口，从而反射服务端类的方法？笔者也做了下尝试，但若想要反射的服务端类不是一个接口类，则会抛出一个内接口类的异常，即使是没有抛出异常，从部署信息获取ComponentView这一步也没法获取服务端EJB3服务接口之外的内容。
Remoting3协议的分析原本是以挖掘协议漏洞为目的，但最终也没有发现什么太大的问题，不得不感叹现在JBoss\WildFly的版本比之前使用remoting2协议的版本安全性上升了一个台阶。翻看近年WildFly的CVE，有一个反序列化相关的CVE-2020-10740，没有验证机制使得可能通过EJB发起远程反序列化攻击，说的大概就是本文讨论的内容。查看在WildFly20.0发布的修复，仅仅是增加了黑名单验证。
除此之外，客户端还有个不大不小的问题，它的反序列化流程和服务端差不多，但客户端这里的类加载器就是普通的类加载器，可以用到部分的反序列化链，这场景就有点像RMI的反序列化服务端传来的恶意结果或异常。也许能用在反制、中间人攻击等场景。。
文中若有什么错误的地方，敬请师傅们斧正。