Open Stack

On Wed, May 13, 2015 at 02:31:26PM +0000, Tim Bell wrote:
> 
> Looking through the details of the Venom vulnerability,
> https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it
> would appear that the QEMU processes need to be restarted.
> 
> Our understanding is thus that a soft reboot of the VM is not sufficient
> but a hard one would be OK.

Yes, the key requirement is that you get a new QEMU process running. So
this means a save-to-disk followed by restore, or a shutdown + boot,
or a live migration to another (patched) host.

In current Nova code a hard reboot operation will terminate the QEMU
process and then start it again, which is the same as shutdown + boot
really. A soft reboot will also terminate the QEMU process and start
it again, when when terminating it, it will try to do so gracefully.
ie init gets a chance todo a orderly shutdown of services. A soft
reboot though is not guaranteed to ever finish / happen, since it
relies on co-operating guest OS to respond to the ACPI signal. So
soft reboot is probably not a reliable way of guaranteeing you get
a new QEMU process.

My recommendation would be a live migration, or save to disk and restore
though, since those both minimise interruption to your guest OS workloads
where as a hard reboot or shutdown obviously kills them.


Also note that this kind of bug in QEMU device emulation is the poster
child example for the benefit of having sVirt (either SELinux or AppArmor
backends) enabled on your compute hosts. With sVirt, QEMU is restricted
to only access resources that have been explicitly assigned to it. This
makes it very difficult (likely/hopefully impossible[1]) for a compromised
QEMU to be used to break out to compromise the host as a whole, likewise
protect against compromising other QEMU processes on the same host. The
common Linux distros like RHEL, Fedora, Debian, Ubuntu, etc all have
sVirt feature available and enabled by default and OpenStack doesn't
do anything to prevent it from working. Hopefully no one is actively
disabling it themselves leaving themselves open to attack...

Finally QEMU processes don't run as root by default, they use a
'qemu' user account with minimal privileges, which adds another layer
of protection against total host compromise

So while this bug is no doubt serious and worth patching asap, IMHO,
it is not the "immediate end of the world" scale disaster that some
are promoting it to be.


NB, this mail is my personal analysis of the problem - please refer
to the above linked redhat.com blog post and/or CVE errata notes,
or contact Red Hat support team, for the official Red Hat view on
this.

Regards,
Daniel

[1] I'll never claim anything is 100% foolproof, but it is intended to
    to be impossible to escape sVirt, so any such viable escape routes
    would themselves be considered security bugs.
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|