Re: [Xen-devel] [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-09-07 at 20:39 +0100, Andrew Cooper wrote:
> On 07/09/12 20:33, Nathan March wrote:
> > Hi All,
> > 
> > I'm guessing this wasn't intentional, but the patch for xsa17 does
> not contain a complete path to the tools/ioemu-qemu-xen/ path:
> 
> This is because it applies to the qemu repository, not the xen
> repository.
> 
> It just so happens that the xen repository build system will pull it
> into a subdir to build it, if you dont do so manually.

It's also the case the in the tarball releases where qemu is
"pre-cloned" to that location.

We can't easily satisfy both the repo and tarball scenarios in one patch
but this is something we could clarify in the advisory text in the
future.

Ian.

> 
> ~Andrew
> 
> > 
> > --- a/console.c
> > +++ b/console.c
> > 
> > Compared to all the other patches which provide a full path to the
> patched file:
> > 
> > --- a/xen/include/asm-x86/debugreg.h Mon Aug 06 12:28:03 2012 +0100
> > +++ b/xen/include/asm-x86/debugreg.h Wed Aug 15 12:00:21 2012 +0100
> > 
> > Little annoying since it means you have to track down which
> console.c is being patched instead of just applying from the root xen
> build dir.
> > 
> > - Nathan
> > 
> >
> > ------ Original Message ------
> > From: "Xen.org security team" <security@xxxxxxx>
> > To:
> xen-announce@xxxxxxxxxxxxx;xen-devel@xxxxxxxxxxxxx;xen-users@xxxxxxxxxxxxx;oss-security@xxxxxxxxxxxxxxxxxx
> > Cc: "Xen.org security team" <security@xxxxxxx>
> > Sent: 9/5/2012 4:12:47 AM
> > Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu
> VT100 emulation vulnerability
> >            Xen Security Advisory CVE-2012-3515 / XSA-17
> >                           version 2
> > 
> >               Qemu VT100 emulation vulnerability
> > 
> > UPDATES IN VERSION 2
> > ====================
> > 
> > Public release.
> > 
> > ISSUE DESCRIPTION
> > =================
> > 
> > The device model used by fully virtualised (HVM) domains, qemu, does
> > not properly handle escape VT100 sequences when emulating certain
> > devices with a virtual console backend.
> > 
> > IMPACT
> > ======
> > 
> > An attacker who has sufficient privilege to access a vulnerable
> > device
> > within a guest can overwrite portions of the device model's address
> > space. This can allow them to escalate their privileges to that of
> > the
> > device model process.
> > 
> > VULNERABLE SYSTEMS
> > ==================
> > 
> > All Xen systems running HVM guests are potentially vulnerable to
> > this
> > depending on the specific guest configuration. The default
> > configuration is vulnerable.
> > 
> > Guests using either the traditional "qemu-xen" or upstream qemu
> > device
> > models are vulnerable.
> > 
> > MITIGATION
> > ==========
> > 
> > This issue can be avoided by only running PV guests or by
> > configuring
> > HVM guests to not use the virtual console('vc') backend for any
> > device.
> > 
> > For serial devices specify in your guest configuration:
> >     serial = 'none'
> > in your guest configuration.
> > 
> > For parallel port devices the syntax is toolstack specific.
> > For xend specify in your guest configuration:
> >     parallel = 'none'
> > For xl specify in your guest configuration:
> >     xl: device_model_args = ['-parallel', 'none']
> > 
> > In both cases the default is to use the vulnerable 'vc' mode.
> > 
> > You can confirm whether or not you are vulnerable by pressing
> > Ctrl-Alt-<N> (for digit N) while connected to either the VNC or SDL
> > console. If you are able to switch to a window displaying "serial"
> > or
> > "parallel" then you are vulnerable.
> > 
> > The issue can also be mitigated by enabling the stub domain device
> > model. In this case the attacked can only potentially gain control
> > of
> > the stub domain and not of the entire system.
> > 
> > To enable stub domains specify in your guest configuration:
> >    device_model = "stubdom-dm"
> > 
> > RESOLUTION
> > ==========
> > 
> > Applying the appropriate attached patch(es) will resolve the issue.
> > 
> > PATCH INFORMATION
> > =================
> > 
> > The attached patches resolve this issue
> > 
> > Traditional qemu tree
> >   Xen 4.0, 4.1 and unstable
> > xsa17-qemu-xen-traditional-all.patch
> > 
> > Upstream qemu tree (present in unstable only)
> >   Xen unstable                      xsa17-qemu-xen-unstable.patch
> > 
> > $ sha256sum xsa17-*.patch
> > 60215322d3fbbc2054dfc160a20d9e0811af88487c4edc2f6ea81dcd5cedf039
> > xsa17-qemu-xen-traditional-all.patch
> > 7b4bb59e7757080e7806a8b8eeb6b78fa0ffdfbfb28a7a379f7edff285bffd88
> > xsa17-qemu-xen-unstable.patch
> 
> -- 
> Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> T: +44 (0)1223 225 900, http://www.citrix.com
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel