+-- On Wed, 3 Jul 2019, Daniel P. Berrangé wrote --+
| A supposed exploit of QEMU was recently announced as CVE-2019-12928
| claiming that the monitor console was insecure because the "migrate"
| command enabled arbitrary command execution for a remote attacker.
|
| To be a security risk the user launching QEMU must have configured
| the monitor in a way that allows for other users to access it. The
| exploit report quoted use of the "tcp" character device backend for
| QMP.
|
| This would indeed allow any network user to connect to QEMU and
| execute arbitrary commands, however, this is not a flaw in QEMU.
| It is the normal expected behaviour of the monitor console and the
| commands it supports. Given a monitor connection, there are many
| ways to access host filesystem content besides the migrate command.
filesystem -> file system ?
| The reality is that the monitor console (whether QMP or HMP) is
| considered a privileged interface to QEMU and as such must only
| be made available to trusted users. IOW, making it available with
| no authentication over TCP is simply a, very serious, user
| configuration error not a security flaw in QEMU itself.
|
| The one thing this bogus security report highlights though is that
| we have not clearly documented the security implications around the
| use of the monitor. Add a few paragraphs of text to the security
| docs explaining why the monitor is a privileged interface and making
| a recommendation to only use the UNIX socket character device backend.
|
| Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
| Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
| ---
|
| Changed in v2:
|
| - Addressed misc typos (Eric / Philippe)
|
| docs/security.texi | 36 ++++++++++++++++++++++++++++++++++++
| 1 file changed, 36 insertions(+)
|
| diff --git a/docs/security.texi b/docs/security.texi
| index 927764f1e6..3f5d5e7adc 100644
| --- a/docs/security.texi
| +++ b/docs/security.texi
| @@ -129,3 +129,39 @@ those resources that were granted to it.
| system calls that are not needed by QEMU, thereby reducing the host kernel
| attack surface.
| @end itemize
| +
| +@section Sensitive configurations
| +
| +There are aspects of QEMU that can have non-obvious security implications
| +which users & management applications must be aware of.
| +
| +@subsection Monitor console (QMP and HMP)
| +
| +The monitor console (whether used with QMP or HMP) provides an RPC interface
| +to dynamically control many aspects of QEMU's runtime operation. Many of the
| +commands exposed will instruct QEMU to access content on the host
filesysystem
filesysystem -> file system ?
| +and/or trigger spawning of external processes.
| +
| +For example, the @code{migrate} command allows for the spawning of arbitrary
| +processes for the purpose of tunnelling the migration data stream. The
| +@code{blockdev-add} command instructs QEMU to open arbitrary files, exposing
| +their content to the guest as a virtual disk.
| +
| +Unless QEMU is otherwise confined using technologies such as SELinux,
AppArmor,
| +or Linux namespaces, the monitor console should be considered to have
privileges
| +equivalent to those of the user account QEMU is running under.
| +
| +It is further important to consider the security of the character device
backend
| +over which the monitor console is exposed. It needs to have protection
against
| +malicious third parties which might try to make unauthorized connections, or
| +perform man-in-the-middle attacks. Many of the character device backends do
not
| +satisfy this requirement and so must not be used for the monitor console.
| +
| +The general recommendation is that the monitor console should be exposed over
| +a UNIX domain socket backend to the local host only. Use of the TCP based
| +character device backend is inappropriate unless configured to use both TLS
| +encryption and authorization control policy on client connections.
| +
| +In summary, the monitor console is considered a privileged control interface
to
| +QEMU and as such should only be made accessible to a trusted management
| +application or user.
Excellent!
Reviewed-by: Prasad J Pandit <p...@fedoraproject.org>
-> https://nvd.nist.gov/vuln/detail/CVE-2019-12928
-> https://nvd.nist.gov/vuln/detail/CVE-2019-12929
Both these CVEs have since been updated to the 'DISPUTED' state. IIUC it's a
state before rejection.
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F
