[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a pri
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface |
Date: |
Wed, 03 Jul 2019 22:56:05 +0100 |
User-agent: |
mu4e 1.3.2; emacs 26.1 |
Daniel P. Berrangé <address@hidden> writes:
> 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.
> 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.
Is this the sort of thing we should emit warnings for? I guess this is a
philosophical question as QEMU tends to err towards being taciturn on
the command line unless something is actually wrong (and not just
stupid).
I wouldn't expect a warning for -serial mon:stdio but maybe a
non-localhost tcp chardev for o+rw socket might be worth a mention? Of
course this sort of sanitising of the command line options does incur
cost and complexity in our option processing.
>
> 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.
However extra clarity is always welcome, modulo typos and grammar
suggestions the others have made:
Reviewed-by: Alex Bennée <address@hidden>
>
> 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
> +QEMU and as such should only be made accessible to a trusted management
> +application or user.
--
Alex Bennée
Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface, no-reply, 2019/07/03
Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface, Markus Armbruster, 2019/07/05