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/
Created qemu tracking bugs for this issue: Affects: epel-7 [bug 1724810] Affects: fedora-all [bug 1724811]
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
Statement: QEMU Machine Protocol (QMP) is for administrative control of QEMU instances. It must not be exposed to unprivileged users.
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.