Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface

[Philippe Mathieu-Daudé]

On 7/3/19 3:54 PM, 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"
> comand enabled arbitrary command execution for a remote attacker.
> 
> For this to be a flaw the user launching QEMU must have configured
> the monitor in a way that allows for other userrs 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 comamnds, however, this is not a flaw in QEMU.

comamnds -> commands

> 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.
> 
> 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.
> 
> Signed-off-by: Daniel P. Berrangé <address@hidden>
> ---
>  docs/security.texi | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/docs/security.texi b/docs/security.texi
> index 927764f1e6..5bff01449d 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
> +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

I'd have written "In summary, " or "In summary: " but I'm not sure this
is correct/better ;)

> +QEMU and as such should only be made accessible to a trusted management
> +application or user.
> 

Thanks for writing this down.

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>