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

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

[Nathan March]

[-- Attachment #1.1: Type: text/plain, Size: 4315 bytes --]

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:

--- 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@xen.org>
To: 
xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Sent: 9/5/2012 4:12:47 AM
Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu 
VT100 emulation vulnerability
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>           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
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.10 (GNU/Linux)
>
>iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
>GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
>cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
>MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
>s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
>C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=
>=gnuE
>-----END PGP SIGNATURE-----
>
>

[-- Attachment #1.2: Type: text/html, Size: 7017 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Nathan March]

[-- Attachment #1.1: Type: text/plain, Size: 4884 bytes --]

Same issue also applies to the xsa-19 patch.

- Nathan

------ Original Message ------
From: "Nathan March" <nathan@gt.net>
To: "Xen.org security team" 
<security@xen.org>;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
Cc: "Xen.org security team" <security@xen.org>
Sent: 9/7/2012 12:33:42 PM
Subject: Re: [Xen-devel] [Xen-users] Xen Security Advisory 17 
(CVE-2012-3515) - Qemu VT100 emulation vulnerability
>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:

>--- 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@xen.org>
>To: xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
>Cc: "Xen.org security team" <security@xen.org>
>Sent: 9/5/2012 4:12:47 AM
>Subject: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu 
>VT100 emulation vulnerability
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>           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
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.10 (GNU/Linux)
>>
>>iQEcBAEBAgAGBQJQRx1PAAoJEIP+FMlX6CvZUqUH/jeAAvQnoBp6YKzm78XSnnmk
>>GI2C/LhH0xqR3wFoEmWeMsiO4lrGrASX6T31NTvHa8sOtFqlNpTfRhwQybwYR3aa
>>cz9/4y2a54hD95P1nVmPF0PddmSP47QSpRdCj0projq1UGxIdwEhkNeSoM8h7dXO
>>MegqZClsvJMKd8XEcjBF5Qg7u9vLrXilCx5+It7XNE31Jxpkr/fozBb7FnNtDGJj
>>s4RN/UDU4Pu68XyZ7Dc5xEFdJW48tz4BIlxxXavILBRFSE1VEf7Gc8H9CsUtBPWB
>>C/LCUjpHkAOmqdgFhiLnZ2u+2s79U0dtPDJMNmqaGgWH+AqGkU9Nq8XXODTyY9k=
>>=gnuE
>>-----END PGP SIGNATURE-----
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 9325 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Andrew Cooper]

[-- Attachment #1.1: Type: text/plain, Size: 4083 bytes --]

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.

~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@xen.org>
> To:
xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
> Cc: "Xen.org security team" <security@xen.org>
> 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


[-- Attachment #1.2: Type: text/html, Size: 6082 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Ian Campbell]

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@xen.org>
> > To:
> xen-announce@lists.xen.org;xen-devel@lists.xen.org;xen-users@lists.xen.org;oss-security@lists.openwall.com
> > Cc: "Xen.org security team" <security@xen.org>
> > 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
>