Bug 1724812 (CVE-2019-12928) - CVE-2019-12928 QEMU: QMP migrate command execution issue
Summary: CVE-2019-12928 QEMU: QMP migrate command execution issue
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2019-12928
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1724813 1724814
Blocks: 1724845
TreeView+ depends on / blocked
 
Reported: 2019-06-27 21:01 UTC by Pedro Sampaio
Modified: 2021-02-16 21:47 UTC (History)
34 users (show)

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. 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 'migrate' command, the user already has access to the guest VM. Then migrating 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.
Clone Of:
Environment:
Last Closed: 2019-07-08 08:48:15 UTC
Embargoed:

Attachments (Terms of Use)

Description Pedro Sampaio 2019-06-27 21:01:26 UTC 
The QMP migrate command in QEMU version 4.0.0 and earlier is vulnerable to OS command injection, which allows the remote 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/05/CVE-2019-12928/
Comment 1 Pedro Sampaio 2019-06-27 21:01:48 UTC 
Created qemu tracking bugs for this issue:

Affects: epel-7 [bug 1724813]
Affects: fedora-all [bug 1724814]
Comment 2 Joshua Padman 2019-06-28 01:19:05 UTC 
The migrate command in QMP is provides a way to migrate a current running guest to another virtual machine [1]. This functionality is built on top of QEMU migration functionality. Both of these support the use of 'exec:' within the command. Examples are provided utilizing this functionality to encrypt data before sending over the network [2]. This is expected and documented behavior.

[1] https://qemu.weilnetz.de/doc/qemu-qmp-ref.html
[2] https://www.linux-kvm.org/page/Migration
Comment 3 Joshua Padman 2019-06-28 01:19:09 UTC 
Statement:

QEMU Machine Protocol (QMP) is for administrative control of QEMU instances. It must not be exposed to unprivileged users.
Comment 4 Prasad Pandit 2019-07-03 09:36:02 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. It is meant to be used by trusted users and/or applications. TCP server socket is only one of the transport options supported by QMP, other more secure being local UNIX socket. If one is able to run 'migrate' command, he/she already has access to the guest VM. Then migrating guest state to an unworthy remote machine via nc(1) 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. So that other users on the system cannot connect to the UNIX socket. Libvirt also creates a unique per-VM sVirt label, so that VMs cannot access each other's UNIX sockets, even though they are owned by the same system user-id.
Note You need to log in before you can comment on or make changes to this bug.