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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).