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é <berra...@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é <phi...@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 :|