QEMU heap overflow flaw while processing certain ATAPI commands | Hacker News Reader

QEMU heap overflow flaw while processing certain ATAPI commands

seclists.org

62 pointsJosephRedfern24 comments

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

Presumably it's because public deployment would have been noticed by malicious actors, who would have reverse engineered the fix and tried to use the exploit elsewhere.

I'm guessing that the embargo has run out and it's no longer restricted.

Perhaps its possible to pick up on the change from inside the Guest VM, and patching the problem on a public cloud would potentially expose the issue before members of the "Xen project Security Issues Predispose list" had a chance to patch? I'm not sure.

XEN embargoes patches to make sure they are released as synchronous as possible (i.e. patches hit the major distros and are deployed to all major deployments at the same time). The additional restriction in this case suggests that they think that observing a patched system as customer allows to figure out details of the vulnerability.

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

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.

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

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

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".

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

How often is that how it is run?

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

> All the time if you use libvirt.

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

cgroups and SELinux protections are separate. See: https://libvirt.org/cgroups.html Also: https://libvirt.org/drvqemu.html#security

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

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.

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

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.

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!)

XenServer runs their version of qemu under a unique unused uid, in a empty chroot and with a separate network namespace. This is the default behavior under XenServer.

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

Is KVM vulnerable or just Xen?

qemu-kvm is vulnerable too.

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

Reply on news.ycombinator.com