Bug 1724809 (CVE-2019-12929)

Summary:	CVE-2019-12929 QEMU: guest agent guest_exec command execution
Product:	[Other] Security Response	Reporter:	Pedro Sampaio <psampaio>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	ailan, amit, areis, berrange, cfergeau, dbecker, drjones, dwmw2, eglynn, imammedo, itamar, jen, jferlan, jjoyce, jschluet, kbasil, knoel, lhh, lkundrak, lpeer, lsvaty, mburns, mgarciac, mkenneth, mrezanin, mst, pbonzini, pgrist, ppandit, rbalakri, ribarry, rjones, rkrcmar, sclewis, slinaber, virt-maint, virt-maint, vkuznets, xen-maint
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	QEMU's Machine Protocol (QMP) is designed to enable remote applications (ex. Libvirt) to control and manage QEMU process instances. QEMU Guest-Agent is a daemon program which helps remote applications (ex. Libvirt) to run commands on the guest VM, it supports QMP commands. It is meant to be used by trusted users and applications. The TCP server socket is only one of the transport options supported by QMP; other, more secure options, being local UNIX socket. If one is able to run QEMU Guest Agents' 'guest_exec' command, the user already has access to the guest VM. Then sending guest state to an unworthy remote machine via nc is not really a security issue. Libvirt only uses local UNIX sockets to interact with the guest VMs that it manages. This UNIX socket is owned by the same user-id as the QEMU process instance. Other users on the system cannot connect to the UNIX socket. Libvirt also creates a unique per-VM sVirt label so VMs cannot access each other's UNIX sockets, even though they are owned by the same system user-id.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-08 08:47:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1724810, 1724811
Bug Blocks:	1724845

Description Pedro Sampaio 2019-06-27 20:59:21 UTC

The QMP guest_exec command in QEMU 4.0.0 and earlier is prone to OS command injection, which allows the attacker to achieve code execution, denial of service, or information disclosure by sending a crafted QMP command to the listening server.

https://fakhrizulkifli.github.io/posts/2019/06/06/CVE-2019-12929/

Comment 1 Pedro Sampaio 2019-06-27 20:59:44 UTC

Created qemu tracking bugs for this issue:

Affects: epel-7 [bug 1724810]
Affects: fedora-all [bug 1724811]

Comment 5 Joshua Padman 2019-06-28 01:19:21 UTC

The purpose of the guest-exec command in QMP is to allow the passing of commands to the guest to be executed by the guest.  It is a documented part of the QMP interface between the host and the guest for the management of the guest. In the documentation [1] the functions description is "Execute a command in the guest". 

[1] https://qemu.weilnetz.de/doc/qemu-ga-ref.html

Comment 6 Joshua Padman 2019-06-28 01:19:27 UTC

Statement:

QEMU Machine Protocol (QMP) is for administrative control of QEMU instances. It must not be exposed to unprivileged users.

Comment 7 Prasad Pandit 2019-07-03 09:33:52 UTC

This is not a security issue in QEMU.

QEMU's Machine Protocol (QMP) is designed to enable remote applications (ex. Libvirt) to control and manage QEMU process instances. QEMU Guest Agent is a daemon program which helps remote applications (ex. Libvirt) to run commands on the guest VM, it supports QMP commands. It is meant to be used by trusted users and applications. The TCP server socket is only one of the transport options supported by QMP; other, more secure options, being local UNIX socket. If one is able to run QEMU Guest Agents' 'guest_exec' command, the user already has access to the guest VM. Then sending guest state to an unworthy remote machine via nc is not really a security issue.

Libvirt only uses local UNIX sockets to interact with the guest VMs that it manages. This UNIX socket is owned by the same user-id as the QEMU process instance. Other users on the system cannot connect to the UNIX socket. Libvirt also creates a unique per-VM sVirt label so VMs cannot access each other's UNIX sockets, even though they are owned by the same system user-id.