vxworks5.5里面rpcbind漏洞分析-2

白刃玄衣及

上周由于课程缘故原由，分析中断了，这个是上一篇，这周末继续
vxworks5.5里面rpcbind漏洞分析-1
脚本长达60个字节，也就是480位：




首先举行静态分析一波
当系统完成启动之后会举行如许子的查询方式，中心会有关中断的一些操作。
vxIdleAutoHalt函数是检查任务队列

当前检查有东西的时间，ln97x启动初始化

ln97xInt函数对缓冲寄存器检查，做进一步的检查。如果已经处于full的状态，那么就进入下一步正式接收的状态。

继续深入可以看见驱动里面开始在内存里面申请
在网络这一块，官方vxworks对于内存的管理叫做cluster【簇】，但是根据效果图看得出来，这个就是堆管理。
我们直接将其当做堆管理即可。


OK，这一层分析的差不多了。
知道了基本上是堆块管理的方式，那我们只需要在堆中找到我们需要的东西即可。
对于svc来说，是有svctcp_recv, svcraw_recv 和 svcudp_recv的。

当然，对于RPC来说自然就是UDP。

这里乍一看是可以看到有具体的一个函数，recvfrom是一个关键函数。

所以我们关键就是要找到第二个缓冲区的地点就行了。
关键就是找到第二个地址

也就是这个ecx，这个时间的ecx的值是0Xfee3024这个地址。当运行完recvfrom之后，这个地址就会有我们想要的东西。
随便在recvfrom之后随便下个结点，F9
然后就可以看到这个地方出现了。

这个就是整个payload的拷贝，从图中的信息可以判断出，不是栈溢出，不是堆溢出。
我们可以先从步伐的报错代码中找到我们需要的报错信息。
之前是已经分析好了步伐，基本上的问题都是出现在eax寄存器上，我们只需要对这个寄存器举行回溯操作，也就是在这个出现问题的步伐段上开头按下F2，。也就是下一个断点，如许步伐往下面走我们就可以看见我们想要的值，最先出现在什么地方。
根据这个地方，我们可以确定内存地址，进而推断出进一步的调用关系。

可以看得到，基本上内存里面一个堆块，存储了payload的一半以上的信息，但是对于后面的那一段payload具体在什么地方，我们现在还没有定论，所以，可以先按照这个地址展开来看。
图中的圆圈就是我们找到的对应的payload。
回去看看伪代码我么可以知道这个具体的函数就是一个传参的过程，也就是说，这个payload是从a2这个地方继承过来的。
首先，我们关注一下这个a2的地址和数据，同时a1这个地址也请注意一下，由于是从上面继承来的，0XFEF39B4

找到gcc2_compiled__312上一级函数svc_getreqset
当前出问题的这个函数是svc_getreqset

根据基层调用关系，我们可以得出如许的结论。
第一层出现问题的是gcc2_compiled312

调用gcc2_compiled312的是svc_getreqset

svc_getreqset上一层是svc_run

SVC是交换假造电路，信息包交换假造线路面向连接的网络中，从一台计算机到另一台计算机的连接。SVC是假造的，由于路径是从路由表中得到的，而不是建立物理线路。SVC是交换的，由于它能按需要建立，类似于一次电话呼叫。
从函数的调用关系可以看来，对于svc_runàsvc_getreqsetà gcc2_compiled__312是一个请求号，也就是说，系统是已经担当到了看似公道的请求，而造成这个的错误并不是一半的填充数据覆盖eip之类的，也就是说在从驱动拷贝到内存的过程当中，并没有出现一样平常的栈溢出或者堆溢出，不然会有其他的报错。
在分析的过程当中，我们经常可以看见一个命名就是taskIDcurrent这个值，从指针传递的值可以看到一直有一个值是0XFEF3B94，这个实在是portmap这个任务的栈基址

从“In addition, multithreaded RPC servers must call on svc_run(). Note that svc_getreqpoll() and svc_getreqset() are unsafe in MT applications.”
可以看出，对于svc_runàsvc_getreqsetà gcc2_compiled__312这里实在是一个不太安全的方法。
那么问题出现在哪里呢？


细数下来，我们的请求在复制的过程中并没有发生故障，相反的，反而在执行的时间出现了问题。清除了堆溢出、栈溢出和字符串格式化漏洞，那么还有一个极其隐晦的整数溢出漏洞。
岂论只要保持88888888前面的长度，后面的长度可以截断，这就可以判断出不是栈溢出或者堆溢出之类的，实测有效。
所以，总的下来，出现问题的函数就是在执行请求那边出现了问题，那么也还是回到最初的函数那边可以看到，gcc2_compiled__312。

当eax为88888888乘以四之后就会溢出。


整数溢出漏洞。
官方已经给出了几个方式去写exp

• 一个是整数溢出后导致RCE漏洞，执行危险命令
  
• 堆喷射放置shellcode
  
• 计算出可验证的？？值
  
• 直接跳到shellcode
  

综合来看，我可以尝试第四种，首先，我先控制call eax这个命令的eax值。
一样平常来说，填写负数将是一个不错的选择。

来源：http://www.12558.net
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！