4 ms·
QEMU heap overflow flaw while processing certain ATAPI commands
- lelf 11y ago> 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?
- barrkel 11y agoPresumably 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.
- JosephRedfern 11y agoPerhaps 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.
- detaro 11y agoXEN 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.
- JoshTriplett 11y ago> 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 11y agoNote 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 11y agoturn off stuff you don't need! features are the source of bugs.
- JosephRedfern 11y agoAlthough I guess for many, it's a fairly important feature if you're creating a new disk image.
- flihp 11y agoAgree. 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 11y agoNote that without a separate Linux privilege escalation exploit, running QEMU in a least-privilege "container" for each VM should help stem the bleeding.
- wglb 11y agoHow often is that how it is run?
- rwmj 11y agoAll the time if you use libvirt. Also libvirt adds SELinux protection on platforms that support SELinux.
- eeZi 11y ago> All the time if you use libvirt. Does it? Afaik libvirt requires AppArmor/SELinux for this.
- rwmj 11y agocgroups 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 11y agoBut cgroups do not provide isolation, just better resource management.
- rwmj 11y agoIf 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 11y agoHow likely is exploitation, given that the QEMU binaries are compiled with all available mitigations/hardening flags?
- jtchang 11y agoIs KVM vulnerable or just Xen?