RMI源码调试

x33g5p2x  于2021-11-20 转载在 其他  
字(5.7k)|赞(0)|评价(0)|浏览(271)

看RMI漏洞时候,对其漏洞原理并不是很理解,所以简单调试了下源码加强下漏洞理解

由于要调试到RegistryImpl_Stub这种动态类,刚开始用的源码版本是JDK8u141,后来发现源码有些地方进行了修改,故此换回了JDK 7u80

以下是源码版本JDK 7u80的源码

创建注册中心

createRegistry

Registry registry = LocateRegistry.createRegistry(1099);

从上面这句代码入手,追溯下去,可以发现服务端创建了一个RegistryImpl对象。

LiveRef var2 = new LiveRef(id, var1);这里进行了一些数据的封装并赋值给var2

跟进下一行this.setup()

1.首先创建了个UnicastServerRef对象,把刚刚封装的var2传入了进去

2.跟进下一行setup,把创建UnicastServerRef的对象作为var1传入了setup()中

在setup()中调用了UnicastServerRef的exportObject()方法

跟进UnicastServerRef的exportObject()方法

第85行创建了RegistryImpl的代理对象RegistryImpl_stub,这个对象就是后面服务于客户端的RegistryImpl的Stub对象

第91行传入RegistryImpl,创建出RegistryImpl_Skel对象

继续回到前面,看94行,这里用skeleton、stub、UnicastServerRef对象、ObjID和一个boolean值等构造了一个Target对象,也就是这个Target对象基本上包含了全部的信息

在这上面都是没有进行网络操作,只是进行了一些对象的创建和变量的赋值操作。

接下来就是网络层的一些操作了

调用this.ref的exportObject方法,传入了Target对象,跟进LiveRef的exportObject

又调用了TCPEndpoint的exportObject方法,然后最终到达了TCPTransport的exportObject方法。以下是调用栈

TCPTransport的exportObject方法做的事情就是将上面构造的Target对象暴露出去。

此时的this是TCPTransport对象,跟进TCPTransport的listen()方法

调用TCPEndpoint#newServerSocket方法,会开启端口监听

接下来的第231行就是启动一条线程,等待客户端的请求

回到TCPTransport#exportObject,往下看

调用了父类Transport的exportObject()将Target对象存放进ObjectTable中

注册中心处理请求

接上,在TCPTransport#listen中

跟进AcceptLoop()到executeAcceptLoop

这里就是获取了请求中的一些信息,在371行创建一个线程,调用内部类ConnectionHandler来处理请求

进入ConnectionHandler,此内部类就是用来处理请求的

接收请求,在run()中获取的ServerSocket对象

跟进上图中的run0()后,handleMessages来处理请求

进入handleMessages(),在之前获取一些客户端传过来的数据。然后转到case 80

先是创建了一个StreamRemoteCall对象,并传入var1,var1是当前连接的Connection对象

紧接着跟入下一行TCPTransport#serviceCall

这里获取了OBJID,后面会获取到Target对象

最后在下面调用了UnicastServerRef#dispatch来处理请求

接着跟dispatch:

这里传递的两个参数,一个是Target对象,一个是当前连接的StreamRemoteCall对象,

接着调用到了oldDispatch

跟进oldDispatch,在最后调用到了this.skel.dispatch

可以看到this.skel就是之前创建的RegistryImpl_Skel对象,也就是说UnicastServerRef#dispatch最后会调用到RegistryImpl_Skel#dispatch来处理请求

接着跟RegistryImpl_Skel#dispatch方法:

var3是一个int类型的数组,分别对应了

  • 0->bind
  • 1->list
  • 2->lookup
  • 3->rebind
  • 4->unbind

然后会进入case对方法进行处理,可以看到case 0对应的是bind,有执行readObject,而最后var6.bind中的var6是RegistryImpl对象,由createRegistry获得

比如调用了bind,则会进入RegistryImpl_Skel#dispatch中,先反序列化readObject传过来的序列化对象,之后进行var6.bind来注册服务,而var6则是RegistryImpl对象。也就是说无论是客户端还是服务端,最终其调用注册中心的方法都是通过创建的RegistryImpl对象进行调用的。

获取注册中心

getRegistry

在前面createRegistry获得的是RegistryImpl对象,而getRegistry获得的是RegistryImpl_Stub对象

Registry registry = LocateRegistry.getRegistry("192.168.202.1",1099);

直接查看getRegistry源码最后返回的是一个RegistryImpl_Stub对象

调用bind绑定到注册中心

在两种方式获取的RegistryImpl和RegistryImpl_Stub对象中,其bind方法有什么区别呢

RegistryImpl#bind

在第一步会checkAccess,里边有一些判断,会对你当前的权限、来源IP进行判断。

之后判断这个键是否已经被绑定过,如果已经被绑定过,则抛出一个AlreadyBoundException的错误,否则将键和对象都put到Hashtable中。

这里的bindings是一个Hashtable,以键-值的方式存储了服务端注册的服务。

RegistryImpl_Stub#bind

进入RegistryImpl_Stub#bind,这里的var3,前面说过,bind方法对于的数字为0,此时的var3就代表了bind方法对应的数字

调用UnicastRef#newCall,将RegistryImpl_Stub对象传了进去,RegistryImpl_Stub存了一些服务器相关的信息。

简单来看newCall就是与远程RegistryImpl的Skeleton对象的连接

new newConnection用来创建一个TCPConnection对象,里面写了一些ip、端口

new StreamRemoteCall创建了一个StreamRemoteCall对象,把var6,LiveRef,ObjID,调用bind方法的值var3和4905912898345647071传入了StreamRemoteCall对象

以上两个都是进行数据的封装

调用完后,回到RegistryImpl_Stub#bind(因为这里RegistryImpl_Stub是动态类,故用了jdk8u141的源码调试的截图)

序列化两个内容

  • 序列化后的var1,var1为我们要绑定远程对象对应的名称
  • 序列化后的var2,var2为我们要绑定的远程对象

最后调用invoke方法把请求发出去,注册中心就会接收到请求调用RegistryImpl_Skel#dispatch进行处理。

以下是注册中心的RegistryImpl_Skel#dispatch处理请求

注册中心首先会反序列化readObject两个对象,第一个和第二个对应上面两个writeObject写入的对象,绑定远程对象对应的名称和要绑定的远程对象

接着调用var6.bind来绑定服务,var6即RegistryImpl对象,调用到RegistryImpl#bind把键和对象都put到Hashtable中。

创建远程对象

其实创建远程对象的时候,和创建注册中心是类似。生成其存根stub和skel,并且会绑定随机一个端口发布

在这里下个断点

HelloImpl继承了UnicastRemoteObject

跟进super方法,传入port为0

这里调用了exportObject,并且传入了HelloImpl对象

跟进exportObject

new UnicastServerRef()就是封装了一些host,ObjID等

经过了几次exportObject调用后,到了UnicastServerRef#exportObject

Util.createProxy创建了一个远程对象的代理对象proxy。这点和之前注册中心的并不同,注册中心创建的是RegistryImpl_Stub

跟进Util.createProxy看到,后面返回了动态代理对象,而其invocationHandler值为RemoteObjectInvocationHandler(远程调用该对象时,客户端获取到的其实是该代理对象)

回到UnicastServerRef#exportObject,看到var5的值最终是一个动态代理类

继续往下看,if判断是否为RemoteStub类,显然RemoteObjectInvocationHandler不属于RemoteStub,返回false,不执行if里面的语句

下面构造了一个Target对象,然后调用this.ref的exportObject方法,传入了Target对象

下面就是网络层的操作了

跟进exportObject,最终调用 TCPTransport#exportObject 方法

跟进listen()

调用newServerSocket开启一个随机端口监听,这里开启的是11061

回到TCPTransport#exportObject。

最终服务暴露(exportObject)时做了两件事,一是如果 socket 没有启动,启动 socket 监听;二是将 Target 实例注册到 ObjectTable 对象中。

通信调用

接下来讲客户端与服务器之间通信是怎么进行的

客户端与服务端的通信

客户端代码:

//获取远程主机对象
        Registry registry = LocateRegistry.getRegistry("127.0.0.1",1099);
        //查找注册中心得hello对象
        Hello hello = (Hello)registry.lookup("hello");
        //调用方法
        System.out.println(hello.hello("yangyang"));

客户端与服务端的通信发生在调用远程方法时

hello.hello(); //调用方法

前面两行,拿到的hello对象是proxy代理对象,且该代理对象的handler为RemoteObjectInvocationHandler

此时是远程代理对象RemoteObjectInvocationHandler与服务器的Skel进行通信

在Proxy调用方法时候,会进入对应的InvocationHandler的invoke方法中,也就是RemoteObjectInvocationHandler的invoke方法

在这个做了个if判断为false,跳转到else中

跟进invokeRemoteMethod

这里调用了this.ref.invoke,而this.ref则是UnicastRef对象

跟进UnicastRef#invoke

和前面一样newConnection用来创建一个TCPConnection对象,里面写了一些ip、端口

new StreamRemoteCall创建了一个StreamRemoteCall对象,把TCPConnection对象,ObjID,-5976794856777945295传入了StreamRemoteCall对象

然后往下看,for循环条件满足(前提是传递的参数是一个对象)跟入下面的marshalValue

这个方法是把调用方法的参数进行了序列化

回到UnicastRef#invoke,下面调用了executeCall()方法

跟进StreamRemoteCall#executeCall方法,这个方法就是用来发送给服务端数据的了

继续跟进releaseOutputStream方法,this.out.flush就是把数据发送给服务端

发送完数据后,回到UnicastRef#invoke,下面的unmarshalValue

unmarshalValue则是接受服务端发过来的数据进行readObject读取,然后赋值给var13返回。

到这里整个客户端与服务端通信流程就走完了,下面来看下服务端和客户端的通信

服务端和客户端的通信

和注册中心一样,服务端的接收到请求后,最后会进入UnicastServerRef#dispatch进行处理

这里有两次处理请求:

第一次是在lookup的时候

当执行lookup的时候,会进入UnicastServerRef#dispatch中,到124行进入oldDispatch

跟进oldDispatch,看到调用了DGCImpl_Skel的dispatch处理

第二次是发生在UnicastServerRef#dispatch中的第151行进行处理

当传入的参数类型是一个Object的时候,这里也会进行unmarshalValue

unmarshalValue中进行了readObject,此处就是服务端反序列化触发的一个点

相关文章