VNC Virtual Network Computing is a good remote control tool software. Since the Qemu built-in vnc module, it can be a vnc client on the remote Qemu virtual machine for remote access.
3 6 0 security team members even a Han/LR in the reading of the Qemu-VNC source code in the process, found a function module in a remote denial of service.
The vulnerability risk level, the vulnerability number CVE-2 0 1 5-5 2 3 9 .
VNC uses the RFB communication Protocol. RFB(“remote frame buffer”)is a remote Graphical User a simple Protocol. Through this Protocol, the user can remotely simulate mouse clicks, keyboard keys and text copy/cut and other functions. This article described the vulnerability is in the text copy/cut when triggered. A detailed Protocol format the following figure:
Following this piece of data is true for sending text, copy/cut the packet:
0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 6 7 4 6 5 7 3 7 4 2 1 2 1 0 6: indicates the Protocol type message-type 0 0 0 0 0 0: used for filling padding 0 0 0 0 0 0 0 6: to be cut the length of the data length 7 4 6 5 7 3 7 4 2 1 2 1: to be cut the data content of the text
The Protocol format is relatively simple, will not be further described.
QEMU in Via vnc reads the packets stored in the clipboard data, since its not on the packets used to describe the data length of the field is strictly limited, thereby leading to the emergence of a logic error into the dead cycle. The following is the program the main processing logic:
Read the packets used to describe the data to be read length of field Determine this whether the field is over the entire packet length. If not, then copy the data; if it is, then out of the loop
Implementation code are as follows: (ui/vnc. c):
From the above code can be found: since the len of the initial value of 1, so protocol_client_msg()returns a value of 8. Input. the offset value is always 1 and 4 is greater than 8, so in this case wouldn't be out of the loop. Before entering the next cycle 8 will be used as protocol_client_msg()the parameter len is passed, for reading the packet length field value. However, if read at this time of the packet in the length field is 0xFFFFFFF9 then protocol_client_msg()the return value will be 1, The next cycle when the len of the value it has returned to an initial value of 1.
Thus, the program again proceeds to the start state, once again calling protocol_client_msg()and the return value is 8. Then again, the 8 incoming protocol_client_msg (), reads the packet length field 0xFFFFFFF9, the return value is 1, ad infinitum. Since in this period of the cycle in the process client connection flag vs->csock has not been changed, the program will not be out of the loop, thereby entering an infinite loop state. Vnc denial of service is also resulting.
An attacker exploiting the vulnerability can cause the virtual machine to a denial of service, and keep the cpu high occupancy rate, which in turn will affect the host machine and other virtual machines executed properly.
In our test environment for this vulnerability test the trigger before and after shots as follows. You can see that the vulnerability is triggered after the qemu-kvm can not remote access, and occupies extremely high CPU usage rate, seriously affecting the other programs running.
The vulnerability is triggered before the state of the CPU:
The vulnerability is triggered after the state of the CPU: the
The official has been on the vulnerability to fix, repair as follows:
Specifically, see: <http://git.qemu.org/?p=qemu.git;a=commit;h=f9a70e79391f6d7c2a912d785239ee8effc1922d>
The patch, the developers of key data dlen size of the strict size of the judgment, ensure that the value of the data length can not exceed 1MB. This is the perfect fix for this vulnerability. Proposed here all use qemu manufacturers use this patch, to prevent attackers using the CVE-2 0 1 5-5 2 3 9 vulnerability to manufacturers and users that the attack caused the loss.