

QEMU heap overflow flaw while processing certain ATAPI commands - JosephRedfern
http://seclists.org/oss-sec/2015/q3/212

======
lelf
> _Deployment of patches or mitigations is NOT permitted (except on systems
> used and administered only by organisations which are members of the Xen
> Project Security Issues Predisclosure List). Specifically, deployment on
> public cloud systems is NOT permitted._

What is the rationale for this?

~~~
JoshTriplett
> The decision not to permit deployment was made by the group that, at their
> discretion, disclosed the issue to the Xen Project Security Team.

Xen has, in the past, worked with major cloud service providers to get patches
deployed early. Perhaps the view was that the major cloud providers aren't
enabling cdrom to begin with, or are using stubdomains, so it wasn't worth
risking the broader exposure; or perhaps there were past incidents with early
disclosure by cloud providers.

~~~
pm215
Note that it says "by the group that disclosed the issue". Xen's security
process says that it's the people who disclose issues to xen-security that get
to make this decision about pre-deployment.

------
sitkack
turn off stuff you don't need! features are the source of bugs.

~~~
JosephRedfern
Although I guess for many, it's a fairly important feature if you're creating
a new disk image.

~~~
flihp
Agree. There have been several vulns in the fringes of QEMU device emulation
code before but typically in lesser used devices (floppy etc). OTOH it's very
common to use CDROM emulation to install systems and I'm sure there are plenty
of admins who leave the ISO exposed to the guest "just in case".

------
Titanous
Note that without a separate Linux privilege escalation exploit, running QEMU
in a least-privilege "container" for each VM should help stem the bleeding.

~~~
wglb
How often is that how it is run?

~~~
rwmj
All the time if you use libvirt. Also libvirt adds SELinux protection on
platforms that support SELinux.

~~~
eeZi
> All the time if you use libvirt.

Does it? Afaik libvirt requires AppArmor/SELinux for this.

~~~
rwmj
cgroups and SELinux protections are separate. See:
[https://libvirt.org/cgroups.html](https://libvirt.org/cgroups.html) Also:
[https://libvirt.org/drvqemu.html#security](https://libvirt.org/drvqemu.html#security)

~~~
eeZi
But cgroups do not provide isolation, just better resource management.

~~~
rwmj
If you bother to read the second link I posted, you'll see that cgroups does
both (some) isolation and resource management. It's a layered scheme however
and you absolutely should be using SELinux which is where the really
comprehensive confinement happens.

~~~
eeZi
I read both links, and the "isolation" provided by cgroups alone will not
prevent exploitation of this bug (or any other, for that matter).

~~~
rwmj
You can flat out wrong about this, as you have been in your other answers. I
am an _upstream libvirt committer_ so I do know a fair bit about what libvirt
can do. The fact is that the isolation of cgroups will prevent various denial
of service bugs, and also access to non-whitelisted devices.

It is nowhere near as comprehensive as SELinux isolation, as I clearly said
way up there in my initial response -- which is also the reason why when you
use Docker on RHEL, most of the security comes from the additional SELinux
protections Red Hat have added.

~~~
eeZi
I agree with you that cgroups protect against denial of service attacks, and
that the device whitelist provides some additional security (I actually did
not know about the latter, so thanks! TIL). Thinking about it, if you
exclusively use block devices for storage, this is a lot better than I
expected.

But still, this is nowhere from a "a least-privilege container for each VM" as
you suggested.

(I'm a heavy libvirt user myself - thank you for your work on it!)

------
eeZi
How likely is exploitation, given that the QEMU binaries are compiled with all
available mitigations/hardening flags?

------
jtchang
Is KVM vulnerable or just Xen?

~~~
rwmj
Yup QEMU is vulnerable. Various details and patches in the Red Hat bug here:
[https://bugzilla.redhat.com/show_bug.cgi?id=1243563](https://bugzilla.redhat.com/show_bug.cgi?id=1243563)

