|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Xen-users] Xen Security Advisory 208 (CVE-2017-2615) - oob access in cirrus bitblt copy
On Sat, Feb 11, 2017 at 8:49 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote: > On Fri, Feb 10, 2017 at 12:43:17PM +0000, Xen.org security team wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Xen Security Advisory CVE-2017-2615 / XSA-208 >> >> oob access in cirrus bitblt copy >> >> ISSUE DESCRIPTION >> ================= >> >> When doing bitblt copy backwards, qemu should negate the blit width. >> This avoids an oob access before the start of video memory. >> >> IMPACT >> ====== >> >> A malicious guest administrator can cause an out of bounds memory >> access, possibly leading to information disclosure or privilege >> escalation. >> >> VULNERABLE SYSTEMS >> ================== >> >> Versions of qemu shipped with all Xen versions are vulnerable. >> >> Xen systems running on x86 with HVM guests, with the qemu process >> running in dom0 are vulnerable. >> >> Only guests provided with the "cirrus" emulated video card can exploit >> the vulnerability. The non-default "stdvga" emulated video card is >> not vulnerable. (With xl the emulated video card is controlled by the >> "stdvga=" and "vga=" domain configuration options.) >> >> ARM systems are not vulnerable. Systems using only PV guests are not >> vulnerable. >> >> For VMs whose qemu process is running in a stub domain, a successful >> attacker will only gain the privileges of that stubdom, which should >> be only over the guest itself. >> >> Both upstream-based versions of qemu (device_model_version="qemu-xen") >> and `traditional' qemu (device_model_version="qemu-xen-traditional") >> are vulnerable. >> >> MITIGATION >> ========== >> >> Running only PV guests will avoid the issue. >> >> Running HVM guests with the device model in a stubdomain will mitigate >> the issue. >> >> Changing the video card emulation to stdvga (stdvga=1, vga="stdvga", >> in the xl domain configuration) will avoid the vulnerability. >> >> RESOLUTION >> ========== >> >> Applying the appropriate attached patch resolves this issue. >> >> xsa208-qemuu.patch qemu-xen, mainline qemu > > The patch doesn't apply cleanly against the QEMU-upstream found in Xen 4.7.1: > > http://beefy9.nyi.freebsd.org/data/110amd64-default/433828/logs/xen-tools-4.7.1_2.log I'm working on an updated advisory., but in the meantime, Stefano checked in backported patches to the qemu-xen tree already; you can get those from the staging-4.* branches. (That doesn't address the qemu-traditional issues -- for those you'll have to wait for the updated advisory.) -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |