oss-security - Re: [Xen-devel] [Xen-users] Xen Security Advisory 208 (CVE-2017-2615)

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 13 Feb 2017 14:26:11 +0000
From: George Dunlap <dunlapg@...ch.edu>
To: Roger Pau Monné <roger.pau@...rix.com>
Cc: "Xen.org security team" <security@....org>, "xen-users@...ts.xen.org" <xen-users@...ts.xen.org>, 
	xen-announce@...ts.xen.org, oss-security@...ts.openwall.com, 
	"xen-devel@...ts.xen.org" <xen-devel@...ts.xen.org>
Subject: 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@...rix.com> 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

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.