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

[Daniel P . Berrangé]

On Wed, Jul 03, 2019 at 10:56:05PM +0100, Alex Bennée wrote:
> 
> 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 challenge with issuing warnings is ensuring that we don't give
false positives, and that's pretty much impossible IMHO.

Even use of plain non-localhost TCP chardevs can be valid in some
circumstances. For example it would not be surprising to see it
used if QEMU was inside a Kubernetes container, as two containers
can communicate with each other over IP & rely on Kubernetes
networking layer to provide security

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 :|