0x00背景
安全娱乐圈媒体Freebuf对该漏洞的有关报道:
提供的POC没有触发崩溃,在MJ0011的博客给出了修改后可以使qemu崩溃的poc。详见:
0x01漏洞重现
注:qemu的用户交互性体验相对于vmware来说,极差
a.Linux 的qemu虚拟机
环境:
Win 10 物理机 + qemu-system-i386.exe (2.0.50) + CentOS 6.3虚拟机
Linux 因为在用户层就可以直接操作端口,所以在linux虚拟机中将MJ给的POC保存成一个C文件,用gcc编译后运行,就可以看到qemu崩溃了:
b.Windows的qemu虚拟机
环境:
Win 10 物理机 + Qemu Manager 7.0 + WinXP虚拟机
Windows因为不可以在用户层直接和端口操作,需要借助驱动,所以就存在了和物理机的交互:驱动加载工具和编译好的驱动程序。
测试的过程中,使用了Qemu Manager 7.0来建立共享文件夹。在物理机设置一个共享文件夹,然后就可在windows虚拟机的网上邻居访问了:
编写的驱动关键代码,换成对应对端口操作的函数就好了:
物理机中用windbg附加到qemu进程后,在xp虚拟机中加载驱动后,就可以观察到windbg捕获到异常了:
注:如果不用windbg附加到qemu.exe进程的话,那么看到的是qemu mannager把虚拟机给关了。
0x02分析
MJ的文章对漏洞成因进行了较为详细的分析了,具体的情况可以查看其blog。下面进行简要的说明:
qemu接受到FIFO命令后,会先调用fdctrl_write_data 函数,该函数会确保fdctrl的状态是可写入的,才会进行下一步操作。
outb(0x8e,0x3f5)对应的函数为fdctrl_handle_drive_specification_command:
因为 fdctrl->fifo[fdctrl->data_pos - 1] 是我们可控的,加上fdctrl ->data_len =6,不可能大于7,所以可以绕过这两个对fdctrl写入状态的改写,其状态还是可以被写入的。
而接受写入数据buffer fdctrl->fifo的大小为0x1000 bytes,poc中对其进行不断的写入,也就发生了越界写了。
by:会飞的猫
转载请注明:http://www.cnblogs.com/flycat-2016