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

我的苦恼冉

漏洞触发脚本：
import socketimport sysPAYLOAD_HEX = 'cc6ff7e200000000000000020001a086000000040000000488888888000000110000001100001111111111111111111111111111'def poc(host, rpcPort=111):  sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)  sock.sendto(PAYLOAD_HEX.decode('hex'), (host, rpcPort))if __name__ == '__main__':  poc(sys.argv[1])瓦解场景：

Vxworks的服务由netTask函数总统领：

这里还有一个惊喜之处就是找到了栈溢出的字符串。在这个函数下面使用了很多函数指针来举行传参，这对分析造成了困难，同时由于这个特性，也没办法利用IDA的流程图重建功能来举行分析，以是打算对比一下不同端口、不同服务的函数流程的差别：
经太过析后发现只要是UPD服务，走的都是这一条路线：

查询了网络上相关资料知道在Vxworks中在硬件接口和传输层之间增加了一个叫做mux层的东西，其作用是屏蔽复杂的硬件环境。以是在Vxworks中，muxRecieve这个函数很紧张，另外在这个函数中调用了一个函数指针：

因为我们都知道在vxworks当中是没有历程的概念，天然也没有线程的概念，其内存管理也是实模式下举行的，为了保证效率，他们只有任务的概念，其实就是函数的调用，一个函数就是一个任务，因此是有一个循环会不绝的检查信息的变化，然后查询到相关的函数举行调用。

可以看到，瓦解的tPortmapd函数PC是运行到0x3ad3bc。
这时间我们有两个思路，对于这个指令的地址，
l 是因为栈溢出而填充的覆盖到的
l 是因为在操纵栈的时间，粉碎了其他函数任务的栈结构
首先我们可以很快的确定的是，肯定不是第一种，第一，我们的脚本的payload当中，“cc6ff7e200000000000000020001a086000000040000000488888888000000110000001100001111111111111111111111111111”显着没有这三个字节的存在，通过网络装包也可知道。

不大概，因为0x3ad3bc跟其他没有报错的函数的PC值相近，肯定也是合理的代码段间的。因此第一种方式不可行。
同时我们也要开始排查另外一种大概就是，对于0x3ad3bc这个函数的地址不是从其他地方直接jmp已往的，而是从一个特别的函数开始启动。
因此，我们定位到这个地址。

然后在这个地址所在的proc段开头设一个断点

看一下伪代码，可以看到是在传递参数的过程中栈结构出题目了。

Continue……
然后触发脚本。
发现断点已经停留在这个程序段，那我们就F8跟进同时查看栈结构的变化。

这时间的栈结构是

根据上下文，我们推测比力就是在eax寄存器上面出现了题目，eax从数据段那里取数据，从一些细节，我猜测这一段的代码紧张是举行中断向量表的更换，



这当然也只是一个猜测，具体得团结官方文档的layout表示图，来考量。
再次将断点放到

当断点确定到再次断到事发前一句，检查寄存器的值，发现了异常

对于即将实行“mov eax, ds:svcauthsw[eax*4]”这样的指令，eax等于那个奇怪的值肯定不是合理的，这时间我猜测到这里来自payload此中一段，果不其然，找到了八个八，于是我我修改了一下，改成八个9。看看是否会跟着变化。

发现了到这一步已经可以劫持eax寄存器了，以是我们假如通过合理的跳转，是可以举行任意代码实行的。
可以覆盖的段我们已经找到了，现在就是尝试分析程序走向，得到更高的权限。

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