VNC(Virtual Network Computing)是一款优秀的远程控制工具软件。由于Qemu内置vnc功能模块,所以可通过vnc客户端对远程Qemu虚拟机进行远程访问。
360安全团队成员连一汉/LR在阅读Qemu-VNC源码过程中,发现了功能模块中的一个远程拒绝服务。
该漏洞危险等级为中,漏洞编号 CVE-2015-5239 。
VNC采用RFB通信协议。RFB(“remote 帧缓存”)是一个远程图形用户的简单协议。通过这个协议,用户可以远程模拟鼠标点击、键盘按键以及文本复制/剪切等功能。本文所讲述漏洞就是在文本复制/剪切时触发的。详细协议格式如下图:
下面这段数据是真实发送的用于文本复制/剪切的报文:
06 00 00 00 00 00 00 06 74 65 73 74 21 21 06 :表示协议类型message-type 00 00 00 :用于填充padding 00 00 00 06 :待剪切数据的长度length 74 65 73 74 21 21:待剪切数据内容text
协议格式相对简单,就不再进一步描述。
QEMU在通过vnc读取报文中存储的剪切板中的数据时,由于其未对报文中用于描述数据长度的字段进行严格限制,进而导致其出现逻辑错误进入死循环。下面就是程序处理的主体逻辑:
读取报文中用于描述待读取数据长度的字段 判断这个字段是否超过整个报文的长度。 如果为否,则进行数据复制;如果为是,则跳出循环
实现代码如下(ui/vnc.c):
从上述代码中可以发现:由于len的初始值为1,所以protocol_client_msg()的返回值为8。Input.offset的值始终为14大于8,所以此时不会跳出循环。在进入下次循环时8将作为protocol_client_msg()的参数len传入,用于读取报文长度字段的值。但是,如果此时读取的报文中的长度字段为0xFFFFFFF9则protocol_client_msg()的返回值又将为1,下次循环时len的值也就又恢复为初始值1。
这样,程序又进入开始时的状态,再次调用protocol_client_msg()并且返回值为8。然后又将8传入protocol_client_msg(),读取报文中的长度字段0xFFFFFFF9,返回值又为1,循环往复。由于在这段循环过程中客户端连接标志vs->csock始终未被更改,程序也将无法跳出循环,从而进入死循环状态。Vnc拒绝服务也就由此产生。
攻击者利用该漏洞可以导致虚拟机拒绝服务,并且保持对cpu的高占用率,继而会影响宿主机以及其他虚拟机的正常执行。
我们在测试环境中对该漏洞进行测试,触发前后的截图如下。可以看到,在漏洞触发后qemu-kvm无法远程访问,并占有极高的CPU使用率,严重影响其它程序的运行。
漏洞触发前CPU的状态:
漏洞触发后CPU的状态:
官方已经对该漏洞进行修复,修补如下:
具体见: http://git.qemu.org/?p=qemu.git;a=commit;h=f9a70e79391f6d7c2a912d785239ee8effc1922d
该补丁中,开发人员对关键数据dlen的大小进行严格的大小判断,确保数据长度值不能超过1MB。这样就完美修复此漏洞。在这里建议所有使用qemu的厂商采用该补丁,防止攻击者利用CVE-2015-5239漏洞对厂商和用户攻击造成损失。