From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, P J P <ppandit@redhat.com>,
qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface
Date: Wed, 3 Jul 2019 15:30:01 +0100 [thread overview]
Message-ID: <20190703143001.GE23082@redhat.com> (raw)
In-Reply-To: <43fe3646-1ee5-238e-3f0b-dc0b2e976b6e@redhat.com>
On Wed, Jul 03, 2019 at 04:24:26PM +0200, Philippe Mathieu-Daudé wrote:
> 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é <berrange@redhat.com>
> > ---
> > 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 ;)
Using a comma is a reasonable thing here.
>
> > +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é <philmd@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-07-03 14:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 13:54 [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface Daniel P. Berrangé
2019-07-03 14:24 ` Philippe Mathieu-Daudé
2019-07-03 14:30 ` Daniel P. Berrangé [this message]
2019-07-03 14:41 ` Eric Blake
2019-07-03 16:37 ` no-reply
2019-07-03 21:56 ` Alex Bennée
2019-07-04 8:50 ` Daniel P. Berrangé
2019-07-04 9:16 ` Alex Bennée
2019-07-04 9:19 ` Daniel P. Berrangé
2019-07-04 9:24 ` Alex Bennée
2019-07-04 1:33 ` no-reply
2019-07-05 7:03 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190703143001.GE23082@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=philmd@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.