Bug 1724812 (CVE-2019-12928)
| Summary: | CVE-2019-12928 QEMU: QMP migrate command execution issue | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Pedro Sampaio <psampaio> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| 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, 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. 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-08 08:48:15 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: | 1724813, 1724814 | ||
| Bug Blocks: | 1724845 | ||
|
Description
Pedro Sampaio
2019-06-27 21:01:26 UTC
Created qemu tracking bugs for this issue: Affects: epel-7 [bug 1724813] Affects: fedora-all [bug 1724814] 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 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. 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. |