Daniel P. Berrangé <berra...@redhat.com> 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.
https://xkcd.com/2166/ > 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. Good idea. > 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 Is calling the implications "non-obvious" useful? One guy's "non-obvious" can be the next guy's "trivial"... > +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 "RPC" is unnecessary detail I find distracting (and not entirely fitting besides). Please scratch it. > +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. With "RPC" scratched: Reviewed-by: Markus Armbruster <arm...@redhat.com>
