* Re: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability [not found] <E1T9DXL-0005Qu-97@xenbits.xen.org> @ 2012-09-07 19:33 ` Nathan March 2012-09-07 19:38 ` Nathan March 2012-09-07 19:39 ` Andrew Cooper 0 siblings, 2 replies; 4+ messages in thread From: Nathan March @ 2012-09-07 19:33 UTC (permalink / raw) To: xen-devel, xen-users, oss-security; +Cc: Xen.org security team [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability 2012-09-07 19:33 ` [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability Nathan March @ 2012-09-07 19:38 ` Nathan March 2012-09-07 19:39 ` Andrew Cooper 1 sibling, 0 replies; 4+ messages in thread From: Nathan March @ 2012-09-07 19:38 UTC (permalink / raw) To: Xen.org security team, xen-devel, xen-users [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability 2012-09-07 19:33 ` [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability Nathan March 2012-09-07 19:38 ` Nathan March @ 2012-09-07 19:39 ` Andrew Cooper 2012-09-08 5:39 ` Ian Campbell 1 sibling, 1 reply; 4+ messages in thread From: Andrew Cooper @ 2012-09-07 19:39 UTC (permalink / raw) To: xen-devel [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability 2012-09-07 19:39 ` Andrew Cooper @ 2012-09-08 5:39 ` Ian Campbell 0 siblings, 0 replies; 4+ messages in thread From: Ian Campbell @ 2012-09-08 5:39 UTC (permalink / raw) To: Andrew Cooper; +Cc: xen-devel@lists.xen.org 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-09-08 5:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1T9DXL-0005Qu-97@xenbits.xen.org>
2012-09-07 19:33 ` [Xen-users] Xen Security Advisory 17 (CVE-2012-3515) - Qemu VT100 emulation vulnerability Nathan March
2012-09-07 19:38 ` Nathan March
2012-09-07 19:39 ` Andrew Cooper
2012-09-08 5:39 ` Ian Campbell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.