Last updated 24 July 2024
A buffer overflow flaw was found in the way e1000 emulated device driver of QEMU, a FAST! processor emulator, processed received large e1000 packets, when the SBP and LPE flags were disabled. If the underlying network was configured to allow large (jumbo) packets, a remote attacker could use this flaw to cause relevant guest in question to crash (DoS) or, potentially, the attacker could use this flaw to execute arbitrary code on the guest system with the kernel level privilege.
References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696051 [2] http://www.openwall.com/lists/oss-security/2012/12/19/9 [3] http://thread.gmane.org/gmane.comp.emulators.qemu/182666 [4] http://www.openwall.com/lists/oss-security/2013/01/17/12
Relevant upstream patches: [5] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=b0d9ffcd0251161c7c92f94804dcf599dfa3edeb http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2c0331f4f7d241995452b99afaf0aab00493334a
Both virtio-block and virtio-serial read, VirtQueueElements are read in as buffers, and passed to virtqueuemapsg(), where numsg is taken from the wire and can force writes to indicies beyond VIRTQUEUEMAXSIZE.
An user able to alter the savevm data (either on the disk or over the wire during migration) could use this flaw to to corrupt QEMU process memory on the (destination) host, which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process.
Upstream fix: ------------- -> http://git.qemu.org/?p=qemu.git;a=commit;h=36cf2a37132c7f01fa9adb5f95f5312b27742fd4
It was found that fix for CVE-2013-0167 was not complete. A privileged guest user could still potentially make the host the guest is running on unavailable to the management server by making guest agent return data with invalid XML characters.
Upstream fix: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=5fe1615b7949999fc9abd896bde63bf24f8431d6
Acknowledgements:
This issue was found by David Gibson of Red Hat.
A cross-site scripting (XSS) flaw was found in the RedirectServlet of the oVirt Engine and Red Hat Enterprise Virtualization Manager (RHEV-M). A remote attacker could provide a specially-crafted link, that when visited by an unsuspecting RHEV-M / oVirt user would lead to arbitrary script execution in the context of the RHEV-M / oVirt domain. Access to the RedirectServlet does not require authentication.
Stack-based buffer overflow in the redshandleticket function in server/reds.c in SPICE 0.12.0 allows remote attackers to cause a denial of service (crash) via a long password in a SPICE ticket.
Buffer overflow in the SCSI implementation in QEMU, as used in Xen, when a SCSI controller has more than 256 attached devices, allows local users to gain privileges via a small transfer buffer in a REPORT LUNS command.
Insecure temporary file vulnerability in RedHat vsdm 4.9.6.
Unquoted Windows search path vulnerability in Red Hat Enterprise Virtualization (RHEV) 3 and 3.2 allows local users to gain privileges via a crafted application in an unspecified folder.
A flaw was found in the way processing of unexpected fields in guestInfo dictionary were handled. A privileged guest user can potentially make the host the VM runs on unavailable to the managment server.
Acknowledgements:
This issue was discovered by Dan Kenigsberg of the Red Hat Enterprise Virtualization team.
vdsm and vdsclient does not validate certficate hostname from another vdsm which could facilitate a man-in-the-middle attack
Dan Kenigsberg of Red Hat reports:
Description of problem: In numerous places, ovirt-node puts an input string on a command line, without safely quoting it. With this, whoever controls the input string may gain complete control on the host.
For example, http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=blob;f=src/ovirtnode/ovirtfunctions.py;h=caef7ef019ca12b49aa3c030792538956fb4caad;hb=e11e02cd9256c854dd0419515097637d6829b4f1#l1091
"ls '%s'" % filename
is not going to end up well if the filename is actually "bla\'; rm -fr /; echo \'". pipes.quote() or its like must be used in such occasions.
It may be safer to disallow shell=True completely (but would require to avoid in-shell pipes).
Version-Release number of selected component (if applicable): ovirt-node-3.0.0-474-gb852fd7
During migration, the values read from migration stream during ram load are not validated. Especially offset in hostfromstreamoffset() and also the length of the writes in the callers of the said function.
A user able to alter the savevm data (either on the disk or over the wire during migration) could use either of these flaws to corrupt QEMU process memory on the (destination) host, which could potentially result in arbitrary code execution on the host with the privileges of the QEMU process.
Acknowledgements:
This issue was discovered by Michael S. Tsirkin of Red Hat.
bitsperpixel that are less than 8 could result in accessing non-initialized buffers later in the code due to the expectation that bytesperpixel value that is used to initialize these buffers is never zero.
An attacker having access to the guest's VNC console could use this flaw to crash the guest.
Acknowledgements:
Red Hat would like to thank James Spadaro of Cisco for reporting this issue.
libvirt 1.0.0 through 1.2.x before 1.2.5, when fine grained access control is enabled, allows local users to read arbitrary files via a crafted XML document containing an XML external entity declaration in conjunction with an entity reference to the (1) virDomainDefineXML, (2) virNetworkCreateXML, (3) virNetworkDefineXML, (4) virStoragePoolCreateXML, (5) virStoragePoolDefineXML, (6) virStorageVolCreateXML, (7) virDomainCreateXML, (8) virNodeDeviceCreateXML, (9) virInterfaceDefineXML, (10) virStorageVolCreateXMLFrom, (11) virConnectDomainXMLFromNative, (12) virConnectDomainXMLToNative, (13) virSecretDefineXML, (14) virNWFilterDefineXML, (15) virDomainSnapshotCreateXML, (16) virDomainSaveImageDefineXML, (17) virDomainCreateXMLWithFiles, (18) virConnectCompareCPU, or (19) virConnectBaselineCPU API method, related to an XML External Entity (XXE) issue. NOTE: this issue was SPLIT from CVE-2014-0179 per ADT3 due to different affected versions of some vectors.
An information leakage flaw was found in Qemu's VGA emulator. It could lead to leaking host memory bytes to a VNC client. It could occur when a guest GOP driver attempts to set a high display resolution.
A privileged user/program able to set such high resolution could use this flaw to leak host memory bytes.
Upstream fixes: --------------- -> http://git.qemu.org/?p=qemu.git;a=commit;h=c1b886c45dc70f247300f549dce9833f3fa2def5 -> http://git.qemu.org/?p=qemu.git;a=commit;h=ab9509cceabef28071e41bdfa073083859c949a7
libvirt 0.7.5 through 1.2.x before 1.2.5 allows local users to cause a denial of service (read block and hang) via a crafted XML document containing an XML external entity declaration in conjunction with an entity reference to the (1) virConnectCompareCPU or (2) virConnectBaselineCPU API method, related to an XML External Entity (XXE) issue. NOTE: this issue was SPLIT per ADT3 due to different affected versions of some vectors. CVE-2014-5177 is used for other API methods.
QEMU before 2.0.0 block drivers for CLOOP, QCOW2 version 2 and various other image formats are vulnerable to potential memory corruptions, integer/buffer overflows or crash caused by missing input validations which could allow a remote user to execute arbitrary code on the host with the privileges of the QEMU process.
Qemu before 1.6.2 block diver for the various disk image formats used by Bochs and for the QCOW version 2 format, are vulnerable to a possible crash caused by signed data types or a logic error while creating QCOW2 snapshots, which leads to incorrectly calling updaterefcount() routine.
Qemu before 2.0 block driver for Hyper-V VHDX Images is vulnerable to infinite loops and other potential issues when calculating BAT entries, due to missing bounds checks for blocksize and logicalsectorsize variables. These are used to derive other fields like 'sectorsperblock' etc. A user able to alter the Qemu disk image could ise this flaw to crash the Qemu instance resulting in DoS.
Buffer overflow in the pcnetreceive function in hw/net/pcnet.c in QEMU, when a guest NIC has a larger MTU, allows remote attackers to cause a denial of service (guest OS crash) or execute arbitrary code via a large packet.
The C+ mode offload emulation in the RTL8139 network card device model in QEMU, as used in Xen 4.5.x and earlier, allows remote attackers to read process heap memory via unspecified vectors.
It was reported that the libvirt daemon using RBD leaks ceph key/id in the process list:
As a non-privileged user you can run ps -ef | grep libvirt and see the below output. In this you can see libvirt using the ceph key as part of the command to run the VM. In particular this section
~~~ -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:authsupported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback ~~~
With the 'id' and 'key' values, any user can perform any operations on the cluster which that key provides. Typically, that would be the ability to create/delete RBDs within the cinder pool.
Full output: ~~~ qemu 13924 1 33 Dec10 ? 2-23:31:12 /usr/libexec/qemu-kvm -S -M rhel6.1.0 -enable-kvm -m 8000 -smp 8,sockets=8,cores=1,threads=1 -name os-network -uuid f0ede7e8-c15a-4813-900e-971988d494c1 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/os-network.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:authsupported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:64:92:b6,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:f7:50:e2,bus=pci.0,addr=0x4 -netdev tap,fd=30,id=hostnet2,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=52:54:00:14:3b:33,bus=pci.0,addr=0x5 -netdev tap,fd=32,id=hostnet3,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=52:54:00:fd:86:aa,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:5 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x8 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 ~~~
The Floppy Disk Controller (FDC) in QEMU, as used in Xen 4.5.x and earlier and KVM, allows local guest users to cause a denial of service (out-of-bounds write and guest crash) or possibly execute arbitrary code via the (1) FDCMDREADID, (2) FDCMDDRIVESPECIFICATIONCOMMAND, or other unspecified commands, aka VENOM.
Heap-based buffer overflow in the PCNET controller in QEMU allows remote attackers to execute arbitrary code by sending a packet with TXSTATUSSTARTPACKET set and then a crafted packet with TXSTATUSDEVICEOWNS set.
Due converting PIO to the new memory read/write api we no longer provide separate I/O region lenghts for read and write operations. As a result, reading from PIT Mode/Command register will end with accessing pit->channels with invalid index and potentially cause memory corruption and/or minor information leak.
A privileged guest user in a guest with QEMU PIT emulation enabled could potentially (tough unlikely) use this flaw to execute arbitrary code on the host with the privileges of the hosting QEMU process. (QEMU part of the vulnerability)
A privileged guest user in a guest could potentially (tough unlikely) use this flaw to execute arbitrary code on the host. (KVM part of the vulnerability)
Acknowledgements:
Red Hat would like to thank Matt Tait of Google's Project Zero security team for reporting this issue.
It was found that a malicious guest user could submit more requests than the virtqueue size permits, resulting in a crash of the host QEMU process.
The guest could submit requests without bothering to wait for completion and is therefore not bound by virtqueue size. This requires reusing vring descriptors in more than one request, which is incorrect but possible. Processing a request allocates a VirtQueueElement and therefore causes unbounded memory allocation controlled by the guest.
Exit with an error if the guest provides more requests than the virtqueue size permits. This bounds memory allocation and makes the buggy guest visible to the user.
Upstream patch -------------- -> git.qemu.org/?p=qemu.git;a=commit;h=afd9096eb1882f23929f5b5c177898ed231bac66
Heap-based buffer overflow in the iscsiaioioctl function in block/iscsi.c in QEMU allows local guest OS users to cause a denial of service (QEMU process crash) or possibly execute arbitrary code via a crafted iSCSI asynchronous I/O ioctl call.
Qemu emulator built with VGA emulation with VESA BIOS Extensions(VBE) support is vulnerable to an OOB r/w access issue. It could occur while doing VGA r/w operations via i/o port methods.
A privileged guest user could use this flaw to potentially execute arbitrary code, with privileges of the Qemu process on the host.
Upstream patch: --------------- -> https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg01197.html
Reference: ---------- -> http://www.openwall.com/lists/oss-security/2016/05/09/3
The netchecksumcalculate function in net/checksum.c in QEMU allows local guest OS users to cause a denial of service (out-of-bounds heap read and crash) via the payload length in a crafted packet.