[Xen-devel] Xen Security Advisory 243 (CVE-2017-15592) - x86: Incorrect handling of self-linear shadow mappings with translated guests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-15592 / XSA-243
version 5
x86: Incorrect handling of self-linear shadow mappings with translated guests
UPDATES IN VERSION 5
New final patch, addressing a hypervisor crash the original fix caused,
which by itself represents another security issue (DoS).
ISSUE DESCRIPTION
=
The shadow pagetable code uses linear mappings to inspect and modify the
shadow pagetables. A linear mapping which points back to itself is known as
self-linear. For translated guests, the shadow linear mappings (being in a
separate address space) are not intended to be self-linear. For
non-translated guests, the shadow linear mappings (being the same
address space) are intended to be self-linear.
When constructing a monitor pagetable for Xen to run on a vcpu with, the shadow
linear slot is filled with a self-linear mapping, and for translated guests,
shortly thereafter replaced with a non-self-linear mapping, when the guest's
%cr3 is shadowed.
However when writeable heuristics are used, the shadow mappings are used as
part of shadowing %cr3, causing the heuristics to be applied to Xen's
pagetables, not the guest shadow pagetables.
While investigating, it was also identified that PV auto-translate mode was
insecure. This mode was removed in Xen 4.7 due to being unused, unmaintained
and presumed broken. We are not aware of any guest implementation of PV
auto-translate mode.
IMPACT
==
A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a
Denial of Service (DoS) affecting the entire host, or cause hypervisor memory
corruption. We cannot rule out a guest being able to escalate its privilege.
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
HVM guests using shadow mode paging can exploit this vulnerability.
HVM guests using Hardware Assisted Paging (HAP) as well as PV guests
cannot exploit this vulnerability.
ARM systems are not vulnerable.
MITIGATION
==
Running only PV guests will avoid this vulnerability.
Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests. HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached set of patches resolves this issue.
xsa243-[12].patchxen-unstable, Xen 4.9.x
xsa243-{4.8-1,2}.patch Xen 4.8.x
xsa243-{4.7-1,2}.patch Xen 4.7.x
xsa243-{4.6-[12],2}.patchXen 4.6.x
xsa243-4.{6-1,5-[23]}.patch Xen 4.5.x
$ sha256sum xsa243*
a5b484db80346f7e75c7921ee4780567f04b9f9b4620c0cde4bfa1df3ac0f87f xsa243-1.patch
013cff90312305b7f4ce6818a25760bcfca61bfadd860b694afa04d56e60c563 xsa243-2.patch
79e1c5e088eee8e78aa67895a29d611352c64251854e4c5129e33c85988a47a5
xsa243-4.5-2.patch
b838f387747c6e45314f44202c018ad907a8119bb7d8330fc875dc4243626e78
xsa243-4.5-3.patch
722073aad1e734e24b0b79d03a1957e491f3616fe6e244a89050f7a50f8f356b
xsa243-4.6-1.patch
94cb346c486f88f2f4f701564017e1997e518a5a14218f0e38ff882c60fb382c
xsa243-4.6-2.patch
465ba9e3293591a3c84c122ffd73474fe96483f5e21565440d5fbc207fa4c4a9
xsa243-4.7-1.patch
f8e471b42502905a442d43934ac339663a6124118c9762b31f2ad930fd532e64
xsa243-4.8-1.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJaDHWmAAoJEIP+FMlX6CvZbKgH/RsntzKBpEJQfElzpN15+eMM
Kakfq3Mzad4JuaOb5dVy4fhE88gHgE344mmiUqu/h+pwRKofC/a3DvS4GPO8NJAI
Zdu1CCkuZ3/L3IpbtdGsLMw1EZGQLXNsQGWCgDB3sNAT6Ue+FvmJbiP0RkIO+qXw
7KSCfs2NtMvkj17jt5ZYj2Y43d0IvWirR3LHkJIDR0ZPYkX5WagAmuOom3bj57lt
0Q/GC40x+kO9lQSw299CZxuHTi34zu0V4/HRtfSSVph5Gbcb+4kxMqv8e3wRfgg9
[Xen-devel] Xen Security Advisory 236 (CVE-2017-15597) - pin count / page reference race in grant table code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15597 / XSA-236 version 3 pin count / page reference race in grant table code UPDATES IN VERSION 3 We now once again think that only Xen 4.2 and newer are vulnerable. Fix grammar typo. Public release. ISSUE DESCRIPTION = Grant copying code made an implication that any grant pin would be accompanied by a suitable page reference. Other portions of code, however, did not match up with that assumption. When such a grant copy operation is being done on a grant of a dying domain, the assumption turns out wrong. IMPACT == A malicious guest administrator can cause hypervisor memory corruption, most likely resulting in host crash and a Denial of Service. Privilege escalation and information leaks cannot be ruled out. VULNERABLE SYSTEMS == Xen versions from 4.2 onwards are vulnerable. Xen versions 4.1 and earlier are not vulnerable. Both x86 and ARM are vulnerable, and on x86 both PV and HVM guests can trigger the vulnerability. MITIGATION == Running only guests without para-virtual drivers, and known not to issue grant table operations can avoid the vulnerability. CREDITS === This issue was discovered by Pawel Wieczorkiewicz of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa236.patch xen-unstable xsa236-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa236-4.5.patch Xen 4.5.x $ sha256sum xsa236* 2f7736c43b6da7d983cf3edbc10024c4cba9d6d3e5b2b758a07de726a804617d xsa236.meta f06f01fb4ffcfc7938a2fc6ab73559ebbaac2d448bd36ca538bb07ba510eeb4a xsa236.patch c98a4b50d021414626cd68002643e9aa0cc6067b98cd5dd995c0140a7933d1ea xsa236-4.5.patch b6fe5604af26e93184f30127ebbb644f127ecc7116b093c161ca3044b44d2fe9 xsa236-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ70ZiAAoJEIP+FMlX6CvZlBgH/0cwYrP3/zvc3dNJRtpxyn1J BkigYP8JBIYW85M7KdZDFBhgXIpuw6x45XZ4qfq6rrz3GOp5oZgZVFIoggHZBzRe eVCIpjOAXInM7ThsE6pV1Qr/JKe8V6RJumXEgqr5zznWpGmcFChWmobA+BBq64P6 87ALWjXBcuqOyjJnJQwEjk+kHJMnIpocVZk6NqcDeoHoJvRh/Zk4YYc78qm4Lucw d0yHq5azA9bgt5iJgxUvF74B4r8JxTLmA8sn7Kx280UJGEAkqM7jj1QVQ6sb8fgO q6RSzBVnuVqLh4E1Dji9KaxcRRVnbrp2FFpBUUWHAVVO4O0GYlu5NxERnnye9v0= =zI77 -END PGP SIGNATURE- xsa236.meta Description: Binary data xsa236.patch Description: Binary data xsa236-4.5.patch Description: Binary data xsa236-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 239 (CVE-2017-15589) - hypervisor stack leak in x86 I/O intercept code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15589 / XSA-239 version 3 hypervisor stack leak in x86 I/O intercept code UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Intercepted I/O operations may deal with less than a full machine word's worth of data. While read paths had been the subject of earlier XSAs (and hence have been fixed), at least one write path was found where the data stored into an internal structure could contain bits from an uninitialized hypervisor stack slot. A subsequent emulated read would then be able to retrieve these bits. IMPACT == A malicious unprivileged x86 HVM guest may be able to obtain sensitive information from the host or other guests. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only HVM guests can leverage this vulnerability. PV guests cannot leverage this vulnerability. MITIGATION == Running only PV guests will avoid this issue. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa239.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa239-4.5.patch Xen 4.5.x $ sha256sum xsa239* eb7971be89199eb3ff510f4f5650fd5a8ec588b9fcb8f89230216fac4214ef21 xsa239.meta 087a8b3cf7ecbdbde593033c127cbcf6c37f532bf33d90f72c19e493970a799c xsa239.patch b91a68fe67240f2a5bb9460c5b650e9595364afa180f8702aef783815e3d7dcd xsa239-4.5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ50QiAAoJEIP+FMlX6CvZ9+EH/3FDnPzVeA+Rd8rblNpLh7VQ oyQ0B0olLYPZHLHQ2yzNJAg/1wv1ar7K2Rs0E1kovSqFZWdrTeo0DFKy418+rD6j TvSxYq0ktC0ir5cUSeExhHRDkBGDlEAuugdC381e0g89KT7Sv+kQz8t06yBV9KIP hnWPWcGvzeIKQX//Gd5i4618zhqGHI29LBuFJyMdrDcHSdD8f5B81n+pWojZ8JDP gYbhLHr0MLev2CH0URiegc7FIvbEPbW4rAzuEAKbMLfLMMwPg+eLJsM25WCTWuE7 AiQUvx3zyD76EZ7gjVIDV/AazOWmMpZHrS1Rd+LwNYTeuV77JDebSI6KJ+X0jHc= =v3zp -END PGP SIGNATURE- xsa239.meta Description: Binary data xsa239.patch Description: Binary data xsa239-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 241 (CVE-2017-15588) - Stale TLB entry due to page type release race
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15588 / XSA-241 version 4 Stale TLB entry due to page type release race UPDATES IN VERSION 4 CVE assigned. ISSUE DESCRIPTION = x86 PV guests effect TLB flushes by way of a hypercall. Xen tries to reduce the number of TLB flushes by delaying them as much as possible. When the last type reference of a page is dropped, the need for a TLB flush (before the page is re-used) is recorded. If a guest TLB flush request involves an Inter Processor Interrupt (IPI) to a CPU in which is the process of dropping the last type reference of some page, and if that IPI arrives at exactly the right instruction boundary, a stale time stamp may be recorded, possibly resulting in the later omission of the necessary TLB flush for that page. IMPACT == A malicious x86 PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only x86 systems are affected. ARM systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests cannot leverage the vulnerability. RISK ASSESSMENT === A successful attack would require introducing an extended delay between two adjacent operations on one cpu -- long enough for two hypercalls to complete on another cpu. The security team currently has no proof-of-concept for this vulnerability. However, techniques for these sorts of timing-based attacks are continually advancing, so we still recommend users potentially affected by this issue apply the patch as soon as reasonably possible. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa241.patch xen-unstable xsa241-4.9.patch Xen 4.9.x xsa241-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa241* 5e239ba4dbd74fd61e59a27f9abc8ea6ba32532bdf81eeb2d7e66f0fd53e40b4 xsa241.meta b8db933d53e7e289652ffda6c46ce284a0254a9f8bc9e1be6793e388009f49ce xsa241.patch 443a5b0818045ada44fad0370ac01af0c96181be5a4078ae3b2575799e4a4e5b xsa241-4.8.patch 927ef14d875556481c38d4065f501211a78eec1c2396a954a4a4abfb9255960f xsa241-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ50QlAAoJEIP+FMlX6CvZp/cH/2z+BXU30Jg8PlfnXM7LDulR +ZyoPggsqJfE8AlY7XmsPXo8qY1vsG1NHI6D0YoTvgQyFDVa2h2IBkIc/aZd7jfW iUYTluAQcxFKSC7G02HCrMdY6w9HkpIo4AtYw9Rm6tueF9/0vaWm0jy7MCMrNxAt Dbx8a91dkKiJ9MImLralZUMewK6kym1p2PhVPgWmF3lprvLiLSbRu19eiYSAdjBa C8ulKhUZsDymM3Lpe+F7+9FATZ58sEyvqgAach0Wn/vhaJ0axHroW3KKVCdNMNVJ AqFHjv6NKgHGS3HU9TEOCfCptYqE+Ne/UB4M19nVOZulfZn4Ok2MgBvogJXIA/Q= =7sHr -END PGP SIGNATURE- xsa241.meta Description: Binary data xsa241.patch Description: Binary data xsa241-4.8.patch Description: Binary data xsa241-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 244 (CVE-2017-15594) - x86: Incorrect handling of IST settings during CPU hotplug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15594 / XSA-244 version 3 x86: Incorrect handling of IST settings during CPU hotplug UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The x86-64 architecture allows interrupts to be run on distinct stacks. The choice of stack is encoded in a field of the corresponding interrupt descriptor in the Interrupt Descriptor Table (IDT). That field selects an entry from the active Task State Segment (TSS). Since, on AMD hardware, Xen switches to an HVM guest's TSS before actually entering the guest, with the Global Interrupt Flag still set, the selectors in the IDT entry are switched when guest context is loaded/unloaded. When a new CPU is brought online, its IDT is copied from CPU0's IDT, including those selector fields. If CPU0 happens at that moment to be in HVM context, wrong values for those IDT fields would be installed for the new CPU. If the first guest vCPU to be run on that CPU belongs to a PV guest, it will then have the ability to escalate its privilege or crash the hypervisor. IMPACT == A malicious or buggy x86 PV guest could escalate its privileges or crash the hypervisor. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only PV guests can exploit the vulnerability. HVM guests cannot exploit the vulnerability, but their presence is necessary for the exposure of the vulnerability to PV guests. Only x86 systems using SVM (AMD virtualisation extensions) rather than VMX (Intel virtualisation extensions) are vulnerable. Therefore AMD x86 hardware is vulnerable; Intel hardware is not vulnerable. ARM systems are not vulnerable. MITIGATION == Avoiding to online CPUs at runtime will avoid this vulnerability. Running only HVM or only PV guests on any individual host will also avoid this vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa244.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa244-4.7.patch Xen 4.7.x xsa244-4.6.patch Xen 4.6.x xsa244-4.5.patch Xen 4.5.x $ sha256sum xsa244* 5b663620a1b0d5f07e7ae4d1d3506d925515d5f85830ca49dda75cab1218506f xsa244.meta bcf22b332bf3f6fe8c86e4de67f82628c9b8e257d9513c3bf5c7f5dd71d86c33 xsa244.patch 4c4543fdfd25b4a8ea7d53f3f45011ec137798e7d4e690d8f3ea58d77afb5f06 xsa244-4.5.patch eaa3ba303980d783813db7aee948a9cb2723328da5fa5650ffca7b825c21bab6 xsa244-4.6.patch 4d8cf754f760ef05488e9fb25a7ebd9a7e46f3742e91eee1a8385fd1e611ea8c xsa244-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ50QqAAoJEIP+FMlX6CvZmsEIAKuPA1/ly1Hgf9vZCkbKauO/ df8JgVdLemcGSEfDwzVlRjHQh0QtpMLNG5RCYRD+s8hrCotKc8dC95+pIztDY/l+ lw6k9bCFup7hI++IdL/fmy79RS+WUOinMEOwD39zqFVK+y6J2M0iXnuKqxtF+j/7 zWVmzdZIHbM+6DlRr1uN0jpirqkJ8P5yNMBgqhp4zH4efOe0Olv+0SQtNtNclCib MR4ipBbkK9sCMN6odZCbnwKkn2zyCDSfPiXnINfiIbsUweCf9n6MEpry8Kiae90Z BFn+KGkRcC9gQkoKRoF/rDwG02P6KCb34pNY0nVgxtr4pDYqJzhEh7+eGXfVHME= =dk0t -END PGP SIGNATURE- xsa244.meta Description: Binary data xsa244.patch Description: Binary data xsa244-4.5.patch Description: Binary data xsa244-4.6.patch Description: Binary data xsa244-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 237 (CVE-2017-15590) - multiple MSI mapping issues on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15590 / XSA-237 version 3 multiple MSI mapping issues on x86 UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Multiple issues exist with the setup of PCI MSI interrupts: - - unprivileged guests were permitted access to devices not owned by them, in particular allowing them to disable MSI or MSI-X on any device - - HVM guests can trigger a codepath intended only for PV guests - - some failure paths partially tear down previously configured interrupts, leaving inconsistent state - - with XSM enabled, caller and callee of a hook disagreed about the data structure pointed to by a type-less argument IMPACT == A malicious or buggy guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be excluded. VULNERABLE SYSTEMS == All Xen versions from at 3.3 onwards are vulnerable. Xen versions 3.2 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. Only guests which have a physical device assigned to them can exploit the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Simon Gaiser of Qubes OS Project. RESOLUTION == Applying the appropriate attached set of patches resolves this issue. xsa237-unstable/*.patch xen-unstable xsa237-4.9/*.patch Xen 4.9.x xsa237-4.8/*.patch Xen 4.8.x, Xen 4.7.x xsa237-4.6/*.patch Xen 4.6.x xsa237-4.5/*.patch Xen 4.5.x $ sha256sum xsa237* xsa237*/* 1d4d3fa452e91d235fd688761d695752bde2f2e91fd9b17f566c4cee23ae26d0 xsa237.meta 3259cd514ea80e3cbac5b72376b4e964afb3b2cabee347440ec2bdd6e585c513 xsa237-unstable/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch 7ef53f6a5f3fc6952cb8411e31e0a670de5a78ab2c8176037db32cf147438aa6 xsa237-unstable/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-unstable/0003-x86-MSI-disallow-redundant-enabling.patch 503b58512c5336aff9692c0d0768f38ee956c0988fa3fad4d439f13814736e06 xsa237-unstable/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch dc5f27245e44582db682ac53f24007685ea2f8cb104bad9b4d6afeaa7c4e73d2 xsa237-unstable/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6 xsa237-4.5/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch 87bbb240323b3cce9767da73961d58436c436db6da614c62ade7640f87f748dd xsa237-4.5/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 6a2e6772fa7b7a1683f7b1041f0675756268635aedb8c760ebcd9ad0ff7a xsa237-4.5/0003-x86-MSI-disallow-redundant-enabling.patch c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d xsa237-4.5/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch 60169e2016451e1c479c4f873ee6798b6abc46e3223a60a4b83bac20a7a3d27c xsa237-4.5/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6 xsa237-4.6/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch d39d1c0eaf2ba169b6596520b05930d280721c397fafa3414b6da6168e8b73ca xsa237-4.6/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-4.6/0003-x86-MSI-disallow-redundant-enabling.patch c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d xsa237-4.6/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch 4cdcd71758d9e5b392c38aeafc9960a4f3ef5c109508e69b2218a8d8394edf0b xsa237-4.6/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch 1ae6aefb86ba0c48a45ecc14ff56ea0bc3d9d354937668bcacadaed1225017a8 xsa237-4.8/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch bf2ca9cb99ee64d7db77d628cec1a84684c360fd36de433cbc78fbcde8095319 xsa237-4.8/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-4.8/0003-x86-MSI-disallow-redundant-enabling.patch 9a38899afd728d504382954de28657aa82af7da352eb4e45a5e615bd646834c5 xsa237-4.8/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch fef5c77f19e2c6229912f1fd19cbcb41c1ce554ff53be22198b2f34ea7a27314 xsa237-4.8/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch
[Xen-devel] Xen Security Advisory 242 (CVE-2017-15593) - page type reference leak on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15593 / XSA-242 version 3 page type reference leak on x86 UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The page type system of Xen requires cleanup when the last reference for a given page is being dropped. In order to exclude simultaneous updates to a given page by multiple parties, pages which are updated are locked beforehand. This locking includes temporarily increasing the type reference count by one. When the page is later unlocked, the context precludes cleanup, so the reference that is then dropped must not be the last one. This was not properly enforced. IMPACT == A malicious or buggy PV guest may cause a memory leak upon shutdown of the guest, ultimately perhaps resulting in Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests cannot leverage the vulnerability. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa242.patch xen-unstable xsa242-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa242* 168db3aef00806025afa255dee35cd0c042706a27a0256744e4d63f3ee86a2e8 xsa242.meta 16848f71311c2fd6a38afd7602e59211c89a3daf29b874097dba0b1e31ba6eec xsa242.patch 5e66b6b1d1cd400905d3abd3478144539c3afa24f5a744a11809d9c5eb517b98 xsa242-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ50QmAAoJEIP+FMlX6CvZ8KMIALNhUmBoSrrx6V16Z8rPKRTs uBJ9b5KcUs6aiOvTD8HnGpukF5g4W+O4MzGY0WkIGjUIXgYYj4Fjnib+40x99Bp0 W6m7EMfkU3N9hg4BPAy33MHEwK/kC9TNxro3IxYXCzSZzZn6FG64x2j1gULZvz66 +mAIaiSF0cvrn/uB1aBoAW6z+kCtqq7+XzzeC61hHmEYseYa+5JY20xB0zJ9hQe2 KER5QTzySFsbLv/3uQ2KamQK318YBzVuFry04/ZFOXJFlz9UdP74xcRyCXuaWQCV EGehp54ri3qqPv5Cc2tAKATbllIrHWizhF9dtM5vnXkvFKjh3jq8cszmuRga9zI= =Y0V/ -END PGP SIGNATURE- xsa242.meta Description: Binary data xsa242.patch Description: Binary data xsa242-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 243 (CVE-2017-15592) - x86: Incorrect handling of self-linear shadow mappings with translated guests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-15592 / XSA-243
version 4
x86: Incorrect handling of self-linear shadow mappings with translated guests
UPDATES IN VERSION 4
CVE assigned.
ISSUE DESCRIPTION
=
The shadow pagetable code uses linear mappings to inspect and modify the
shadow pagetables. A linear mapping which points back to itself is known as
self-linear. For translated guests, the shadow linear mappings (being in a
separate address space) are not intended to be self-linear. For
non-translated guests, the shadow linear mappings (being the same
address space) are intended to be self-linear.
When constructing a monitor pagetable for Xen to run on a vcpu with, the shadow
linear slot is filled with a self-linear mapping, and for translated guests,
shortly thereafter replaced with a non-self-linear mapping, when the guest's
%cr3 is shadowed.
However when writeable heuristics are used, the shadow mappings are used as
part of shadowing %cr3, causing the heuristics to be applied to Xen's
pagetables, not the guest shadow pagetables.
While investigating, it was also identified that PV auto-translate mode was
insecure. This mode was removed in Xen 4.7 due to being unused, unmaintained
and presumed broken. We are not aware of any guest implementation of PV
auto-translate mode.
IMPACT
==
A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a
Denial of Service (DoS) affecting the entire host, or cause hypervisor memory
corruption. We cannot rule out a guest being able to escalate its privilege.
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
HVM guests using shadow mode paging can exploit this vulnerability.
HVM guests using Hardware Assisted Paging (HAP) as well as PV guests
cannot exploit this vulnerability.
ARM systems are not vulnerable.
MITIGATION
==
Running only PV guests will avoid this vulnerability.
Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests. HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa243.patch xen-unstable, Xen 4.9.x
xsa243-4.8.patch Xen 4.8.x
xsa243-4.7.patch Xen 4.7.x
xsa243-4.6-[1,2].patch Xen 4.6.x
xsa243-4.{6-1,5-2}.patch Xen 4.5.x
$ sha256sum xsa243*
61b05e2d6655f5d18cd53b16e03499152c603162584f64d68fad31b088cc5cd2 xsa243.meta
a5b484db80346f7e75c7921ee4780567f04b9f9b4620c0cde4bfa1df3ac0f87f xsa243.patch
79e1c5e088eee8e78aa67895a29d611352c64251854e4c5129e33c85988a47a5
xsa243-4.5-2.patch
722073aad1e734e24b0b79d03a1957e491f3616fe6e244a89050f7a50f8f356b
xsa243-4.6-1.patch
94cb346c486f88f2f4f701564017e1997e518a5a14218f0e38ff882c60fb382c
xsa243-4.6-2.patch
465ba9e3293591a3c84c122ffd73474fe96483f5e21565440d5fbc207fa4c4a9
xsa243-4.7.patch
f8e471b42502905a442d43934ac339663a6124118c9762b31f2ad930fd532e64
xsa243-4.8.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZ50QoAAoJEIP+FMlX6CvZfY8H/j9FvKi/ZMCbL0bkiHzDurGB
oUhuw21LyJ0xCvBu+Qo94LsKPNwmhcsGdk13kjwYHorIBsjlJgAxavri4HnWLVx/
vdAavrPXrjf69q4YAbLVowjevhwdapGYaEn9q/ftURReDi5c5UEs/sxRgg2BeMWb
CYYFGYEWfpWDR2KpOgZib8Pg4G9Jz8oyzFAopnJpuBK2whbnTDlABnX15DGTFeih
Rk9OJDqfARelnqXS6I+AG8erqyaI1gWvoVjEuSDDUv/H27N/qRaG4WCsSdENQS/V
HLm+oxgJyC8sWAyE8Fr6DUZSf/jW8QBvt1iuLJIUXL7ns8B0U527iM3185T2TYA=
=Gwk6
-END PGP SIGNATURE-
xsa243.meta
Description: Binary data
xsa243.patch
Description: Binary data
xsa243-4.5-2.patch
Description: Binary data
xsa243-4.6-1.patch
Description: Binary data
xsa243-4.6-2.patch
[Xen-devel] Xen Security Advisory 235 (CVE-2017-15596) - add-to-physmap error paths fail to release lock on ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-15596 / XSA-235 version 2 add-to-physmap error paths fail to release lock on ARM UPDATES IN VERSION 2 CVE assigned. ISSUE DESCRIPTION = When dealing with the grant map space of add-to-physmap operations, ARM specific code recognizes a number of error conditions, but fails to release a lock being held on the respective exit paths. IMPACT == A malicious guest administrator can cause a denial of service. Specifically, prevent use of a physical CPU for an indefinite period of time. VULNERABLE SYSTEMS == Xen versions 4.4 and later are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only ARM systems are affected. X86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which only issue sane hypercalls will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Wei Liu of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa235.patch xen-unstable xsa235-4.9.patch Xen 4.9.x, Xen 4.8.x xsa235-4.7.patch Xen 4.7.x xsa235-4.6.patch Xen 4.6.x xsa235-4.5.patch Xen 4.5.x $ sha256sum xsa235* 6ec8bf9462de65fee3896246f52c00941b2d83c759b3f7b28a440eb977fcbc37 xsa235.meta c81f534e96fe38b9f77794bb143d104d66ce2d7177bda43f872642616e23df65 xsa235.patch 3c21cb1a53f5979b069568c6cd6df3aad00c19e0e459e37625d6a3c0f4f360cc xsa235-4.5.patch 47cda4f32b65f3543af368c324a2e5b308b698a1c7d8bc84fc274eb2cdb45c0e xsa235-4.6.patch f30848eee71e66687b421b87be1d8e3f454c0eb395422546c62a689153d1e31c xsa235-4.7.patch d8f012734fbf6019c1ff864744e308c41dfb9c7804ca3be2771c2c972cdf4bd5 xsa235-4.9.patch $ NOTE REGARDING LACK OF EMBARGO == The issue was discussed publicly before being recognized as a security issue. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ50QUAAoJEIP+FMlX6CvZR0QH/RdlZ9q8CcqWVVF+De8dlKwk HtgYWWGK/gYgfiwhnYT1fJlW3XZOvbf/fZDUTnuFYL6izJtpcEPuEb3tWM5Nzcs/ u85wyYQmzmDPRCJVuONamWFc0vnSBvb1NqKVqwQEBo3WVbPS5YwIaFgA/z8lZaT9 NV90FLOBjjRyh9ktxqtGQQvt1JcxVxNWLbV974PwFuURMC5kTt2eNvU2vOmgWV5V gmlBcJyMEzAaZKCmotkt1Tla82ydXG1F+obaLhSVRWp0JFugvVJX9I3cqZk4rovv HKqLm1bmzloWPo2wvjSnRJIVu9us3MD4VqjxWOwQQq1nrTdDdlMcC6sfn93PaVo= =R0BH -END PGP SIGNATURE- xsa235.meta Description: Binary data xsa235.patch Description: Binary data xsa235-4.5.patch Description: Binary data xsa235-4.6.patch Description: Binary data xsa235-4.7.patch Description: Binary data xsa235-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 238 - DMOP map/unmap missing argument checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-238 version 2 DMOP map/unmap missing argument checks UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = DMOPs (which were a subgroup of HVMOPs in older releases) allow guests to control and drive other guests. The I/O request server page mapping interface uses range sets to represent I/O resources the emulation of which is provided by a given I/O request server. The internals of the range set implementation require that ranges have a starting value no lower than the ending one. Checks for this fact were missing. IMPACT == Malicious or buggy stub domain kernels or tool stacks otherwise living outside of Domain0 can mount a denial of service attack which, if successful, can affect the whole system. Only domains controlling HVM guests can exploit this vulnerability. (This includes domains providing hardware emulation services to HVM guests.) VULNERABLE SYSTEMS == Xen versions 4.5 and later are vulnerable. Xen versions 4.4 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. This vulnerability is only applicable to Xen systems using stub domains or other forms of disaggregation of control domains for HVM guests. MITIGATION == Running only PV guests will avoid this issue. (The security of a Xen system using stub domains is still better than with a qemu-dm running as an unrestricted dom0 process. Therefore users with these configurations should not switch to an unrestricted dom0 qemu-dm.) CREDITS === This issue was discovered by Vitaly Kuznetsov of RedHat. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa238.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa238-4.6.patch Xen 4.6.x xsa238-4.5.patch Xen 4.5.x $ sha256sum xsa238* 3cced09a1fb2936644d654c568f38580952328b84e28601b019ea7418c36 xsa238.meta 85d3f9713bef1bc86c682857dbd7388a1d1f20089363ddfc4cb9ecbd88eaffec xsa238.patch 034e91c234f6831dbaa1aaf29f4f90de2e822f99301424f7f3527f9da883ff68 xsa238-4.5.patch 29255a81729b24866e594426167de5fbef70de21ef62a95ba95de191d2a7fd54 xsa238-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ31v7AAoJEIP+FMlX6CvZrBgIAMg3C1Gvc3rnrPjT+0Im7gdQ vBXGAWViWDs7EC1Vl5IU6lQQKETNmx40kRPyOYOVSdPzWamOotXOSadpJ49mbTX1 CA2iSJ8OAdqcPhgKjdUYVJXkybujNp6WkdlcT6ZXvEs6DLuvKJXZBaRoX2vYtObq JjwUfGgpHcOc8vLhaEjEZTWRnKJotqQPaPaDHzrtGJAkHB0F+gwqpM4lBD6Q18+/ DzyBWlDENEcoSwzDldZ/4Ktl/rOXDOPoYYZfnFmYA2puWP7ujonio8iofOy+6GH3 GoKSPs1ciC4ax1WdJqbuxM0TCStz4QFOselVQ0hEJNdH6k3mmA4wMg+6kPNDf2U= =9idj -END PGP SIGNATURE- xsa238.meta Description: Binary data xsa238.patch Description: Binary data xsa238-4.5.patch Description: Binary data xsa238-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 237 - multiple MSI mapping issues on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-237 version 2 multiple MSI mapping issues on x86 UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Multiple issues exist with the setup of PCI MSI interrupts: - - unprivileged guests were permitted access to devices not owned by them, in particular allowing them to disable MSI or MSI-X on any device - - HVM guests can trigger a codepath intended only for PV guests - - some failure paths partially tear down previously configured interrupts, leaving inconsistent state - - with XSM enabled, caller and callee of a hook disagreed about the data structure pointed to by a type-less argument IMPACT == A malicious or buggy guest may cause the hypervisor to crash, resulting in Denial of Service (DoS) affecting the entire host. Privilege escalation and information leaks cannot be excluded. VULNERABLE SYSTEMS == All Xen versions from at 3.3 onwards are vulnerable. Xen versions 3.2 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. Only guests which have a physical device assigned to them can exploit the vulnerability. MITIGATION == Not passing through physical devices to untrusted guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Simon Gaiser of Qubes OS Project. RESOLUTION == Applying the appropriate attached set of patches resolves this issue. xsa237-unstable/*.patch xen-unstable xsa237-4.9/*.patch Xen 4.9.x xsa237-4.8/*.patch Xen 4.8.x, Xen 4.7.x xsa237-4.6/*.patch Xen 4.6.x xsa237-4.5/*.patch Xen 4.5.x $ sha256sum xsa237* xsa237*/* 1d4d3fa452e91d235fd688761d695752bde2f2e91fd9b17f566c4cee23ae26d0 xsa237.meta 3259cd514ea80e3cbac5b72376b4e964afb3b2cabee347440ec2bdd6e585c513 xsa237-unstable/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch 7ef53f6a5f3fc6952cb8411e31e0a670de5a78ab2c8176037db32cf147438aa6 xsa237-unstable/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-unstable/0003-x86-MSI-disallow-redundant-enabling.patch 503b58512c5336aff9692c0d0768f38ee956c0988fa3fad4d439f13814736e06 xsa237-unstable/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch dc5f27245e44582db682ac53f24007685ea2f8cb104bad9b4d6afeaa7c4e73d2 xsa237-unstable/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6 xsa237-4.5/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch 87bbb240323b3cce9767da73961d58436c436db6da614c62ade7640f87f748dd xsa237-4.5/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 6a2e6772fa7b7a1683f7b1041f0675756268635aedb8c760ebcd9ad0ff7a xsa237-4.5/0003-x86-MSI-disallow-redundant-enabling.patch c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d xsa237-4.5/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch 60169e2016451e1c479c4f873ee6798b6abc46e3223a60a4b83bac20a7a3d27c xsa237-4.5/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch cd9cd248c4564552bbe847462d247b78ff6af1052198e6b6529178a8a624e1f6 xsa237-4.6/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch d39d1c0eaf2ba169b6596520b05930d280721c397fafa3414b6da6168e8b73ca xsa237-4.6/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-4.6/0003-x86-MSI-disallow-redundant-enabling.patch c558ca347b6df9b430fbdaf9c9b8e3b203c273be1e2bb01aa3424773b88df91d xsa237-4.6/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch 4cdcd71758d9e5b392c38aeafc9960a4f3ef5c109508e69b2218a8d8394edf0b xsa237-4.6/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch 1ae6aefb86ba0c48a45ecc14ff56ea0bc3d9d354937668bcacadaed1225017a8 xsa237-4.8/0001-x86-dont-allow-MSI-pIRQ-mapping-on-unowned-device.patch bf2ca9cb99ee64d7db77d628cec1a84684c360fd36de433cbc78fbcde8095319 xsa237-4.8/0002-x86-enforce-proper-privilege-when-mapping-pIRQ-s.patch 494a79332fc5f854f0dc7606669201717a41e5b89b44db2fb30607a326930bfb xsa237-4.8/0003-x86-MSI-disallow-redundant-enabling.patch 9a38899afd728d504382954de28657aa82af7da352eb4e45a5e615bd646834c5 xsa237-4.8/0004-x86-IRQ-conditionally-preserve-irq-pirq-mapping-on-error.patch fef5c77f19e2c6229912f1fd19cbcb41c1ce554ff53be22198b2f34ea7a27314 xsa237-4.8/0005-x86-FLASK-fix-unmap-domain-IRQ-XSM-hook.patch
[Xen-devel] Xen Security Advisory 242 - page type reference leak on x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-242 version 2 page type reference leak on x86 UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The page type system of Xen requires cleanup when the last reference for a given page is being dropped. In order to exclude simultaneous updates to a given page by multiple parties, pages which are updated are locked beforehand. This locking includes temporarily increasing the type reference count by one. When the page is later unlocked, the context precludes cleanup, so the reference that is then dropped must not be the last one. This was not properly enforced. IMPACT == A malicious or buggy PV guest may cause a memory leak upon shutdown of the guest, ultimately perhaps resulting in Denial of Service (DoS) affecting the entire host. VULNERABLE SYSTEMS == All Xen versions from 3.4 onwards are vulnerable. Xen versions 3.3 and earlier are not vulnerable. Only x86 systems are affected. ARM systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests cannot leverage the vulnerability. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa242.patch xen-unstable xsa242-4.9.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa242* 168db3aef00806025afa255dee35cd0c042706a27a0256744e4d63f3ee86a2e8 xsa242.meta 16848f71311c2fd6a38afd7602e59211c89a3daf29b874097dba0b1e31ba6eec xsa242.patch 5e66b6b1d1cd400905d3abd3478144539c3afa24f5a744a11809d9c5eb517b98 xsa242-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ31wBAAoJEIP+FMlX6CvZs4YH+QH5lTpge4JLyHQRJbLry52Z 70oB+1vZIsoWg9/XONE9/l1kei0WOGPh4Pt2AWUZOXy8I/euHlMUeGZchl7cQ73M 6EOPjQ1+EXv+vIePwyjZiZmjKQJYQDZ5IsNZ3lz2oV27SkppSW6KKPFlj9G3Dc+E Fv0JwawHNBruGQu9RYWukLbCKn9g4Z0OD/4OwpzF0PY3c/zqk9aYjg318i2Na5zu tWDI9+srfzgvT9N2+om/hVBQYHp48OOIUIGtMz7M4A33LBySsETigpBaCiNmyNeG +l3ONWKF8XNeJbpYGtd3jClgXLg8Hy5MgalSCKOyB2XAgl0y2BSX3tyhOnQZKcs= =tqOh -END PGP SIGNATURE- xsa242.meta Description: Binary data xsa242.patch Description: Binary data xsa242-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 243 - x86: Incorrect handling of self-linear shadow mappings with translated guests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-243
version 3
x86: Incorrect handling of self-linear shadow mappings with translated guests
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
The shadow pagetable code uses linear mappings to inspect and modify the
shadow pagetables. A linear mapping which points back to itself is known as
self-linear. For translated guests, the shadow linear mappings (being in a
separate address space) are not intended to be self-linear. For
non-translated guests, the shadow linear mappings (being the same
address space) are intended to be self-linear.
When constructing a monitor pagetable for Xen to run on a vcpu with, the shadow
linear slot is filled with a self-linear mapping, and for translated guests,
shortly thereafter replaced with a non-self-linear mapping, when the guest's
%cr3 is shadowed.
However when writeable heuristics are used, the shadow mappings are used as
part of shadowing %cr3, causing the heuristics to be applied to Xen's
pagetables, not the guest shadow pagetables.
While investigating, it was also identified that PV auto-translate mode was
insecure. This mode was removed in Xen 4.7 due to being unused, unmaintained
and presumed broken. We are not aware of any guest implementation of PV
auto-translate mode.
IMPACT
==
A malicious or buggy HVM guest may cause a hypervisor crash, resulting in a
Denial of Service (DoS) affecting the entire host, or cause hypervisor memory
corruption. We cannot rule out a guest being able to escalate its privilege.
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
HVM guests using shadow mode paging can exploit this vulnerability.
HVM guests using Hardware Assisted Paging (HAP) as well as PV guests
cannot exploit this vulnerability.
ARM systems are not vulnerable.
MITIGATION
==
Running only PV guests will avoid this vulnerability.
Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests. HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa243.patch xen-unstable, Xen 4.9.x
xsa243-4.8.patch Xen 4.8.x
xsa243-4.7.patch Xen 4.7.x
xsa243-4.6-[1,2].patch Xen 4.6.x
xsa243-4.{6-1,5-2}.patch Xen 4.5.x
$ sha256sum xsa243*
61b05e2d6655f5d18cd53b16e03499152c603162584f64d68fad31b088cc5cd2 xsa243.meta
a5b484db80346f7e75c7921ee4780567f04b9f9b4620c0cde4bfa1df3ac0f87f xsa243.patch
79e1c5e088eee8e78aa67895a29d611352c64251854e4c5129e33c85988a47a5
xsa243-4.5-2.patch
722073aad1e734e24b0b79d03a1957e491f3616fe6e244a89050f7a50f8f356b
xsa243-4.6-1.patch
94cb346c486f88f2f4f701564017e1997e518a5a14218f0e38ff882c60fb382c
xsa243-4.6-2.patch
465ba9e3293591a3c84c122ffd73474fe96483f5e21565440d5fbc207fa4c4a9
xsa243-4.7.patch
f8e471b42502905a442d43934ac339663a6124118c9762b31f2ad930fd532e64
xsa243-4.8.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZ31wCAAoJEIP+FMlX6CvZfZIH/i6Ict2HQ3HPT8yLY6e+Lab4
XXRUutCRqiBYoxes4vsOs8SqVEBQ/AI/Ds5jpByNQqUrK/dH7CdTOthy3bsOSmHQ
UcUveuMyJ7IDCjJhFYmIA6o7Bc1OiBDoA3yg1pFn4tb1eAn/3mq4OCSNhqnCPiFy
MxnsQ023yCLUdHwPvNagLOwycOelD1CdZQPae8e1fuasABJfuTZ+MdREMcsJWfOo
rcH5++We9yWKttJqV9om7NsyEBdiQYRJHepJb0dJwm+ZMp46A5NaqNd6/PpFmoP9
L7sgweOd/Z2taJOrDiSTAuaoKuxA0sZstUaE+BCb7Xp2aqFmnSp85gsaqdvAkCs=
=ktEr
-END PGP SIGNATURE-
xsa243.meta
Description: Binary data
xsa243.patch
Description: Binary data
xsa243-4.5-2.patch
Description: Binary data
xsa243-4.6-1.patch
Description: Binary data
xsa243-4.6-2.patch
Description:
[Xen-devel] Xen Security Advisory 244 - x86: Incorrect handling of IST settings during CPU hotplug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-244 version 2 x86: Incorrect handling of IST settings during CPU hotplug UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = The x86-64 architecture allows interrupts to be run on distinct stacks. The choice of stack is encoded in a field of the corresponding interrupt descriptor in the Interrupt Descriptor Table (IDT). That field selects an entry from the active Task State Segment (TSS). Since, on AMD hardware, Xen switches to an HVM guest's TSS before actually entering the guest, with the Global Interrupt Flag still set, the selectors in the IDT entry are switched when guest context is loaded/unloaded. When a new CPU is brought online, its IDT is copied from CPU0's IDT, including those selector fields. If CPU0 happens at that moment to be in HVM context, wrong values for those IDT fields would be installed for the new CPU. If the first guest vCPU to be run on that CPU belongs to a PV guest, it will then have the ability to escalate its privilege or crash the hypervisor. IMPACT == A malicious or buggy x86 PV guest could escalate its privileges or crash the hypervisor. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only PV guests can exploit the vulnerability. HVM guests cannot exploit the vulnerability, but their presence is necessary for the exposure of the vulnerability to PV guests. Only x86 systems using SVM (AMD virtualisation extensions) rather than VMX (Intel virtualisation extensions) are vulnerable. Therefore AMD x86 hardware is vulnerable; Intel hardware is not vulnerable. ARM systems are not vulnerable. MITIGATION == Avoiding to online CPUs at runtime will avoid this vulnerability. Running only HVM or only PV guests on any individual host will also avoid this vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa244.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa244-4.7.patch Xen 4.7.x xsa244-4.6.patch Xen 4.6.x xsa244-4.5.patch Xen 4.5.x $ sha256sum xsa244* 5b663620a1b0d5f07e7ae4d1d3506d925515d5f85830ca49dda75cab1218506f xsa244.meta bcf22b332bf3f6fe8c86e4de67f82628c9b8e257d9513c3bf5c7f5dd71d86c33 xsa244.patch 4c4543fdfd25b4a8ea7d53f3f45011ec137798e7d4e690d8f3ea58d77afb5f06 xsa244-4.5.patch eaa3ba303980d783813db7aee948a9cb2723328da5fa5650ffca7b825c21bab6 xsa244-4.6.patch 4d8cf754f760ef05488e9fb25a7ebd9a7e46f3742e91eee1a8385fd1e611ea8c xsa244-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ31wEAAoJEIP+FMlX6CvZixEIALXqWn6ShR2MCMeiGHy1ewsX S80m2OFqHYgZuawTuA3TN3mYfQONLNpobpchU5Y/RoWxS70sfV5PqLf6IHYPlSSC 3VI+U+Q3nhPhudQo4RFkyFeDGg6dKEnver+Bfik1pHsTBB0o0ojAdgqbW+K4HEoE flqPaXuQSFSFE5mYzQ+UxI7nE9I7IwDRD+eDSE/JRtTmXuoJPB8bC4De68dM4BbM +nfaNR95PvyNTToKluYdcST7pq/jRal5/O8GSxNsolgcd6C4IZrX1wB2ibMoa1wh ElLmcw/gyT/DfvO0STjvVQ/Ryaoj3ZLjMrNRt7pA8IQ1gig312f7vCGpF0/EeYM= =9+du -END PGP SIGNATURE- xsa244.meta Description: Binary data xsa244.patch Description: Binary data xsa244-4.5.patch Description: Binary data xsa244-4.6.patch Description: Binary data xsa244-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 241 - Stale TLB entry due to page type release race
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-241 version 3 Stale TLB entry due to page type release race UPDATES IN VERSION 3 Fix ARM build issue in patches. Public release. ISSUE DESCRIPTION = x86 PV guests effect TLB flushes by way of a hypercall. Xen tries to reduce the number of TLB flushes by delaying them as much as possible. When the last type reference of a page is dropped, the need for a TLB flush (before the page is re-used) is recorded. If a guest TLB flush request involves an Inter Processor Interrupt (IPI) to a CPU in which is the process of dropping the last type reference of some page, and if that IPI arrives at exactly the right instruction boundary, a stale time stamp may be recorded, possibly resulting in the later omission of the necessary TLB flush for that page. IMPACT == A malicious x86 PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions from at least 3.2 onwards are vulnerable. Earlier versions have not been checked. Only x86 systems are affected. ARM systems are not affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests cannot leverage the vulnerability. RISK ASSESSMENT === A successful attack would require introducing an extended delay between two adjacent operations on one cpu -- long enough for two hypercalls to complete on another cpu. The security team currently has no proof-of-concept for this vulnerability. However, techniques for these sorts of timing-based attacks are continually advancing, so we still recommend users potentially affected by this issue apply the patch as soon as reasonably possible. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa241.patch xen-unstable xsa241-4.9.patch Xen 4.9.x xsa241-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa241* 5e239ba4dbd74fd61e59a27f9abc8ea6ba32532bdf81eeb2d7e66f0fd53e40b4 xsa241.meta b8db933d53e7e289652ffda6c46ce284a0254a9f8bc9e1be6793e388009f49ce xsa241.patch 443a5b0818045ada44fad0370ac01af0c96181be5a4078ae3b2575799e4a4e5b xsa241-4.8.patch 927ef14d875556481c38d4065f501211a78eec1c2396a954a4a4abfb9255960f xsa241-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ31v/AAoJEIP+FMlX6CvZsNgIALcJ/DeUN5nv8duBvC3hbAX6 NABBtlVJ6K7qZpAf+04Eztym4bEWXWGtJ1BQVCJ6aPwPZ4aOUodA/zRBEQS7Xp8F 5P5U3Qwa/C+slqLh7QfYdwlkgdMRG67yWIo2xMOEcfORlPjc1wDxohtCQZT9uiMs Y9Xllt/sLhGgYq4+TpNvJyYMzvPp1+oBEuqcR58IZ2aepQJAlPl3LnLdYyN8TAqv MBmli7cRO/vYn5z7aII9NbuF8XEnx0Vfqp7EufLU1LQyG4S9jYXd0xvD6BjjkGWM N/dvJTMq8HXS00VUAoONOv+blq2AdRs9oYD8yeMCglUhpeK8cIaEsYzhOHbCvlI= =1uZK -END PGP SIGNATURE- xsa241.meta Description: Binary data xsa241.patch Description: Binary data xsa241-4.8.patch Description: Binary data xsa241-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 239 - hypervisor stack leak in x86 I/O intercept code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-239 version 2 hypervisor stack leak in x86 I/O intercept code UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Intercepted I/O operations may deal with less than a full machine word's worth of data. While read paths had been the subject of earlier XSAs (and hence have been fixed), at least one write path was found where the data stored into an internal structure could contain bits from an uninitialized hypervisor stack slot. A subsequent emulated read would then be able to retrieve these bits. IMPACT == A malicious unprivileged x86 HVM guest may be able to obtain sensitive information from the host or other guests. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not affected. Only HVM guests can leverage this vulnerability. PV guests cannot leverage this vulnerability. MITIGATION == Running only PV guests will avoid this issue. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa239.patch xen-unstable, Xen 4.9.x, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa239-4.5.patch Xen 4.5.x $ sha256sum xsa239* eb7971be89199eb3ff510f4f5650fd5a8ec588b9fcb8f89230216fac4214ef21 xsa239.meta 087a8b3cf7ecbdbde593033c127cbcf6c37f532bf33d90f72c19e493970a799c xsa239.patch b91a68fe67240f2a5bb9460c5b650e9595364afa180f8702aef783815e3d7dcd xsa239-4.5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZ31v8AAoJEIP+FMlX6CvZ1AQIAMmN4FghnJvlec7xsPQBgPBs nlOItkaXMYZnIajohG2/U5zfFU02oj0GmCz4CDODaKiaZem2p69LzVeVOkqAqQ4p osYMy918GROxrvfHo+36gCBDfwlB7TWr6dQzM50nHh+6O1l1+QlpCw3k+gb5CnNT Rkn/V1ZZGVy7ycwGiMK1mP0C9hsGyuC5xxwCR9XxK01X0x+NTEXZWAS+GbPHBJAS HyopB9W+PkQ0qL/j7VjfGdUWTGquBPffnDGQFBN7CqQ+Pt6Mpv4RvkHiS3NTP5qd 8rp5M0xjVBnpCC/JAQXL9oLK+LZf99oIal1zbQ1FrECYFXIIyf/hUMxguBbsON4= =8UQF -END PGP SIGNATURE- xsa239.meta Description: Binary data xsa239.patch Description: Binary data xsa239-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 245 - ARM: Some memory not scrubbed at boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-245 ARM: Some memory not scrubbed at boot NOTE REGARDING LACK OF EMBARGO == This bug was discussed publicly before it was realised that it was a security vulnerability. ISSUE DESCRIPTION = Data can remain readable in DRAM across soft and even hard reboots. To ensure that sensitive data is not leaked from one domain to another after a reboot, Xen must "scrub" all memory on boot (write it with zeroes). Unfortunately, it was discovered that when memory was in disjoint blocks, or when the first block didn't begin at physical address 0, arithmetic errors meant that some memory was not scrubbed. IMPACT == Sensitive information from one domain before a reboot might be visible to another domain after a reboot. VULNERABLE SYSTEMS == Only ARM systems are vulnerable. All versions of Xen since 4.5 are vulnerable. Only hardware with disjoint blocks, or physical addresses not starting at 0 are vulnerable; this includes the majority of ARM systems. MITIGATION == None. RESOLUTION == Applying the appropriate attached patches resolves this issue. xsa245/*.patch All versions of Xen $ sha256sum xsa245* xsa245*/* 121829263b85fcb5eac8e38fb44e77d3aab1dd7ae6ef665bf84bb49e5e161d24 xsa245.meta 526f9e1b127fbb316762ce8e8f4563bc9de0c55a1db581456a3017d570d35bdd xsa245/0001-xen-page_alloc-Cover-memory-unreserved-after-boot-in.patch 7164010112fcccd9cd88e72ace2eeabdb364dd6f4d05c434686267d18067f420 xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZzTANAAoJEIP+FMlX6CvZHk4IAJpF4ruPkFKdCgsQ/ljjrpxO 8CVQFVwxTLtLZGUB1ZP0nFntkT/FnhDo870EmDvjPZTq3MmQwlPwVhgPqmF+tsTC aMecUftEJxHm6cSRLYiIGEphGbJZR6utjTKd7l0ddni5QtnzUED8mE5WFAq4aLrS y8FHuyghE6nwBXEMhRiDYYZ2X0MeMeTisc/0s1Loe002zcpw0RUlmys21Uzzd1Xv t4n5e4RDMLUNpfpY3o4UVWcJJi55Bpxw9ke4IMExlNSbYR5qQeNigDT0CcE1bv6n mNwlADAUKT4t/K1fyk6XJLFIdzHt5NVmN2O9cYKt6voVMu1r1dh3TgiAffAJsxk= =Pi1Y -END PGP SIGNATURE- xsa245.meta Description: Binary data xsa245/0001-xen-page_alloc-Cover-memory-unreserved-after-boot-in.patch Description: Binary data xsa245/0002-xen-arm-Correctly-report-the-memory-region-in-the-du.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 232 (CVE-2017-14318) - Missing check for grant table
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-14318 / XSA-232 version 4 Missing check for grant table UPDATES IN VERSION 4 Added metadata file Public release. ISSUE DESCRIPTION = The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant table operations. It checks to see if the calling domain is the owner of the page that is to be operated on. If it is not, the owner's grant table is checked to see if a grant mapping to the calling domain exists for the page in question. However, the function does not check to see if the owning domain actually has a grant table or not. Some special domains, such as `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant tables. Hence, if __gnttab_cache_flush operates on a page owned by these special domains, it will attempt to dereference a null pointer in the domain struct. IMPACT == The guest can get Xen to dereference a NULL pointer. For ARM guests and x86 PV guests on systems with SMAP enabled, this will cause a host crash (denial-of-service). For x86 PV guests on systems without SMAP enabled, an attacker can map a crafted grant structure at virtual address 0. This can be leveraged to increment an arbitrary virtual address, which can then probably be leveraged into a full privilege escalation. VULNERABLE SYSTEMS == All versions of Xen since Xen 4.5 are vulnerable. x86 HVM guests do not expose the vulnerability. ARM guests and x86 PV guests on systems with SMAP enabled are only vulnerable to a Denial-of-Service (host crash). x86 PV guests on systems without SMAP running are vulnerable to a privilege escalation. MITIGATION == Hardware supporting Supervisor Mode Access Prevention (Intel Broadwell, AMD Zen) can mitigate the privilege escalation to a DoS. CREDITS === This issue was discovered by Matthew Daley. RESOLUTION == Applying the attached patch resolves this issue. xsa232.patch xen-unstable, 4.9, 4.8, 4.7, 4.6, 4.5 $ sha256sum xsa232* b193a711d013fe14556610ef3e703585164fdfc437c3a32a717c419e7a5afab2 xsa232.meta 5068a78293daa58557c30c95141b775becfb650de6a5eda0d82a4a321ced551c xsa232.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZt80FAAoJEIP+FMlX6CvZjCcH/0arWvHYjB/Zrnu9dMEjbfW8 ydFwwHm0foHY7ALp/RDazJjsNBDyt7iol0Z1Kv5wgxt+iLvgCuqVokkg80eoI6ku TYkytzWsZOw1NOJQJ2nH7v5kW76qXceMAByrWZOm09xfFQ2hhGthz8IMwfyAhWc/ GtbsK4K3k2hEp2Uh1yhvT0m2pKvB1190MfNzsKeYIoAlYnDKQu1BB93NTkIlKypz TgVfvm/1M6F/nnsekipFbGJ6/v7TEi0YqSm6uOudlbUSj0DTZYU5smBizfGwA8Ih D5ROdlqfRsXsXiUdu/HAT/IB9r9knZpicQQPPmwYPhyB+Fn8UCQei3Z+pRYzGYI= =aOmL -END PGP SIGNATURE- xsa232.meta Description: Binary data xsa232.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 234 (CVE-2017-14319) - insufficient grant unmapping checks for x86 PV guests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-14319 / XSA-234 version 3 insufficient grant unmapping checks for x86 PV guests UPDATES IN VERSION 3 Added metadata file Public release. ISSUE DESCRIPTION = When removing or replacing a grant mapping, the x86 PV specific path needs to make sure page table entries remain in sync with other accounting done. Although the identity of the page frame was validated correctly, neither the presence of the mapping nor page writability were taken into account. IMPACT == A malicious or buggy x86 PV guest could escalate its privileges or crash the hypervisor. VULNERABLE SYSTEMS == All Xen versions are affected. Only x86 PV guests can leverage the vulnerability. x86 HVM guests as well as ARM guests cannot leverage the vulnerability. MITIGATION == Running only HVM guests will avoid this vulnerability. However, the vulnerability is exposed to PV stub qemu serving as the device model for HVM guests. Our default assumption is that an HVM guest has compromised its PV stub qemu. By extension, it is likely that the vulnerability is exposed to HVM guests which are served by a PV stub qemu. For PV guests, the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa234.patch xen-unstable xsa234-4.9.patch Xen 4.9.x xsa234-4.8.patch Xen 4.8.x, Xen 4.7.x xsa234-4.6.patch Xen 4.6.x xsa234-4.5.patch Xen 4.5.x $ sha256sum xsa234* efbcc7eac0f010281c5651d191076ac08cc7dd22a1945e88e92ba8a03ae8cc40 xsa234.meta 08ffa79e5c2a77db0b91b3bfcf9fa5c50f174fe842b7418e2e1549d47e0aec4d xsa234.patch 4b74f3c85a98bc6f40c6a448b068bf45e71f7cce887b7cb1481aca0e8746d990 xsa234-4.5.patch 3df4ce173196111c1ff849039ea4927c0b4bd632b08a501fb26f64e31b951fba xsa234-4.6.patch 169e4e0eaa6b27e58ff0f4ce50e8fcc3f81b1e0a10210decf22d1b4cac7501fb xsa234-4.8.patch 213f9d81a4ab785db67b9f579c9e88c9c8586c46b93f466a309060750df2df32 xsa234-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZt80HAAoJEIP+FMlX6CvZBCsH/1ghPnUr7fpKSgd7huB5gtGC +QsoqJlmI8U+eWqmS8RlAZ0f5A2Umy7GyYDWqFbvJR2o60AMf7DI9d1QVHQYRSfD JFw+M4ohZ/gZoHykof929QYY15Fhrnt5PoMJ6ztt3ZsBXYkXTJfyvHwVjCD43Nvt fANPcYOpm8NneV9mAviVEjR3u08ultjcfq0Gdks22L5zWKzG38j/rbBtA75mx5eT v/eYXEqrSgXEfI2zJOP/j53D2CwMJnmbbsxgQTvAalSLq1zqNrXFSHEkfyqi+Aix QReMmubpNVbIv1ybtZsE1tRMgBY7VJBJEbT5/PrOUErb9XMoL0wtMwP+kHuVD2w= =qFgP -END PGP SIGNATURE- xsa234.meta Description: Binary data xsa234.patch Description: Binary data xsa234-4.5.patch Description: Binary data xsa234-4.6.patch Description: Binary data xsa234-4.8.patch Description: Binary data xsa234-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 231 (CVE-2017-14316) - Missing NUMA node parameter verification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-14316 / XSA-231 version 3 Missing NUMA node parameter verification UPDATES IN VERSION 3 Updated metadata file Public release. ISSUE DESCRIPTION = The function `alloc_heap_pages` allows callers to specify the first NUMA node that should be used for allocations through the `memflags` parameter; the node is extracted using the `MEMF_get_node` macro. While the function checks to see if the special constant `NUMA_NO_NODE` is specified, it otherwise does not handle the case where `node >= MAX_NUMNODES`. This allows an out-of-bounds access to an internal array. IMPACT == An attacker using crafted hypercalls can execute arbitrary code within Xen. VULNERABLE SYSTEMS == All versions of Xen are affected. Both ARM and x86 are affected. Both systems running HVM guests and system running PV guests are affected. MITIGATION == No known mitigation. CREDITS === This issue was discovered by Matthew Daley. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa231.patch xen-unstable xsa231-4.9.patch Xen 4.9, Xen 4.8 xsa231-4.7.patch Xen 4.7, Xen 4.6 xsa231-4.5.patch Xen 4.5 $ sha256sum xsa231* 4255d2bc4ca668e7abcbf8256b0a8f21acef2a47a06d626aad6d22c685034587 xsa231.meta b72af3fb8c44925ea7973533e8a8701becfc194f3e1c97f12af0392e1edd16a3 xsa231.patch d9853b2d2649679d8810bd7e93f7b51bd9fefb3472da60ae464bde88aae3389c xsa231-4.5.patch ce29b56a0480f4835b37835b351e704d204bb0ccd22325f487127aa2776cc2cf xsa231-4.7.patch 71a53a5133c8d4e381dd0e3e54205d31dea545ab62b261084dd3aea140f88cad xsa231-4.9.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZt80DAAoJEIP+FMlX6CvZrooIALgotDR4DC367J1SF87V2dHW Wo2O05rF8uBl12ofMA4LirjPfbNq49ZikaDr01jq+srFZLDw72IzgjbNJOwThkZt DHFR12LABvAPHT/Je58vGqS24HKKhK1o+Q0vDcbZHzBGXkj6gwxNC+DJAzF9D9Ye qXtZv4GmkmhFs0nQuzUF8bLu7ZvIQjB7QVoXnOvynx/mpCI9GPvoRGLptIJhbc8A CqSLsgF+7cXC6E8u/pp9XorpsQf2ekQwJMkLiG3UXieeShwrmY1mCE/vWBgsFeyj k7/+dQhj6X+7vwLA385Df3cF7hDjDi23AJMUN1AuVd9fx9/ie4o+9nJIa0FpUOA= =al8X -END PGP SIGNATURE- xsa231.meta Description: Binary data xsa231.patch Description: Binary data xsa231-4.5.patch Description: Binary data xsa231-4.7.patch Description: Binary data xsa231-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 233 (CVE-2017-14317) - cxenstored: Race in domain cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-14317 / XSA-233
version 3
cxenstored: Race in domain cleanup
UPDATES IN VERSION 3
Added metadata file
Public release.
ISSUE DESCRIPTION
=
When shutting down a VM with a stubdomain, a race in cxenstored may
cause a double-free.
IMPACT
==
The xenstored daemon may crash, resulting in a DoS of any parts of the
system relying on it (including domain creation / destruction,
ballooning, device changes, etc).
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
Only systems running the C version os xenstored ("xenstored") are
vulnerable; systems running the Ocaml version ("oxenstored") are not
vulnerable.
Only systems running devicemodel stubdomains are vulnerable. Only x86
HVM guests can use stubdomains. Therefore ARM systems, x86 systems
running only PV guests, and x86 systems running HVM guests with the
devicemodel not in a stubdomain (eg in dom0), are not vulnerable.
MITIGATION
==
Running oxenstored will mitigate this issue. Not using stubdomains
will also mitigate the issue.
CREDITS
===
This issue was discovered by Eric Chanudet of AIS.
RESOLUTION
==
Applying the attached patch resolves this issue.
xsa233.patch xen-unstable, Xen 4.9.x Xen 4.8.x Xen 4.7.x Xen 4.6.x Xen 4.5.x
$ sha256sum xsa233*
66b6f6c0837a5d12a77db7e5cbfd0514968bd47e2d192824da3bc9ddf119bfe0 xsa233.meta
f721cc49ba692b2f36299b631451f51d7340b8b4732f74c98f01cb7a80d8662b xsa233.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZt80GAAoJEIP+FMlX6CvZVO8IALTEAV/xiPTN1uUPISLQYLmX
6Bu80yrD+5UjVVI01FrkeUfNJBABmxf5q6sTOFeuYctwY6iPMJI46jHda8ugew5j
wnOgtgat0lfQT1/E/C8SsGEHeTULXPHVOaaXRQT55ExhVvEhLvSQV5vd6YNituyq
ow3hYrK3crK3uCOdLyZlxbuHXMFyLIbpoTYnRgXzV/3uLOB5TPsoRzKf4E+Z1Muo
chQXk8OQG+CEYupf00+H/QTvrDLSnf4KT4t4rZXDqUd39QoxV1l9s0daLyMjyJg/
Lu5t1WmcmarZvYICJhWf3Vi2NpaNTyQEeepwUM/XHe+vgHJXzesWyuRoLApmEfE=
=trYV
-END PGP SIGNATURE-
xsa233.meta
Description: Binary data
xsa233.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 226 (CVE-2017-12135) - multiple problems with transitive grants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-12135 / XSA-226 version 7 multiple problems with transitive grants UPDATES IN VERSION 7 First patch provided in version 6 regressed 32-bit Dom0 or backend domains. The updated patch includes a fix for this. ISSUE DESCRIPTION = 1) Code to handle copy operations on transitive grants has built in retry logic, involving a function reinvoking itself with unchanged parameters. Such use assumes that the compiler would also translate this to a so called "tail call" when generating machine code. Empirically, this is not commonly the case, allowing for theoretically unbounded nesting of such function calls. 2) The reference counting and locking discipline for transitive grants is broken. Concurrent use of the transitive grant can leak references on the transitively-referenced grant. IMPACT == A malicious or buggy guest may be able to crash Xen. Privilege escalation and information leaks cannot be ruled out. A malicious or buggy guest can leak references on grants it has been given, amounting to a DoS against the grantee. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jan Beulich of SUSE. The security team would also like to thank Amazon for helping to identify that the problems with transitive grants were deeper than originally believed. RESOLUTION == Applying the appropriate attached pair of patches from the list below addresses this issue: xsa226-unstable/*.patch xen-unstable xsa226-4.9/*.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa226-4.6/*.patch Xen 4.6.x xsa226-4.5/*.patch Xen 4.5.x Note that these patches have already been applied to the respective staging trees. Alternatively, applying the appropriate attached patch from the list below works around this issue by disabling transitive grants by default: xsa226.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa226-4.7.patch Xen 4.7.x xsa226-4.6.patch Xen 4.6.x xsa226-4.5.patch Xen 4.5.x $ sha256sum xsa226* xsa226*/* b09e07aaf422ae04a4ece5e2c5b5e54036cfae5b5c632bfc6953a0cacd6f60ff xsa226.patch d999767014501d3ac62def06ccd43b97bbbf0ef7d402d3bd70ca96ac9997a14d xsa226-unstable/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch 4473fd96ce4fdea5e19e0b502d65f20bd279d82473ac34ff404ce2b2cbc10be1 xsa226-unstable/0002-gnttab-fix-transitive-grant-handling.patch ca8b92b2ff58b87e8bec137a34784cbf11e2820659046df6e1d71e23bf7e7dee xsa226-4.5.patch ca77d01172abf263b5b731f26f5e3f74b0b8c75b3e29bee3f65a9318236daba7 xsa226-4.5/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch de6359e50fd2bb710469da74a596013ce275edb43d3d1c36d41452f88eee9b7d xsa226-4.5/0002-gnttab-fix-transitive-grant-handling.patch 28c7df7edabb91fb2f1fa3fc7d6906bfae75a6e701f1cd335baafaae3e087696 xsa226-4.6.patch 0186f78e99f5f6eec913da8355e0c28946a14a6099a7219bd4e0d385fdf8c306 xsa226-4.6/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch e34dbba7b94942faeb3e6b7630ba06f01998e2b56be1035d76e67aa47e77457d xsa226-4.6/0002-gnttab-fix-transitive-grant-handling.patch fffcc0a4428723e6aea391ff4f1d27326b5a3763d2308cbde64e6a786502c702 xsa226-4.7.patch 3878c27b77ba24012599289e0e0fb1e5198b1e4efe2f87f7c46def5f335f2fd5 xsa226-4.9/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch 01d773c5bb4cafe54daf0d14e8a3af899a7c5863513d18927c4a570a74afdb15 xsa226-4.9/0002-gnttab-fix-transitive-grant-handling.patch $ (The .meta file is a prototype machine-readable file for describing which patches are to be applied how.) DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZpVgpAAoJEIP+FMlX6CvZ228H/jXq5lHGZwtGmbgFY1O6/LBk wrExcAq5iSXVHmfXCR1budkAEYxqCptAbO6FNljvfZVu1bMnGq/ONJs6+UUMCcLb
[Xen-devel] Xen Security Advisory 235 - add-to-physmap error paths fail to release lock on ARM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-235 add-to-physmap error paths fail to release lock on ARM ISSUE DESCRIPTION = When dealing with the grant map space of add-to-physmap operations, ARM specific code recognizes a number of error conditions, but fails to release a lock being held on the respective exit paths. IMPACT == A malicious guest administrator can cause a denial of service. Specifically, prevent use of a physical CPU for an indefinite period of time. VULNERABLE SYSTEMS == Xen versions 4.4 and later are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only ARM systems are affected. X86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which only issue sane hypercalls will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Wei Liu of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa235.patch xen-unstable xsa235-4.9.patch Xen 4.9.x, Xen 4.8.x xsa235-4.7.patch Xen 4.7.x xsa235-4.6.patch Xen 4.6.x xsa235-4.5.patch Xen 4.5.x $ sha256sum xsa235* 6ec8bf9462de65fee3896246f52c00941b2d83c759b3f7b28a440eb977fcbc37 xsa235.meta c81f534e96fe38b9f77794bb143d104d66ce2d7177bda43f872642616e23df65 xsa235.patch 3c21cb1a53f5979b069568c6cd6df3aad00c19e0e459e37625d6a3c0f4f360cc xsa235-4.5.patch 47cda4f32b65f3543af368c324a2e5b308b698a1c7d8bc84fc274eb2cdb45c0e xsa235-4.6.patch f30848eee71e66687b421b87be1d8e3f454c0eb395422546c62a689153d1e31c xsa235-4.7.patch d8f012734fbf6019c1ff864744e308c41dfb9c7804ca3be2771c2c972cdf4bd5 xsa235-4.9.patch $ NOTE REGARDING LACK OF EMBARGO == The issue was discussed publicly before being recognized as a security issue. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZnZxeAAoJEIP+FMlX6CvZTj4IALE9/7IoG1Ak/TZuHE4xRxZx Zd2APyf+lCNj3wwdFRGC/969ilQ9OjLlJ408RyY6bVpwfmsjJTZWnAcWuS/fIdhY niillD1sdP7Eg65JG8bxL2jCaISH7AJKSePoLuc8G55I7uuJYEnipyvDZuz6W+qy k03+Bbz+TwNezA4YoNFsSpRdX48iIevFy9AIhZmggLUqdgmTR1rygjW/bxanBX8z 2dSch8LMcsVArTmwE3NnxVSJC1/g3Tc07wll7LnB6npecbCmiMqk+rhPUFdHZXl7 pYZy+Qp7w5rqcd91cOuKQKml4O3lO9ajblfpqKmbH3+hnuDqEnVlHSvVNVGWyag= =mGPq -END PGP SIGNATURE- xsa235.meta Description: Binary data xsa235.patch Description: Binary data xsa235-4.5.patch Description: Binary data xsa235-4.6.patch Description: Binary data xsa235-4.7.patch Description: Binary data xsa235-4.9.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 226 (CVE-2017-12135) - multiple problems with transitive grants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-12135 / XSA-226 version 6 multiple problems with transitive grants UPDATES IN VERSION 6 Patches actually addressing the issue have become ready. ISSUE DESCRIPTION = 1) Code to handle copy operations on transitive grants has built in retry logic, involving a function reinvoking itself with unchanged parameters. Such use assumes that the compiler would also translate this to a so called "tail call" when generating machine code. Empirically, this is not commonly the case, allowing for theoretically unbounded nesting of such function calls. 2) The reference counting and locking discipline for transitive grants is broken. Concurrent use of the transitive grant can leak references on the transitively-referenced grant. IMPACT == A malicious or buggy guest may be able to crash Xen. Privilege escalation and information leaks cannot be ruled out. A malicious or buggy guest can leak references on grants it has been given, amounting to a DoS against the grantee. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jan Beulich of SUSE. The security team would also like to thank Amazon for helping to identify that the problems with transitive grants were deeper than originally believed. RESOLUTION == Applying the appropriate attached pair of patches from the list below addresses this issue: xsa226-unstable/*.patch xen-unstable xsa226-4.9/*.patch Xen 4.9.x, Xen 4.8.x, Xen 4.7.x xsa226-4.6/*.patch Xen 4.6.x xsa226-4.5/*.patch Xen 4.5.x Note that these patches have already been applied to the respective staging trees. Alternatively, applying the appropriate attached patch from the list below works around this issue by disabling transitive grants by default: xsa226.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa226-4.7.patch Xen 4.7.x xsa226-4.6.patch Xen 4.6.x xsa226-4.5.patch Xen 4.5.x $ sha256sum xsa226* xsa226*/* b09e07aaf422ae04a4ece5e2c5b5e54036cfae5b5c632bfc6953a0cacd6f60ff xsa226.patch 22913e87349e27bd9167d5dad2d6a449b3959516e34e78ca0ff822320c4b55da xsa226-unstable/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch 4473fd96ce4fdea5e19e0b502d65f20bd279d82473ac34ff404ce2b2cbc10be1 xsa226-unstable/0002-gnttab-fix-transitive-grant-handling.patch ca8b92b2ff58b87e8bec137a34784cbf11e2820659046df6e1d71e23bf7e7dee xsa226-4.5.patch 61096dca309f48d9e63e255a7bd76a3f5fbdd7ba1c42a3d0661f6f024b553fc7 xsa226-4.5/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch de6359e50fd2bb710469da74a596013ce275edb43d3d1c36d41452f88eee9b7d xsa226-4.5/0002-gnttab-fix-transitive-grant-handling.patch 28c7df7edabb91fb2f1fa3fc7d6906bfae75a6e701f1cd335baafaae3e087696 xsa226-4.6.patch 9f2fb6981206d39274331316cd9cd9ee73d5f610de4891f6d13181fee9bc0529 xsa226-4.6/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch e34dbba7b94942faeb3e6b7630ba06f01998e2b56be1035d76e67aa47e77457d xsa226-4.6/0002-gnttab-fix-transitive-grant-handling.patch fffcc0a4428723e6aea391ff4f1d27326b5a3763d2308cbde64e6a786502c702 xsa226-4.7.patch 624a5ba690de5de88b6fafd8429d025c013632755621f9f4e4c206e0f86419c3 xsa226-4.9/0001-gnttab-dont-use-possibly-unbounded-tail-calls.patch 01d773c5bb4cafe54daf0d14e8a3af899a7c5863513d18927c4a570a74afdb15 xsa226-4.9/0002-gnttab-fix-transitive-grant-handling.patch $ (The .meta file is a prototype machine-readable file for describing which patches are to be applied how.) DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZlaksAAoJEIP+FMlX6CvZzOQH/A3LxvExBgExoQJWM8VPVliF jV19jRvLSK8Z2Xql4UZ8tcihmZyaBKLtzEAeMosk2FOtDu+iIIkmtL+KHaDwNkBk ZEyTkWuGWPqe4G/2CNpsx31v25YYGxgQlqyUcpJ8ZK97QtHkTo0+6PtQZ9wR8vgr
[Xen-devel] Xen Security Advisory 230 (CVE-2017-12855) - grant_table: possibly premature clearing of GTF_writing / GTF_reading
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-12855 / XSA-230
version 3
grant_table: possibly premature clearing of GTF_writing / GTF_reading
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
guest that a grant is in use. A guest is expected not to modify the
grant details while it is in use, whereas the guest is free to
modify/reuse the grant entry when it is not in use.
Under some circumstances, Xen will clear the status bits too early,
incorrectly informing the guest that the grant is no longer in use.
IMPACT
==
A guest may prematurely believe that a granted frame is safely private
again, and reuse it in a way which contains sensitive information, while
the domain on the far end of the grant is still using the grant.
VULNERABLE SYSTEMS
==
All systems are vulnerable.
MITIGATION
==
There are no mitigations.
CREDITS
===
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa230.patch xen-unstable, 4.9, 4.8, 4.7, 4.6, 4.5
$ sha256sum xsa230*
912c24771dc9e9b305be630b7771505abb3db735564c5574fc30b58a5da0139e xsa230.meta
77a73f1c32d083e315ef0b1bbb119cb8840ceb5ada790cad76cbfb9116f725cc xsa230.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
NOTE REGARDING SHORT EMBARGO
This issue was discovered while investigating problems with the initial
version of XSA-226. Accordingly, XSA-230 is embargoed and the embargo
will end at the same time as that of XSA-226.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZkvttAAoJEIP+FMlX6CvZBX4H/j68Tf+YJYNV6coTx6/Ag0wo
WVRepDbj/WTfpY4lT3SL57dpyhnfDNUgUaMkNfEUU9GV9FGtYEChHtQ3kDh9PvVG
ifZgyHxJnRgZY3Mr12FcevyevyPpluMFHZ7RzCl6hVXgekd2+YZOnSbY/FYPhvuh
Chzv2HUUMY/5Yt3HkbTgez3vRIxQW74TjERIqGx6y0bD3z+NYmOtmzeYcyUGsUBL
sf+QnBH6/bjZjiycojK7LEb4u032Kgws0lXABIypql7D8YlVH75ZOxxWxV1TmerR
Alc71JR+22ze76Tz0C4b0rafNv3xmn3o/0qoGQWo+7/o01Eg6XHuN9nn78bz2tw=
=x4fa
-END PGP SIGNATURE-
xsa230.meta
Description: Binary data
xsa230.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 230 - grant_table: possibly premature clearing of GTF_writing / GTF_reading
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-230
version 2
grant_table: possibly premature clearing of GTF_writing / GTF_reading
UPDATES IN VERSION 2
Public release. (A CVE request for this issue is currently outstanding.)
ISSUE DESCRIPTION
=
Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
guest that a grant is in use. A guest is expected not to modify the
grant details while it is in use, whereas the guest is free to
modify/reuse the grant entry when it is not in use.
Under some circumstances, Xen will clear the status bits too early,
incorrectly informing the guest that the grant is no longer in use.
IMPACT
==
A guest may prematurely believe that a granted frame is safely private
again, and reuse it in a way which contains sensitive information, while
the domain on the far end of the grant is still using the grant.
VULNERABLE SYSTEMS
==
All systems are vulnerable.
MITIGATION
==
There are no mitigations.
CREDITS
===
This issue was discovered by Jan Beulich of SUSE.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa230.patch xen-unstable, 4.9, 4.8, 4.7, 4.6, 4.5
$ sha256sum xsa230*
912c24771dc9e9b305be630b7771505abb3db735564c5574fc30b58a5da0139e xsa230.meta
77a73f1c32d083e315ef0b1bbb119cb8840ceb5ada790cad76cbfb9116f725cc xsa230.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
NOTE REGARDING SHORT EMBARGO
This issue was discovered while investigating problems with the initial
version of XSA-226. Accordingly, XSA-230 is embargoed and the embargo
will end at the same time as that of XSA-226.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZkuNZAAoJEIP+FMlX6CvZ+UwH/AjbZSL+HVazwku2f5qtV4SK
tBO0oiA4+o4hC9N71jV2JroQub37zEKBahpVIe0YpZ7QmedNme9URTnndkI7J9xj
qarVafofxbtgqHA8Dqe8TcvOiU0PgmR3JgJYUbXIQYwsPRpJsCtTgWB/IOwYZlcM
FpQSdPhvfVUAONTcM8bGqqe8pww40kW61dvwu4qlqyA1W4nj+Et4Yu9yn+Ga5H94
E8BjHgVE26sh5Q4D8JL70IpgQeuHPQ3wgRvnmzQgnpc5192zUC9ybDC5j9L17O1r
ckJlbaSNKgEHrYhflog/Haa55ZfyiYJF67KIQAYcOa5em0jvgCr7zIzPUPprsT0=
=eYJA
-END PGP SIGNATURE-
xsa230.meta
Description: Binary data
xsa230.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 228 (CVE-2017-12136) - grant_table: Race conditions with maptrack free list handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-12136 / XSA-228
version 3
grant_table: Race conditions with maptrack free list handling
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
The grant table code in Xen has a bespoke semi-lockfree allocator for
recording grant mappings ("maptrack" entries). This allocator has a
race which allows the free list to be corrupted.
Specifically: the code for removing an entry from the free list, prior
to use, assumes (without locking) that if inspecting head item shows
that it is not the tail, it will continue to not be the tail of the
list if it is later found to be still the head and removed with
cmpxchg. But the entry might have been removed and replaced, with the
result that it might be the tail by then. (The invariants for the
semi-lockfree data structure were never formally documented.)
Additionally, a stolen entry is put on the free list with an incorrect
link field, which will very likely corrupt the list.
IMPACT
==
A malicious guest administrator can crash the host, and can probably
escalate their privilege to that of the host.
VULNERABLE SYSTEMS
==
Xen 4.6 and later are vulnerable.
Xen 4.5 and earlier are not vulnerable.
MITIGATION
==
There is no mitigation for this vulnerability.
CREDITS
===
This issue was discovered by Ian Jackson of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa228.patch xen-unstable, Xen 4.9.x
xsa228-4.8.patch Xen 4.8.x, Xen 4.7.x, Xen 4.6.x
$ sha256sum xsa228*
35a1a7f8905770fa64da0756fe3e0400bb8c28ecae0b7cf80e749cb7962018db xsa228.meta
1979e111442517891b483e316a15a760a4c992ac4440f95e361ff12f4bebff62 xsa228.patch
5a7416f15ac9cd7cace354b6102ff58199fe0581f65a36a36869650c71784e48
xsa228-4.8.patch
$
(The .meta file is a prototype machine-readable file for describing
which patches are to be applied how.)
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZkuNRAAoJEIP+FMlX6CvZRz4IAMnEQggvKPrt1zOC14JncQwG
7q6DRlwHcAYVxD8GEJATNV3uyDhEUiOK8A9WwDrR42FInLBHtNk1iMvJSWvBII5/
jr8OBRf8Ealv/G38jilKjX08aiYmOTnHFjMRGTT+Nw7JJImPJq3bqi+nSeiM1IDP
v3Z6m9YtmXOCUPq087OngfEqtR3gG3seEqC7bKQgSk9nAojtJiPVcpw4jm3p3rl5
FYsLMVdLLxhFtiMItcdHa38/JHzxynIaCMHz8K1M/uBSLe58g6KZRerIWWls99RE
Fyo5rKUQ/6HlDuJcHXcf3GHtzujSNxN3PRbtyUMNSOP9/LDgd6fHSJiEOd9fphw=
=hzXD
-END PGP SIGNATURE-
xsa228.meta
Description: Binary data
xsa228.patch
Description: Binary data
xsa228-4.8.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 227 (CVE-2017-12137) - x86: PV privilege escalation via map_grant_ref
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-12137 / XSA-227 version 3 x86: PV privilege escalation via map_grant_ref UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When mapping a grant reference, a guest must inform Xen of where it would like the grant mapped. For PV guests, this is done by nominating an existing linear address, or an L1 pagetable entry, to be altered. Neither of these PV paths check for alignment of the passed parameter. The linear address path suitably truncates the linear address when calculating the L1 entry to use, but the path which uses a directly nominated L1 entry performs no checks. This causes Xen to make an incorrectly-aligned update to a pagetable, which corrupts both the intended entry and the subsequent entry with values which are largely guest controlled. If the misaligned value crosses a page boundary, then an arbitrary other heap page is corrupted. IMPACT == A PV guest can elevate its privilege to that of the host. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Only x86 systems are vulnerable. Any system running untrusted PV guests is vulnerable. The vulnerability is exposed to PV stub qemu serving as the device model for HVM guests. Our default assumption is that an HVM guest has compromised its PV stub qemu. By extension, it is likely that the vulnerability is exposed to HVM guests which are served by a PV stub qemu. MITIGATION == Running only HVM guests, served by a dom0-based qemu, will avoid this vulnerability. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa227.patch xen-unstable, Xen 4.9.x, 4.8.x, 4.7.x xsa227-4.6.patch Xen 4.6.x xsa227-4.5.patch Xen 4.5.x $ sha256sum xsa227* c48cc3be47e81a4ceebcf60659b8755516c68916fc5150920ed42c6b61e3f219 xsa227.meta 9923a47e5f86949800887596f098954a08ef73a01d74b1dbe16cab2e6b1fabb2 xsa227.patch 6f83d0d9ff853192840d2b82d26d8fde21473bf4ac1441a153f3ee02efd1dd67 xsa227-4.5.patch 162b991b27b86f210089526a01cae715563d3a069c92f42538b423bba7709fcc xsa227-4.6.patch $ (The .meta file is a prototype machine-readable file for describing which patches are to be applied how.) DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZkuNOAAoJEIP+FMlX6CvZ9wsH/3/DA8EENxPdhgoNEihvHgPP rquggFGcmgiJZyuy6+e3PZKUwQmUcVdPuVE5h+8NWYRCTjxa15LC/auAmkMHP170 f7nkSA6oU0zT1mxxqWWjht+CCJ56dmpJN+WGXQMasVEO9PLYR7gOxf90rqDuzqE8 zcQA4OyIOpsEH4Y2k2hjYFeLleWSLZKSPAy8fupZv34FakZDDLgxPMdWSrYQX/pP r2QmLoVk4pSQYZzy5aAZWgLugR+ewOmgYTntzGYSEB2VqEgl6vtA8STVqB5WsYZ4 eumUUZRBUeo9n2U9TgWPmKr5JtvC9w2/cjV6HysO5vUwuLJUICX25O9BE3VnBs0= =ulEd -END PGP SIGNATURE- xsa227.meta Description: Binary data xsa227.patch Description: Binary data xsa227-4.5.patch Description: Binary data xsa227-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 226 (CVE-2017-12135) - multiple problems with transitive grants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-12135 / XSA-226 version 5 multiple problems with transitive grants UPDATES IN VERSION 5 Public release. ISSUE DESCRIPTION = 1) Code to handle copy operations on transitive grants has built in retry logic, involving a function reinvoking itself with unchanged parameters. Such use assumes that the compiler would also translate this to a so called "tail call" when generating machine code. Empirically, this is not commonly the case, allowing for theoretically unbounded nesting of such function calls. 2) The reference counting and locking discipline for transitive grants is broken. Concurrent use of the transitive grant can leak references on the transitively-referenced grant. IMPACT == A malicious or buggy guest may be able to crash Xen. Privilege escalation and information leaks cannot be ruled out. A malicious or buggy guest can leak references on grants it has been given, amounting to a DoS against the grantee. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jan Beulich of SUSE. The security team would also like to thank Amazon for helping to identify that the problems with transitive grants were deeper than originally believed. RESOLUTION == Applying the appropriate attached patch works around this issue by disabling transitive grants by default. xsa226.patch xen-unstable, Xen 4.9.x, Xen 4.8.x xsa226-4.7.patch Xen 4.7.x xsa226-4.6.patch Xen 4.6.x xsa226-4.5.patch Xen 4.5.x $ sha256sum xsa226* b09e07aaf422ae04a4ece5e2c5b5e54036cfae5b5c632bfc6953a0cacd6f60ff xsa226.patch ca8b92b2ff58b87e8bec137a34784cbf11e2820659046df6e1d71e23bf7e7dee xsa226-4.5.patch 28c7df7edabb91fb2f1fa3fc7d6906bfae75a6e701f1cd335baafaae3e087696 xsa226-4.6.patch fffcc0a4428723e6aea391ff4f1d27326b5a3763d2308cbde64e6a786502c702 xsa226-4.7.patch $ (The .meta file is a prototype machine-readable file for describing which patches are to be applied how.) DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZkuNKAAoJEIP+FMlX6CvZUHMIALQcTfo00unwBX9RO7lBy4na LSkFE9yaPtA/pg5RRGo7Nrwl2nIDRc6Xc0ZkhNm0rfi1gnR0htP3jyJXxkXv1sah jkBP0bZYfWDHRxSdVBbNNn8q0mhuanycFhVuEiu+vmTPKRUTyODkAdAoi/TkY9Iq XD24clIrjY2xIDO3pKbDTJUZ86rHD0nepHdnnvN2rywyBd2VkJfJWGavqHgs61XX j9jX0nI4Wcm4nQKx37MBUwwN3oYeEKrzYQY3+AGVKQEWuULP4sWRKhxZaqclCbfd Cx/9gACwPEORU6bRXE/vzlxn7Ks6yf2tqgNAGCTrZgwW8q3SFNASHzaAM3EXz3w= =VNkV -END PGP SIGNATURE- xsa226.patch Description: Binary data xsa226-4.5.patch Description: Binary data xsa226-4.6.patch Description: Binary data xsa226-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 229 (CVE-2017-12134) - linux: Fix Xen block IO merge-ability calculation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-12134 / XSA-229 version 3 linux: Fix Xen block IO merge-ability calculation UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The block layer in Linux may choose to merge adjacent block IO requests. When Linux is running as a Xen guest, the default merging algorithm is replaced with a Xen-specific one. When Linux is running as an x86 PV guest, some BIO's are erroneously merged, corrupting the data stream to/from the block device. This can result in incorrect access to an uncontrolled adjacent frame. IMPACT == A buggy or malicious guest can cause Linux to read or write incorrect memory when processing a block stream. This could leak information from other guests in the system or from Xen itself, or be used to DoS or escalate privilege within the system. VULNERABLE SYSTEMS == All x86 Xen systems using pvops Linux in a backend role (either as dom0, or as a disk device driver domain) are affected. This includes upstream Linux versions 2.6.37 and later. Systems using the older classic-linux fork are not affected. All PV x86 domains doing block IO on behalf of a guest, including dom0 and any PV driver domains, are vulnerable. (Any HVM driver domains running are not vulnerable.) This includes Xen vbd backends such as blkback, but also direct IO performed for the guest via eg qemu. ARM systems are not affected. The vulnerability is only exposed if the underlying block device has request merging enabled. See Mitigation. The vulnerability is only exposed to configurations which use grant mapping as a transport mechanism for the block data. Configurations which use exclusively grant copy are not vulnerable. MITIGATION == Disable bio merges on all relevant underlying backend block devices. For example, echo 2 > /sys/block/nvme0n1/queue/nomerges CREDITS === This issue was discovered by Jan H. Schönherr of Amazon. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa229.patch Linux $ sha256sum xsa229* 5f96c72c8c5a971d52f5540475a3fc6f4fef2071ec772ef21392fdc238eda858 xsa229.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZkuNWAAoJEIP+FMlX6CvZBt4H/3tpKPBmzTaI5yKPdBf6wU7L hjmKG6QROeWV+EX3wmmmRi+iG0M90hDYFCTmhdNY4sjCdDEFDMB1KM8XA/LwHlz2 3gX6TVKQ/cXQRJFhlWSZQUDDd5jPqZzDK7KnhS2DC+MjnKvnnuS6N2ibIfaHJmUG HL6VdS7GZ8Z434mgOZskWPFn5xeaWd1vXGV+GI9Ih2RRn/axe6l0RSzgDpfeGB3T hVRQdy9wW4aXrnnUXEuuz5JNlTU1fuGXGz7W5BDP8mu9l/dzmDye6NOgVqo5wAkz +l/fRbFrjdO9JnKDpASDjGuoOCZgkBBxmG2wUz8COi6JTA5X0IRysG5OMOYZ/KU= =lyzV -END PGP SIGNATURE- xsa229.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 218 (CVE-2017-10913, CVE-2017-10914) - Races in the grant table unmap code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10913,CVE-2017-10914 / XSA-218 version 5 Races in the grant table unmap code UPDATES IN VERSION 5 CVEs assigned. ISSUE DESCRIPTION = We have discovered two bugs in the code unmapping grant references. * When a grant had been mapped twice by a backend domain, and then unmapped by two concurrent unmap calls, the frontend may be informed that the page had no further mappings when the first call completed rather than when the second call completed. (CVE-2017-10913.) * A race triggerable by an unprivileged guest could cause a grant maptrack entry for grants to be "freed" twice. The ultimate effect of this would be for maptrack entries for a single domain to be re-used. (CVE-2017-10914.) IMPACT == For the first issue, for a short window of time, a malicious backend could still read and write memory that the frontend thought was its own again. Depending on the usage, this could be either an information leak, or a backend-to-frontend privilege escalation. The second issue is more difficult to analyze. It can probably cause reference counts to leak, preventing memory from being freed on domain destruction (denial-of-service), but information leakage or host privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Both ARM and x86 are vulnerable. On x86, systems with either PV or HVM guests are vulnerable. MITIGATION == None. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. xsa218-unstable/*.patchxen-unstable xsa218-4.8/*.patch Xen 4.8.x xsa218-4.7/*.patch Xen 4.7.x xsa218-4.6/*.patch Xen 4.6.x xsa218-4.5/*.patch Xen 4.5.x $ sha256sum xsa218*/* 6f5e588edb6d3f0a37b89235e95cdcc7ca73cdff236d86b65e6f608bd15b03ec xsa218-unstable/0001-gnttab-fix-unmap-pin-accounting-race.patch 5cb85f0aaa19ff343fc51b08addbf37d62352774115acd28eb18a73f67507e21 xsa218-unstable/0002-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch f5f3d27ce2829b3aa5e09b216bf9afcb1dc6b1f9f3b3a0f3ebfe5a68b4948aef xsa218-unstable/0003-gnttab-correct-maptrack-table-accesses.patch fafb8773957bbffb21ab43c7a3559efe15f52d234afba5f2ad2739411946c021 xsa218-4.5/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures.patch 4398ad7111421dbf954ede651cb7f9acd83c654c7fa93d54a4e5f9b7b25fe918 xsa218-4.5/0002-gnttab-fix-unmap-pin-accounting-race.patch 9d23946afb96a70c574b8c7ff42ed8b30b72e9a1f751ff617a7578c79645c094 xsa218-4.5/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch 27d92c6f4d89de3fd9e9311337823370303c1ef985cce2bd9bea28f00cd6c184 xsa218-4.5/0004-gnttab-correct-maptrack-table-accesses.patch 99ac090d7955a46c6c9c73ca62b64cef6b8f05439961e52278c662f030a36ee2 xsa218-4.6/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures.patch e0f0839336e055c1422cf0f76c37f6d9cc8474b0140ffef2451dca6697a9f20f xsa218-4.6/0002-gnttab-fix-unmap-pin-accounting-race.patch 5f6f63211b18bb6ec157353b9e8b844abe3fd767ef1780e6d28731e935559fbc xsa218-4.6/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch 6a786a8c4b916b6f99092598bd4d60381907cd7e728c98a79e999afeec4f45a6 xsa218-4.6/0004-gnttab-correct-maptrack-table-accesses.patch 58354eec5f4f0b87640c702c6e1ce0eeb57dffbd09394a96e88bd6ff42c53e7e xsa218-4.7/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures.patch 0683d7ffdbe60dc8e1d161adeb0c5465df1840e86353b5cbb96dd204f2dbb526 xsa218-4.7/0002-gnttab-fix-unmap-pin-accounting-race.patch 6bfef9e1653a305e49653c5b81acb57ca41ee8410ea085d49c9bc7e4ccd31e54 xsa218-4.7/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch b4ede29e3a94d9e7992c90b8b7c8d489e071764218b28962b5755a444040e1ae xsa218-4.7/0004-gnttab-correct-maptrack-table-accesses.patch c2a1b40e76764333f3ee34dd9bc7d3e34bab91f8b44eaae7aa6f187bbddb358f xsa218-4.8/0001-gnttab-fix-unmap-pin-accounting-race.patch a210ff17a0ca1a81f2c98cce84a104ac7dd2f1a72fa3855ca5f3b3d13e95468c xsa218-4.8/0002-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch 0b8fa3d6a0f3ccb43c8134db2240867d5a850ee0821d4124a1642596b4d6cb5a xsa218-4.8/0003-gnttab-correct-maptrack-table-accesses.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly
[Xen-devel] Xen Security Advisory 221 (CVE-2017-10917) - NULL pointer deref in event channel poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10917 / XSA-221 version 3 NULL pointer deref in event channel poll UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = When polling event channels, in general arbitrary port numbers can be specified. Specifically, there is no requirement that a polled event channel ports has ever been created. When the code was generalised from an earlier implementation, introducing some intermediate pointers, a check should have been made that these intermediate pointers are non-NULL. However, that check was omitted. IMPACT == A malicious or buggy guest may cause the hypervisor to access addresses it doesn't control, usually leading to a host crash (Denial of Service). Information leaks cannot be excluded. VULNERABLE SYSTEMS == Xen versions 4.4 and newer are vulnerable. Xen versions 4.3 and earlier are not affected. Both x86 and ARM systems are vulnerable. While all guest kinds can cause a Denial of Service, only x86 PV guests may be able to leverage the possible information leaks. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Ankur Arora of Oracle. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa221.patch Xen 4.4.x and later, including xen-unstable $ sha256sum xsa221* 2425396a713466808b0f75f91337be4dd20a4dee7733972b04489773c6e97655 xsa221.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZX5IrAAoJEIP+FMlX6CvZvrQH/iiAi2rNN1mXhC9wRArVRhN4 CHQLswKxeCfL38sAkOCD1oshNsf5Cskv5WI0/row0SzUPuwsdglPBvpXjUdC+4c/ TNm119wRA3XigJl/eW+OlenA/QdXIjp7D3/IqVu5fEZ+bGntOgo7q4GhgsRRl2SR mKMgoN7/PCaLd5KtoCr76FygqBcTHYQDswa97alNXdwALC5PPb1R8lO+GDq4FPNj VYCsynBjVhScnbayEWmbPLXvkaz+6u2VccpfWDIS7i+dyTnAVTNkqS+Mzjsk07za FRisjlyc3rZTF/7nJ9Vtk4bCPC3+zmKsCTfzbOqdDYu9VJryK7gZl8yksfqw37s= =HElV -END PGP SIGNATURE- xsa221.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 222 (CVE-2017-10918) - stale P2M mappings due to insufficient error checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10918 / XSA-222 version 3 stale P2M mappings due to insufficient error checking UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Certain actions require removing pages from a guest's P2M (Physical-to-Machine) mapping. When large pages are in use to map guest pages in the 2nd-stage page tables, such a removal operation may incur a memory allocation (to replace a large mapping with individual smaller ones). If this allocation fails, these errors are ignored by the callers, which would then continue and (for example) free the referenced page for reuse. This leaves the guest with a mapping to a page it shouldn't have access to. The allocation involved comes from a separate pool of memory created when the domain is created; under normal operating conditions it never fails, but a malicious guest may be able to engineer situations where this pool is exhausted. IMPACT == A malicious guest may be able to access memory it doesn't own, potentially allowing privilege escalation, host crashes, or information leakage. VULNERABLE SYSTEMS == Xen versions from at least 3.2 onwards are vulnerable. Older versions have not been inspected. Both x86 and ARM systems are vulnerable. On x86 systems, only HVM guests can leverage the vulnerability. MITIGATION == On x86, specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will avoid the vulnerability. Alternatively, running all x86 HVM guests in shadow mode will also avoid this vulnerability. (For example, by specifying "hap=0" in the xl domain configuration file.) There is no known mitigation on ARM systems. CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the appropriate pair of attached patches resolves this issue. xsa222-[12].patchxen-unstable xsa222-1.patch, xsa222-2-4.8.patch Xen 4.8.x xsa222-[12]-4.7.patchXen 4.7.x xsa222-[12]-4.6.patchXen 4.6.x xsa222-1-4.6.patch, xsa222-2-4.5.patch Xen 4.5.x $ sha256sum xsa222* 8bd8807ee1cfe01c86194f5d5be38618ba5e0c1206667bb119ed952e5d155c1a xsa222-1.patch 9288dfcae1f37e6c8f13910046f43ec161710abb7c94a9346b7e0eaba3258ccd xsa222-1-4.6.patch ebc2c070bad8012a196e984b568a72e013ff072bb077870508f09ed053c1a4c2 xsa222-1-4.7.patch ee320b37b365cb3b6660e559902ff8bb50657b2a28ff0fa7ebaf9ffd33fc0942 xsa222-2.patch 97768f4fe564f702de8e4aebd0c4d24858814ebbb7be532b376cfae7ad6834a4 xsa222-2-4.5.patch 4142f76673b996b65301d52216cbf56e27b0c86e5607f6a9eb18dcc7df3f6343 xsa222-2-4.6.patch a640e190b32e82f5ec7ee4968bf8b9f22137e8379314cc9a29556637c3dc8e87 xsa222-2-4.7.patch ab43bd590139bed53957b3b37b854183c69bee26cf7cb00900e3f4a150d067a5 xsa222-2-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZX5I0AAoJEIP+FMlX6CvZCG8IAJ9PQcPjjf4cHdmpZDlpRUtR M94vFhyCcjSjoVUp3syJnlK+BKgJcEd1LyVplPYBJI/rKroFHSdnTbjJqjE0WAJi uOb2hSe6nj9FD4bCAnL+B0y1BSn+pU5576i6IqEN/dDLTtVA+DH3S3qrnJbzIPuD 1fha4CafMcUJ6qXbs1IHAnlzy09sVI09o1oOtyzLZ/9W6ECiZqCCC9WtE5uBn7MB NvqWuQrteCJmApDAAz6cAv02FxLJiSKra2reBfEDkx4Yy8u6Z4HGhGuInqI4gNbz QHx9ufWNI6FA5E9l/oPpPdLgFv3TDhCcjl85dk+MsKeewA/b4nWtRfmgkg0ekKM= =DNS7 -END PGP SIGNATURE- xsa222-1.patch Description: Binary data xsa222-1-4.6.patch Description: Binary data xsa222-1-4.7.patch Description: Binary data xsa222-2.patch Description: Binary data xsa222-2-4.5.patch Description: Binary data xsa222-2-4.6.patch Description: Binary data xsa222-2-4.7.patch Description: Binary data xsa222-2-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 219 (CVE-2017-10915) - x86: insufficient reference counts during shadow emulation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10915 / XSA-219
version 3
x86: insufficient reference counts during shadow emulation
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
When using shadow paging, writes to guest pagetables must be trapped and
emulated, so the shadows can be suitably adjusted as well.
When emulating the write, Xen maps the guests pagetable(s) to make the final
adjustment and leave the guest's view of its state consistent.
However, when mapping the frame, Xen drops the page reference before
performing the write. This is a race window where the underlying frame can
change ownership.
One possible attack scenario is for the frame to change ownership and to be
inserted into a PV guest's pagetables. At that point, the emulated write will
be an unaudited modification to the PV pagetables whose value is under guest
control.
IMPACT
==
A malicious pair of guests may be able to elevate their privilege to that of
Xen.
We have not ruled out the possibility that a single malicious HVM
guest may be able to elevate their privilege to that of Xen.
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
Only x86 systems are affected. ARM systems are not vulnerable.
HVM guests using shadow mode paging can exploit this vulnerability. HVM guests
using Hardware Assisted Paging (HAP) cannot exploit this vulnerability.
To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q'). This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:
(XEN) General information for domain 2:
(XEN) refcnt=1 dying=2 pause_count=2
(XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=262400
(XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
(XEN) paging assistance: hap refcounts translate external
^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain. For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.
Xen 4.6 and later have the option to compile-out shadow paging support. (The
default is to compile with shadow paging support). If Xen is built without
shadow support, it is not vulnerable.
Exploiting this race condition requires coordination between an x86 HVM guest
using shadow paging, and a PV guest.
Running only HVM guests avoids the vulnerability, unless stub device
models are in use (since stub device models are PV domains, each
controlled by the corresponding guest).
Running only PV guests avoids the vulnerability.
MITIGATION
==
Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests. HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.
(This mitigation is not applicable to PV guests.)
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa219.patch xen-unstable
xsa219-4.8.patch Xen 4.8, 4.7
xsa219-4.6.patch Xen 4.6
xsa219-4.5.patch Xen 4.5, 4.4
$ sha256sum xsa219*
d06759d11dad3b128e65ade9e6afc1c728b65457cc32c34f46690f959c48644f xsa219.patch
0dd27ad66f964ba163dbc72e3a074d171b0e1edf9b322d811feb7f5c1deb4437
xsa219-4.5.patch
d5fdd9d75dbad4a2315f48f8aec5dd3a10b92307320b5c141e2c1e69e422510c
xsa219-4.6.patch
a2023599abbc3b8f46cd430bec154401ef166493fcb5787f2f6fb9802b12f9b4
xsa219-4.8.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
[Xen-devel] Xen Security Advisory 223 (CVE-2017-10919) - ARM guest disabling interrupt may crash Xen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10919 / XSA-223 version 3 ARM guest disabling interrupt may crash Xen UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Virtual interrupt injection could be triggered by a guest when sending an SGI (e.g IPI) to any vCPU or by configuring timers. When the virtual interrupt is masked, a missing check in the injection path may result in reading invalid hardware register or crashing the host. IMPACT == A guest may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == All Xen versions which support ARM are affected. x86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not disable SGI and PPI (i.e IRQ < 32) will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the attached patch resolves this issue. xsa223.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa223* b5c8d8e8dac027069bec7dd812cff3f6f99e5949dd4a8ee729255c38274958b1 xsa223.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZX5I2AAoJEIP+FMlX6CvZuooH/0bkL0vO55m0gAFI/5Ipsopj tsvHObMSeeXRbn9IlhHgqG1HMtiMxMrT5ucQk66jW9oaEX4wxSbeZfDj7F0YlS7q krtRpQsxd0cwL5vN5aGSTs7e8O3G2pXUcVszp/lifZs/17QzjWZTPafQcthcAcRk ohX46fW8GROCXltHXI5epV7vxfD6JiKcejGNa/DUk65qPawjL/kcO2hrcGT8SS6f wlMNnR3ECwcMf0KYxvXrMyyLkfjKhQJDX3Ue6gRretBZ/llSRa75SWNWdGo3lQN1 7y2OuNbr4b2LISZE4f+F0xwMpuBTSnBnrVbyYSyGbBLULsGQF9Di7ok4bqPsuGA= =TPUB -END PGP SIGNATURE- xsa223.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 225 (CVE-2017-10923) - arm: vgic: Out-of-bound access when sending SGIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10923 / XSA-225 version 3 arm: vgic: Out-of-bound access when sending SGIs UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = ARM guests can send SGI (i.e. IPI) targeting a list of vCPUs using the MMIO register GICD_SGIR (GICv2) or System Register ICC_SGI1R (GICv3). However, the emulation code does not sanitize the list and will directly access an array without checking whether the array index is within bounds. IMPACT == A guest may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == Xen versions 4.6 and onwards are affected. Xen versions 4.5 and earlier are not affected. Only ARM systems are affected. x86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which only send sane IPIs (i.e. targeting valid CPUs) will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the attached patch resolves this issue. xsa225.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x $ sha256sum xsa225* a52d90a2586b74d6dd0d17390c940bf414c1332a6b4ccb87f10b7d97af3b3877 xsa225.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZX5I4AAoJEIP+FMlX6CvZm7oIAMpza3K23Dh57zjVhFoKSrK7 C/l5LbgxQB53uqlgDWeLlGxoRBuYOUg4i8rYzwI5NJAy8Y7n5z3kf8V8IcHa2+9E Oums8O2jpGEjiGddtOW06wRCQQPaNo/ivrjRCeLEVVTc6Lvni22Bp38vjTPykIYY SOspEAg9VU7BUp+K8LYF16/tYV5QyPf5JQDHWX4xKjlT0F3sRtrO5hXY3uZUJlMt GqLXFcD1CQqjwiaqeD/kZOpJiWCXTrMk9DoSMO2HcsJniZfLdom9MdL9YTPQNi9R oQkVSDt5Szt8pGTojgDymYEi8F3+LdDrauGPGUl4CNao7Yv/L1BMcNEcukiCTDY= =KiJw -END PGP SIGNATURE- xsa225.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 216 (CVE-2017-10911) - blkif responses leak backend stack data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10911 / XSA-216 version 5 blkif responses leak backend stack data UPDATES IN VERSION 5 CVE assigned. ISSUE DESCRIPTION = The block interface response structure has some discontiguous fields. Certain backends populate the structure fields of an otherwise uninitialized instance of this structure on their stacks, leaking data through the (internal or trailing) padding field. IMPACT == A malicious unprivileged guest may be able to obtain sensitive information from the host or other guests. VULNERABLE SYSTEMS == All Linux versions supporting the xen-blkback, blkback, or blktap drivers are vulnerable. FreeBSD, NetBSD and Windows (with or without PV drivers) are not vulnerable (either because they do not have backends at all, or because they use a different implementation technique which does not suffer from this problem). All qemu versions supporting the Xen block backend are vulnerable. The qemu-xen-traditional code base does not include such code, so is not vulnerable. Note that an instance of qemu will be spawned to provide the backend for most non-raw-format disks; so you may need to apply the patch to qemu even if you use only PV guests. MITIGATION == There's no mitigation available for x86 PV and ARM guests. For x86 HVM guests it may be possible to change the guest configuaration such that a fully virtualized disk is being made available instead. However, this would normally entail changes inside the guest itself. CREDITS === This issue was discovered by Anthony Perard of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa216-linux-4.11.patch Linux 4.5 ... 4.11 xsa216-linux-4.4.patchLinux 3.3 ... 4.4 xsa216-qemuu.patchqemu-upstream master, 4.8 xsa216-qemuu-4.7.patchqemu-upstream 4.7, 4.6 xsa216-qemuu-4.5.patchqemu-upstream 4.5 xsa216-linux-2.6.18-xen.patch linux-2.6.18-xen.hg $ sha256sum xsa216* d316e16f8da2078966e9d7d516dd0a9ed5a29c3bc479974374c8fa778859913d xsa216-linux-2.6.18-xen.patch 4440fe324b61baf0f3f5a73352c4d9ac6f94917e216d8421263a5e67445852db xsa216-linux-4.4.patch eb24bfc0303e13e08fd3710463aea139a92a3f83db7f35119c4d3831154a6453 xsa216-linux-4.11.patch b4b8f68fa05d718c5be7023c84d942e43725bcc563ea15556ee9646f6f9bf7e7 xsa216-qemuu.patch 4fc3665ff07ec79fb31ac66a3fd360a45b7ec546c549c04284f0128ad0c5beba xsa216-qemuu-4.5.patch a0e0dfd5ea2643ae14c220124194388017a3656db3e6ce430913cda800c43aad xsa216-qemuu-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because this produces a guest-visible change which will indicate which component contains the vulnerability. Additionally, distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZX5IiAAoJEIP+FMlX6CvZdK8IALydeCfUgLpTzeVaRidXkO9M dlChA1fXn5ZRlQxvGGIzatkl2Em99+JfIyW21AoVqFAyIYbYkbV7zmp82HpHAZfB Ib5tFUS4ki1paXXcBtQSvgsz7Sxh5obZnCzyguOcSthZ0/Ude5mh9ImsnKepNxQi GbMBY9xsBv+tclRLiaGUIBgKwtNc0AXpQhWAkbAEWjdYSN2CGsS37Z9Hi0GOoID/ Z49g7/shKDyrHxR1ph0uFqZOkCW8Um3qpORzwHIwpsqleY7Y5E9Ib/QXDOV7wJ1m IDhkSmYf6kXjJ1yhwjRw4UgsGWj/TDyi9d6HxYU9DVHY1b5lWuNjbbyeMuVpR8A= =18b8 -END PGP SIGNATURE- xsa216-linux-2.6.18-xen.patch Description: Binary data xsa216-linux-4.4.patch Description: Binary data xsa216-linux-4.11.patch Description: Binary data xsa216-qemuu.patch Description: Binary data xsa216-qemuu-4.5.patch Description: Binary data xsa216-qemuu-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 220 (CVE-2017-10916) - x86: PKRU and BND* leakage between vCPU-s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-10916 / XSA-220
version 3
x86: PKRU and BND* leakage between vCPU-s
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
newer processors, whose state is intended to be per-thread and context
switched along with all other XSAVE state.
Xen's vCPU context switch code would save and restore the state only
if the guest had set the relevant XSTATE enable bits. However,
surprisingly, the use of these features is not dependent (PKU) or may
not be dependent (MPX) on having the relevant XSTATE bits enabled.
VMs which use MPX or PKU, and context switch the state manually rather
than via XSAVE, will have the state leak between vCPUs (possibly,
between vCPUs in different guests). This in turn corrupts state in
the destination vCPU, and hence may lead to weakened protections
Experimentally, MPX appears not to make any interaction with BND*
state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear. However,
the SDM is not clear in this case; therefore MPX is included in this
advisory as a precaution.
IMPACT
==
There is an information leak, of control information mentioning
pointers into guest address space; this may weaken address space
randomisation and make other attacks easier.
When an innocent guest acquires leaked state, it will run with
incorrect protection state. This could weaken the protection intended
by the MPX or PKU features, making other attacks easier which would
otherwise be excluded; and the incorrect state could also cause a
denial of service by preventing legitimate accesses.
VULNERABLE SYSTEMS
==
Xen 4.4 and earlier are not vulnerable, as they do not use or expose
MPX or PKU to guests. Xen 4.5 and later expose MPX to guests. Xen
4.7 and later expose PKU to guests. Therefore, Xen 4.5 and later are
vulnerable.
Only x86 hardware implementing the MPX or PKU features is vulnerable.
At the time of writing, these are Intel Skylake (and later) processors
for MPX, and Intel Skylake Server (and later) processors for PKU.
ARM hardware is not vulnerable.
The vulnerability is only exposed to HVM guests. PV guests cannot
exploit the vulnerability.
Vulnerable guest operating systems
- --
Guests which use XSAVE for context switching PKU and MPX state are not
vulnerable to inbound corruption caused by another malicious domain.
With respect to PKU, the remaining outbound information leak is of no
conceivable consequence. And, experimentally, MPX does not appear to
have a real vulnerability, even though the CPU documentation is not
clear.
Therefore we think that these guests (those which use XSAVE) are not
vulnerable.
Linux uses XSAVE, so is therefore not vulnerable.
MITIGATION
==
Passing "pku=0" on the hypervisor command line will avoid the PKU
vulnerability (by not advertising the feature to guests).
There is no corresponding option for the probably-theoretical MPX
vulnerability.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa220.patch xen-unstable
xsa220-4.8.patch Xen 4.8
xsa220-4.7.patch Xen 4.7
xsa220-4.6.patch Xen 4.6
xsa220-4.5.patch Xen 4.5
$ sha256sum xsa220*
8b86d9a284c0b14717467e672e63aebfc2bce201658493a54c64fb7c1863ce49 xsa220.patch
4b53ad5748313fb92c68eac1160b00d1bf7310019657028122a455855334252b
xsa220-4.5.patch
befe5ca5321d903428fc496abeee3a3b5eb0cee27a382e20d3caf8cc7bdfced2
xsa220-4.6.patch
555fa741348909943393aaf73571bc7817b30eafcff73dbfcd7393db5d7f
xsa220-4.7.patch
7a41ad9c6f9d46536abae051c517456bdfa3564278e98f80222a904df749fb0c
xsa220-4.8.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
[Xen-devel] Xen Security Advisory 217 (CVE-2017-10912) - page transfer may allow PV guest to elevate privilege
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-10912 / XSA-217 version 3 page transfer may allow PV guest to elevate privilege UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Domains controlling other domains are permitted to map pages owned by the domain being controlled. If the controlling domain unmaps such a page without flushing the TLB, and if soon after the domain being controlled transfers this page to another PV domain (via GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third domain uses the page as a page table, the controlling domain will have write access to a live page table until the applicable TLB entry is flushed or evicted. Note that the domain being controlled is necessarily HVM, while the controlling domain is PV. IMPACT == A malicious pair of guests may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. Only systems where an attacker can control both a PV and an HVM guest are vulnerable. This must be presumed to include systems containing HVM domains with service domains such as stub domain device models. Systems containing only PV guests are not vulnerable. Systems containing only HVM domains serviced by dom0 device model processes are not vulnerable. Note that with libxl, xl, and libvirt, HVM domains use dom0 device model processes by default. MITIGATION == There is no mitigation for this vulnerability. Switching from stub device models to dom0 process device models is not recommended as a mitigation, as in practice the vulnerability is likely to be hard to exploit through this route; whereas dom0 process device models may have unknown vulnerabilities. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa217.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa217-4.5.patch Xen 4.5.x $ sha256sum xsa217* 3e896412389d8e59e417ea7bb3d5b47a20de27b8eae0420c98071ce4b17d219c xsa217.patch 4e555cf47faf5e8d2bba4ff8a31fbe72fb11a6c0e3b286f23b26e684a1809705 xsa217-4.5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZX5IlAAoJEIP+FMlX6CvZCC8IAJ8VgkRigZpOyxl1CHP+pSGu TZzWOS0xCMsuIkbPaGgfbgykNh7/7byWWPBZwoUSKh1gnWXIohFtRr3JvPKlsb8X 5nthArzR1biR4c9kXL7TYiLhxoInHYT3tE7tnAj6c68qxWLrkQuTW3C3kJnlVf+p XXIju4ccV33X0hT1nqOr5P9FqhmDKgml4qeaUnEabFjXgM16/JaHM8f2k2U/FYJP mfrh+5EeAMg3i1OdtLklMyEUXlA1IE2m7BsfnA3eMQ9xc50mjEQ/NZYhe3knv7IX KfvRMMZgjTvEO/6GU7Qt5qlBRLj1e/jpxaviHsdZaLPoHz4Cq4WncdfyqfAJ1Dk= =WueX -END PGP SIGNATURE- xsa217.patch Description: Binary data xsa217-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 216 - blkif responses leak backend stack data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-216 version 4 blkif responses leak backend stack data UPDATES IN VERSION 4 Move "For patch:" Reported-by to patches as intended. ISSUE DESCRIPTION = The block interface response structure has some discontiguous fields. Certain backends populate the structure fields of an otherwise uninitialized instance of this structure on their stacks, leaking data through the (internal or trailing) padding field. IMPACT == A malicious unprivileged guest may be able to obtain sensitive information from the host or other guests. VULNERABLE SYSTEMS == All Linux versions supporting the xen-blkback, blkback, or blktap drivers are vulnerable. FreeBSD, NetBSD and Windows (with or without PV drivers) are not vulnerable (either because they do not have backends at all, or because they use a different implementation technique which does not suffer from this problem). All qemu versions supporting the Xen block backend are vulnerable. The qemu-xen-traditional code base does not include such code, so is not vulnerable. Note that an instance of qemu will be spawned to provide the backend for most non-raw-format disks; so you may need to apply the patch to qemu even if you use only PV guests. MITIGATION == There's no mitigation available for x86 PV and ARM guests. For x86 HVM guests it may be possible to change the guest configuaration such that a fully virtualized disk is being made available instead. However, this would normally entail changes inside the guest itself. CREDITS === This issue was discovered by Anthony Perard of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa216-linux-4.11.patch Linux 4.5 ... 4.11 xsa216-linux-4.4.patchLinux 3.3 ... 4.4 xsa216-qemuu.patchqemu-upstream master, 4.8 xsa216-qemuu-4.7.patchqemu-upstream 4.7, 4.6 xsa216-qemuu-4.5.patchqemu-upstream 4.5 xsa216-linux-2.6.18-xen.patch linux-2.6.18-xen.hg $ sha256sum xsa216* d316e16f8da2078966e9d7d516dd0a9ed5a29c3bc479974374c8fa778859913d xsa216-linux-2.6.18-xen.patch 4440fe324b61baf0f3f5a73352c4d9ac6f94917e216d8421263a5e67445852db xsa216-linux-4.4.patch eb24bfc0303e13e08fd3710463aea139a92a3f83db7f35119c4d3831154a6453 xsa216-linux-4.11.patch b4b8f68fa05d718c5be7023c84d942e43725bcc563ea15556ee9646f6f9bf7e7 xsa216-qemuu.patch 4fc3665ff07ec79fb31ac66a3fd360a45b7ec546c549c04284f0128ad0c5beba xsa216-qemuu-4.5.patch a0e0dfd5ea2643ae14c220124194388017a3656db3e6ce430913cda800c43aad xsa216-qemuu-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However, deployment of the mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because this produces a guest-visible change which will indicate which component contains the vulnerability. Additionally, distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZSRYiAAoJEIP+FMlX6CvZILQIALI17G6L+BIr6rXHglleL6Lz E9Rvlng8K3e5088Hzs5gwq0c9jeK7i9B8PIjdgTH8OS1YjwpWF4wdPveSNACules 590SQVdwN2+Q1oTqdEECnaaCdl7eiEiv+2vRr+LYXNSLJuIRclnc/Fv3nTz/iuTM 5vwIVS/rpdETDBcMJVbCRvUbMeCx/ZM8+lNmEe20QP6h++pmc8wT7B54yGVwk6LT eknzRMFYhUqcF8eLTJ/QyHf94x1mujVCHNKbOXkMQ27lWAJ5Jt2ut0IZeA6CFAlw j/u8azGv9VIpXGLp2R1OWPYbEYeAzvjNC7+qoixiscSvfPkiSTfAv7pmr52jvGg= =+gya -END PGP SIGNATURE- xsa216-linux-2.6.18-xen.patch Description: Binary data xsa216-linux-4.4.patch Description: Binary data xsa216-linux-4.11.patch Description: Binary data xsa216-qemuu.patch Description: Binary data xsa216-qemuu-4.5.patch Description: Binary data xsa216-qemuu-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org
[Xen-devel] Xen Security Advisory 218 - Races in the grant table unmap code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-218 version 4 Races in the grant table unmap code UPDATES IN VERSION 4 Adjust last patch description and add review tag. Public release. ISSUE DESCRIPTION = We have discovered two bugs in the code unmapping grant references. * When a grant had been mapped twice by a backend domain, and then unmapped by two concurrent unmap calls, the frontend may be informed that the page had no further mappings when the first call completed rather than when the second call completed. * A race triggerable by an unprivileged guest could cause a grant maptrack entry for grants to be "freed" twice. The ultimate effect of this would be for maptrack entries for a single domain to be re-used. IMPACT == For the first issue, for a short window of time, a malicious backend could still read and write memory that the frontend thought was its own again. Depending on the usage, this could be either an information leak, or a backend-to-frontend privilege escalation. The second issue is more difficult to analyze. It can probably cause reference counts to leak, preventing memory from being freed on domain destruction (denial-of-service), but information leakage or host privilege escalation cannot be ruled out. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Both ARM and x86 are vulnerable. On x86, systems with either PV or HVM guests are vulnerable. MITIGATION == None. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate set of attached patches resolves this issue. xsa218-unstable/*.patchxen-unstable xsa218-4.8/*.patch Xen 4.8.x xsa218-4.7/*.patch Xen 4.7.x xsa218-4.6/*.patch Xen 4.6.x xsa218-4.5/*.patch Xen 4.5.x $ sha256sum xsa218*/* 6f5e588edb6d3f0a37b89235e95cdcc7ca73cdff236d86b65e6f608bd15b03ec xsa218-unstable/0001-gnttab-fix-unmap-pin-accounting-race.patch 5cb85f0aaa19ff343fc51b08addbf37d62352774115acd28eb18a73f67507e21 xsa218-unstable/0002-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch f5f3d27ce2829b3aa5e09b216bf9afcb1dc6b1f9f3b3a0f3ebfe5a68b4948aef xsa218-unstable/0003-gnttab-correct-maptrack-table-accesses.patch fafb8773957bbffb21ab43c7a3559efe15f52d234afba5f2ad2739411946c021 xsa218-4.5/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures.patch 4398ad7111421dbf954ede651cb7f9acd83c654c7fa93d54a4e5f9b7b25fe918 xsa218-4.5/0002-gnttab-fix-unmap-pin-accounting-race.patch 9d23946afb96a70c574b8c7ff42ed8b30b72e9a1f751ff617a7578c79645c094 xsa218-4.5/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch 27d92c6f4d89de3fd9e9311337823370303c1ef985cce2bd9bea28f00cd6c184 xsa218-4.5/0004-gnttab-correct-maptrack-table-accesses.patch 99ac090d7955a46c6c9c73ca62b64cef6b8f05439961e52278c662f030a36ee2 xsa218-4.6/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures.patch e0f0839336e055c1422cf0f76c37f6d9cc8474b0140ffef2451dca6697a9f20f xsa218-4.6/0002-gnttab-fix-unmap-pin-accounting-race.patch 5f6f63211b18bb6ec157353b9e8b844abe3fd767ef1780e6d28731e935559fbc xsa218-4.6/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch 6a786a8c4b916b6f99092598bd4d60381907cd7e728c98a79e999afeec4f45a6 xsa218-4.6/0004-gnttab-correct-maptrack-table-accesses.patch 58354eec5f4f0b87640c702c6e1ce0eeb57dffbd09394a96e88bd6ff42c53e7e xsa218-4.7/0001-IOMMU-handle-IOMMU-mapping-and-unmapping-failures.patch 0683d7ffdbe60dc8e1d161adeb0c5465df1840e86353b5cbb96dd204f2dbb526 xsa218-4.7/0002-gnttab-fix-unmap-pin-accounting-race.patch 6bfef9e1653a305e49653c5b81acb57ca41ee8410ea085d49c9bc7e4ccd31e54 xsa218-4.7/0003-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch b4ede29e3a94d9e7992c90b8b7c8d489e071764218b28962b5755a444040e1ae xsa218-4.7/0004-gnttab-correct-maptrack-table-accesses.patch c2a1b40e76764333f3ee34dd9bc7d3e34bab91f8b44eaae7aa6f187bbddb358f xsa218-4.8/0001-gnttab-fix-unmap-pin-accounting-race.patch a210ff17a0ca1a81f2c98cce84a104ac7dd2f1a72fa3855ca5f3b3d13e95468c xsa218-4.8/0002-gnttab-Avoid-potential-double-put-of-maptrack-entry.patch 0b8fa3d6a0f3ccb43c8134db2240867d5a850ee0821d4124a1642596b4d6cb5a xsa218-4.8/0003-gnttab-correct-maptrack-table-accesses.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly
[Xen-devel] Xen Security Advisory 223 - ARM guest disabling interrupt may crash Xen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-223 version 2 ARM guest disabling interrupt may crash Xen UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Virtual interrupt injection could be triggered by a guest when sending an SGI (e.g IPI) to any vCPU or by configuring timers. When the virtual interrupt is masked, a missing check in the injection path may result in reading invalid hardware register or crashing the host. IMPACT == A guest may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == All Xen versions which support ARM are affected. x86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not disable SGI and PPI (i.e IRQ < 32) will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the attached patch resolves this issue. xsa223.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa223* b5c8d8e8dac027069bec7dd812cff3f6f99e5949dd4a8ee729255c38274958b1 xsa223.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZSQ3WAAoJEIP+FMlX6CvZpxQH/0nQaJEWEuVZlQliIaB3TUK2 nnXBf3cFMsNCBIsrQtYXetZ8amA7cjULd2SX8/WIR60CPZ5Uj/YQtld5cq4LfxMj Ngma8mPDUMlu6t+n07vee/fte5fZYOpci0teC9NCLDbG5eTWoJ0K7CzN2JUQWLAb IgeJAVgyNr3ZibqdB8xBb5KlA+hOBE77MQ6yt8qZeltoYezIxprwgcqE/BgMVrcj +7pz0WtJtdTe7i8i6jGcqvzbl3WhmcppiDLNhv310V+dV+T2e9cJia5EuapbqYD7 mkMLnOTRngJq97q1RwTQlsLMOp+/deZpqueLKttVCSR6VP4GtKpgr/0O1NW91YU= =hATV -END PGP SIGNATURE- xsa223.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 216 - blkif responses leak backend stack data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-216
version 3
blkif responses leak backend stack data
UPDATES IN VERSION 3
Public release.
Fix a typo ("our" for "or" in Vulnerable Systems).
ISSUE DESCRIPTION
=
The block interface response structure has some discontiguous fields.
Certain backends populate the structure fields of an otherwise
uninitialized instance of this structure on their stacks, leaking
data through the (internal or trailing) padding field.
IMPACT
==
A malicious unprivileged guest may be able to obtain sensitive
information from the host or other guests.
VULNERABLE SYSTEMS
==
All Linux versions supporting the xen-blkback, blkback, or blktap
drivers are vulnerable.
FreeBSD, NetBSD and Windows (with or without PV drivers) are not
vulnerable (either because they do not have backends at all, or
because they use a different implementation technique which does not
suffer from this problem).
All qemu versions supporting the Xen block backend are vulnerable. The
qemu-xen-traditional code base does not include such code, so is not
vulnerable. Note that an instance of qemu will be spawned to provide
the backend for most non-raw-format disks; so you may need to apply the
patch to qemu even if you use only PV guests.
MITIGATION
==
There's no mitigation available for x86 PV and ARM guests.
For x86 HVM guests it may be possible to change the guest
configuaration such that a fully virtualized disk is being made
available instead. However, this would normally entail changes inside
the guest itself.
CREDITS
===
This issue was discovered by Anthony Perard of Citrix.
For patch:
Reported by: Anthony Perard
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa216-linux-4.11.patch Linux 4.5 ... 4.11
xsa216-linux-4.4.patchLinux 3.3 ... 4.4
xsa216-qemuu.patchqemu-upstream master, 4.8
xsa216-qemuu-4.7.patchqemu-upstream 4.7, 4.6
xsa216-qemuu-4.5.patchqemu-upstream 4.5
xsa216-linux-2.6.18-xen.patch linux-2.6.18-xen.hg
$ sha256sum xsa216*
28beb3d876fa0eee77f4377ef2708d764a5d9a2003dd4f1a4ecb9b8bf60658a4
xsa216-linux-2.6.18-xen.patch
6f6138c0a00df4ed7307ae4e5ee30dbe8594ff05bc1e8fdc7cfd785077d72ddc
xsa216-linux-4.4.patch
e04da27961cd867f7bbba31677f61e3e425c0e7cc7352a7a2d22b5a35eaf8585
xsa216-linux-4.11.patch
850b0143cfe3c69c62abdad71be9813014d46c380109fc650689a10c90ff39f4
xsa216-qemuu.patch
072270274d2554b71579a529c908d16479f8eba6646d8aed2e3d129495b27716
xsa216-qemuu-4.5.patch
5a64e2c5bb78f1c8fae97354be10fcc63ea39d333d6490e3a422ff30460cdef1
xsa216-qemuu-4.7.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
However, deployment of the mitigation is NOT permitted (except where
all the affected systems and VMs are administered and used only by
organisations which are members of the Xen Project Security Issues
Predisclosure List). Specifically, deployment on public cloud systems
is NOT permitted. This is because this produces a guest-visible
change which will indicate which component contains the vulnerability.
Additionally, distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZSQ3JAAoJEIP+FMlX6CvZWkQIAMXD8Lc1PunNw5x9WsLb2y9U
KA0QrsNve4Ugc/xvCiuqUoV+ljZIRiy57A//ZnNtTR8JiRqpjEC47he3oYNleytN
RfOw2ZzsXdD4F8sqT3YvR0vcPL1Pf7fHzg8Ax19RxdcXRWTrN/b/poxuCu4F5PWn
cFi4tQDYLuEb2e9Sj8ue8RbtcVOEyuSG/dP1E29K7sKdc6GB13nWsa93KJsSRLY6
cwKnOmBy+2H66FcfmWomU+OueKI7y5DsYxYV+VVUBGnBTSn0b3dwpHNKUBCuF1nQ
RqOjo2rHOMBeiGaAlGg8toef7IkRH20p/LjiQxAneMndmta3t9enx8rYYxgFd5k=
=3n1c
-END PGP SIGNATURE-
xsa216-linux-2.6.18-xen.patch
Description: Binary data
xsa216-linux-4.4.patch
Description: Binary data
xsa216-linux-4.11.patch
Description: Binary data
xsa216-qemuu.patch
Description: Binary data
xsa216-qemuu-4.5.patch
Description: Binary data
xsa216-qemuu-4.7.patch
Description: Binary data
[Xen-devel] Xen Security Advisory 225 - arm: vgic: Out-of-bound access when sending SGIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-225 version 2 arm: vgic: Out-of-bound access when sending SGIs UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = ARM guests can send SGI (i.e. IPI) targeting a list of vCPUs using the MMIO register GICD_SGIR (GICv2) or System Register ICC_SGI1R (GICv3). However, the emulation code does not sanitize the list and will directly access an array without checking whether the array index is within bounds. IMPACT == A guest may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == Xen versions 4.6 and onwards are affected. Xen versions 4.5 and earlier are not affected. Only ARM systems are affected. x86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which only send sane IPIs (i.e. targeting valid CPUs) will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the attached patch resolves this issue. xsa225.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x $ sha256sum xsa225* a52d90a2586b74d6dd0d17390c940bf414c1332a6b4ccb87f10b7d97af3b3877 xsa225.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZSQ3mAAoJEIP+FMlX6CvZ/TAH/Role6HA+csMGO/DshXbfuhN /S+DOPKU7NwynExZhf43Afj37EI4cw3xUcpRrZJbRExhGtlnBInsjUq8V9kmWcZL pJOgVcTOMyeR6Mc3B/tLqamH49uJdEGoi3zHVtckXY/A8a8+iyT5faSibmsWgl1t mYylB33xg9JmQ6gEa4NtbXOFi/f7BHjXUqVr8+P/KAyqvEramxoH+lp21Wrc1JZd wvpeEVnIlXjNBJB3ERqIENc/E0jlHY73mTLPK1br8OkkrJPnwkbC246Nd1cIosVt v8fe/Lin8yq2K+dPU6VFk/ZawDmOUtOtwJCL8klteIs6iiT+m2F3nGHMoQAGaBk= =lwE9 -END PGP SIGNATURE- xsa225.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 217 - page transfer may allow PV guest to elevate privilege
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-217 version 2 page transfer may allow PV guest to elevate privilege UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Domains controlling other domains are permitted to map pages owned by the domain being controlled. If the controlling domain unmaps such a page without flushing the TLB, and if soon after the domain being controlled transfers this page to another PV domain (via GNTTABOP_transfer or, indirectly, XENMEM_exchange), and that third domain uses the page as a page table, the controlling domain will have write access to a live page table until the applicable TLB entry is flushed or evicted. Note that the domain being controlled is necessarily HVM, while the controlling domain is PV. IMPACT == A malicious pair of guests may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. Only systems where an attacker can control both a PV and an HVM guest are vulnerable. This must be presumed to include systems containing HVM domains with service domains such as stub domain device models. Systems containing only PV guests are not vulnerable. Systems containing only HVM domains serviced by dom0 device model processes are not vulnerable. Note that with libxl, xl, and libvirt, HVM domains use dom0 device model processes by default. MITIGATION == There is no mitigation for this vulnerability. Switching from stub device models to dom0 process device models is not recommended as a mitigation, as in practice the vulnerability is likely to be hard to exploit through this route; whereas dom0 process device models may have unknown vulnerabilities. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa217.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x xsa217-4.5.patch Xen 4.5.x $ sha256sum xsa217* 3e896412389d8e59e417ea7bb3d5b47a20de27b8eae0420c98071ce4b17d219c xsa217.patch 4e555cf47faf5e8d2bba4ff8a31fbe72fb11a6c0e3b286f23b26e684a1809705 xsa217-4.5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEbBAEBCAAGBQJZSQ3LAAoJEIP+FMlX6CvZe2MH90dkMpagV2W3Q0uzwo3GT4tv VmrsM5O5oSCvJBpgRk397Nr6jbPfUOdH8LqHSuNjoU4vYThNqM8mTT0mqW0MKniK didfWFyXIjHuBIBaye2r+mFWQ5AFH9B4vp3XT65k+vgq6GTIlRmV8H/bGdeCE4kT 6ht+ZLzc9XAvOy46pxAw0nz51QkknX4DXC0JTJW77aqKFz3H9+LKS015MLPxBvwj JFgmGIgLHR9lsMIGHScLLFibzTE1cDGF9u0I2DLHpWsDMaZN6kJfq8xblEtq58EE goth3SydPXPq4UuLfRMQMHX+pCxCdh9bwz82qThSmMFY7h/kPbw340D9+bBZIw== =/qch -END PGP SIGNATURE- xsa217.patch Description: Binary data xsa217-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 221 - NULL pointer deref in event channel poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-221 version 2 NULL pointer deref in event channel poll UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = When polling event channels, in general arbitrary port numbers can be specified. Specifically, there is no requirement that a polled event channel ports has ever been created. When the code was generalised from an earlier implementation, introducing some intermediate pointers, a check should have been made that these intermediate pointers are non-NULL. However, that check was omitted. IMPACT == A malicious or buggy guest may cause the hypervisor to access addresses it doesn't control, usually leading to a host crash (Denial of Service). Information leaks cannot be excluded. VULNERABLE SYSTEMS == Xen versions 4.4 and newer are vulnerable. Xen versions 4.3 and earlier are not affected. Both x86 and ARM systems are vulnerable. While all guest kinds can cause a Denial of Service, only x86 PV guests may be able to leverage the possible information leaks. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Ankur Arora of Oracle. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa221.patch Xen 4.4.x and later, including xen-unstable $ sha256sum xsa221* 2425396a713466808b0f75f91337be4dd20a4dee7733972b04489773c6e97655 xsa221.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZSQ3TAAoJEIP+FMlX6CvZw20H/jCUm+eX4rPUCQ6CL+Ya/dXH th34nPKQnq60gm3469sDQQMNbuvfgBItAAAjO87NC6P2BSyYPMny5SvqSsmkWow1 8OkAWq5ZZ3L7ksPhkP6aco+ks1a99SxJX4YfjwOFq9ct6/zfrcW1ThEqs9j87JeP 6RGPYgXc0mP9IOk27JnUVgiej7/v4a8v5FcWrG3bHpw2vp9tY3hdvkfc6wJiuplx kkqIVkqTpCNu7QYGv3de1RpDeI5mN8TGY+6ahs9eZFEFmRGWiAahhZRnwGVNE7Tl QcHzaphlzp/etub8sHgZPH90xLaeILJ+9oz29b/SLUVqahRxzTD1bLUElEu2su0= =xR3U -END PGP SIGNATURE- xsa221.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 220 - x86: PKRU and BND* leakage between vCPU-s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-220
version 2
x86: PKRU and BND* leakage between vCPU-s
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
Memory Protection Extensions (MPX) and Protection Key (PKU) are features in
newer processors, whose state is intended to be per-thread and context
switched along with all other XSAVE state.
Xen's vCPU context switch code would save and restore the state only
if the guest had set the relevant XSTATE enable bits. However,
surprisingly, the use of these features is not dependent (PKU) or may
not be dependent (MPX) on having the relevant XSTATE bits enabled.
VMs which use MPX or PKU, and context switch the state manually rather
than via XSAVE, will have the state leak between vCPUs (possibly,
between vCPUs in different guests). This in turn corrupts state in
the destination vCPU, and hence may lead to weakened protections
Experimentally, MPX appears not to make any interaction with BND*
state if BNDCFGS.EN is set but XCR0.BND{CSR,REGS} are clear. However,
the SDM is not clear in this case; therefore MPX is included in this
advisory as a precaution.
IMPACT
==
There is an information leak, of control information mentioning
pointers into guest address space; this may weaken address space
randomisation and make other attacks easier.
When an innocent guest acquires leaked state, it will run with
incorrect protection state. This could weaken the protection intended
by the MPX or PKU features, making other attacks easier which would
otherwise be excluded; and the incorrect state could also cause a
denial of service by preventing legitimate accesses.
VULNERABLE SYSTEMS
==
Xen 4.4 and earlier are not vulnerable, as they do not use or expose
MPX or PKU to guests. Xen 4.5 and later expose MPX to guests. Xen
4.7 and later expose PKU to guests. Therefore, Xen 4.5 and later are
vulnerable.
Only x86 hardware implementing the MPX or PKU features is vulnerable.
At the time of writing, these are Intel Skylake (and later) processors
for MPX, and Intel Skylake Server (and later) processors for PKU.
ARM hardware is not vulnerable.
The vulnerability is only exposed to HVM guests. PV guests cannot
exploit the vulnerability.
Vulnerable guest operating systems
- --
Guests which use XSAVE for context switching PKU and MPX state are not
vulnerable to inbound corruption caused by another malicious domain.
With respect to PKU, the remaining outbound information leak is of no
conceivable consequence. And, experimentally, MPX does not appear to
have a real vulnerability, even though the CPU documentation is not
clear.
Therefore we think that these guests (those which use XSAVE) are not
vulnerable.
Linux uses XSAVE, so is therefore not vulnerable.
MITIGATION
==
Passing "pku=0" on the hypervisor command line will avoid the PKU
vulnerability (by not advertising the feature to guests).
There is no corresponding option for the probably-theoretical MPX
vulnerability.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa220.patch xen-unstable
xsa220-4.8.patch Xen 4.8
xsa220-4.7.patch Xen 4.7
xsa220-4.6.patch Xen 4.6
xsa220-4.5.patch Xen 4.5
$ sha256sum xsa220*
8b86d9a284c0b14717467e672e63aebfc2bce201658493a54c64fb7c1863ce49 xsa220.patch
4b53ad5748313fb92c68eac1160b00d1bf7310019657028122a455855334252b
xsa220-4.5.patch
befe5ca5321d903428fc496abeee3a3b5eb0cee27a382e20d3caf8cc7bdfced2
xsa220-4.6.patch
555fa741348909943393aaf73571bc7817b30eafcff73dbfcd7393db5d7f
xsa220-4.7.patch
7a41ad9c6f9d46536abae051c517456bdfa3564278e98f80222a904df749fb0c
xsa220-4.8.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJZSQ3QAAoJEIP+FMlX6CvZ6ogH/3HavoXiL0zhOEfVyCJqMk8N
[Xen-devel] Xen Security Advisory 219 - x86: insufficient reference counts during shadow emulation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-219
version 2
x86: insufficient reference counts during shadow emulation
UPDATES IN VERSION 2
Public release.
Add caveat about exploitability by a single HVM guest, to Impact.
ISSUE DESCRIPTION
=
When using shadow paging, writes to guest pagetables must be trapped and
emulated, so the shadows can be suitably adjusted as well.
When emulating the write, Xen maps the guests pagetable(s) to make the final
adjustment and leave the guest's view of its state consistent.
However, when mapping the frame, Xen drops the page reference before
performing the write. This is a race window where the underlying frame can
change ownership.
One possible attack scenario is for the frame to change ownership and to be
inserted into a PV guest's pagetables. At that point, the emulated write will
be an unaudited modification to the PV pagetables whose value is under guest
control.
IMPACT
==
A malicious pair of guests may be able to elevate their privilege to that of
Xen.
We have not ruled out the possibility that a single malicious HVM
guest may be able to elevate their privilege to that of Xen.
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
Only x86 systems are affected. ARM systems are not vulnerable.
HVM guests using shadow mode paging can exploit this vulnerability. HVM guests
using Hardware Assisted Paging (HAP) cannot exploit this vulnerability.
To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q'). This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:
(XEN) General information for domain 2:
(XEN) refcnt=1 dying=2 pause_count=2
(XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=262400
(XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
(XEN) paging assistance: hap refcounts translate external
^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain. For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.
Xen 4.6 and later have the option to compile-out shadow paging support. (The
default is to compile with shadow paging support). If Xen is built without
shadow support, it is not vulnerable.
Exploiting this race condition requires coordination between an x86 HVM guest
using shadow paging, and a PV guest.
Running only HVM guests avoids the vulnerability, unless stub device
models are in use (since stub device models are PV domains, each
controlled by the corresponding guest).
Running only PV guests avoids the vulnerability.
MITIGATION
==
Where the HVM guest is explicitly configured to use shadow paging (eg
via the `hap=0' xl domain configuration file parameter), changing to
HAP (eg by setting `hap=1') will avoid exposing the vulnerability to
those guests. HAP is the default (in upstream Xen), where the
hardware supports it; so this mitigation is only applicable if HAP has
been disabled by configuration.
(This mitigation is not applicable to PV guests.)
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa219.patch xen-unstable
xsa219-4.8.patch Xen 4.8, 4.7
xsa219-4.6.patch Xen 4.6
xsa219-4.5.patch Xen 4.5, 4.4
$ sha256sum xsa219*
d06759d11dad3b128e65ade9e6afc1c728b65457cc32c34f46690f959c48644f xsa219.patch
0dd27ad66f964ba163dbc72e3a074d171b0e1edf9b322d811feb7f5c1deb4437
xsa219-4.5.patch
d5fdd9d75dbad4a2315f48f8aec5dd3a10b92307320b5c141e2c1e69e422510c
xsa219-4.6.patch
a2023599abbc3b8f46cd430bec154401ef166493fcb5787f2f6fb9802b12f9b4
xsa219-4.8.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
[Xen-devel] Xen Security Advisory 222 - stale P2M mappings due to insufficient error checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-222 version 2 stale P2M mappings due to insufficient error checking UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Certain actions require removing pages from a guest's P2M (Physical-to-Machine) mapping. When large pages are in use to map guest pages in the 2nd-stage page tables, such a removal operation may incur a memory allocation (to replace a large mapping with individual smaller ones). If this allocation fails, these errors are ignored by the callers, which would then continue and (for example) free the referenced page for reuse. This leaves the guest with a mapping to a page it shouldn't have access to. The allocation involved comes from a separate pool of memory created when the domain is created; under normal operating conditions it never fails, but a malicious guest may be able to engineer situations where this pool is exhausted. IMPACT == A malicious guest may be able to access memory it doesn't own, potentially allowing privilege escalation, host crashes, or information leakage. VULNERABLE SYSTEMS == Xen versions from at least 3.2 onwards are vulnerable. Older versions have not been inspected. Both x86 and ARM systems are vulnerable. On x86 systems, only HVM guests can leverage the vulnerability. MITIGATION == On x86, specifying "hap_1gb=0 hap_2mb=0" on the hypervisor command line will avoid the vulnerability. Alternatively, running all x86 HVM guests in shadow mode will also avoid this vulnerability. (For example, by specifying "hap=0" in the xl domain configuration file.) There is no known mitigation on ARM systems. CREDITS === This issue was discovered by Julien Grall of ARM. RESOLUTION == Applying the appropriate pair of attached patches resolves this issue. xsa222-[12].patchxen-unstable xsa222-1.patch, xsa222-2-4.8.patch Xen 4.8.x xsa222-[12]-4.7.patchXen 4.7.x xsa222-[12]-4.6.patchXen 4.6.x xsa222-1-4.6.patch, xsa222-2-4.5.patch Xen 4.5.x $ sha256sum xsa222* 8bd8807ee1cfe01c86194f5d5be38618ba5e0c1206667bb119ed952e5d155c1a xsa222-1.patch 9288dfcae1f37e6c8f13910046f43ec161710abb7c94a9346b7e0eaba3258ccd xsa222-1-4.6.patch ebc2c070bad8012a196e984b568a72e013ff072bb077870508f09ed053c1a4c2 xsa222-1-4.7.patch ee320b37b365cb3b6660e559902ff8bb50657b2a28ff0fa7ebaf9ffd33fc0942 xsa222-2.patch 97768f4fe564f702de8e4aebd0c4d24858814ebbb7be532b376cfae7ad6834a4 xsa222-2-4.5.patch 4142f76673b996b65301d52216cbf56e27b0c86e5607f6a9eb18dcc7df3f6343 xsa222-2-4.6.patch a640e190b32e82f5ec7ee4968bf8b9f22137e8379314cc9a29556637c3dc8e87 xsa222-2-4.7.patch ab43bd590139bed53957b3b37b854183c69bee26cf7cb00900e3f4a150d067a5 xsa222-2-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZSQ3UAAoJEIP+FMlX6CvZUd8H/0Lre7nvQJ+AWb5f9ztcOHcM Yi+ztFhfKhi9eLrJTGSQqso5rf4Fqf96E+J0UKV5eiI4/u/tRYdhb2kVsv0cwmWR 8npcnpsacTqIzPttTtwiJ4pCh7JM5/OMmEJtuBZHqgw21nCOzIEQjPJTsW0nnnfq uh20P15sf8ag1mT0N17WuNV1mxdbS6ZqpZMwTYSJfp409oXftsfBkHeH1a9ajdf/ yFZbJQpJ9eizRfZSxmSGMa02V90zQp9vnHhMm1hpy+RrywRysfAVwv4cfIeduo1t 6R3qS+2gAR5YgDvISurBJLAcK1Q0p1qxH5JQd3sYCOPeX3qbbvZ2wDmqPclxa4s= =iwX3 -END PGP SIGNATURE- xsa222-1.patch Description: Binary data xsa222-1-4.6.patch Description: Binary data xsa222-1-4.7.patch Description: Binary data xsa222-2.patch Description: Binary data xsa222-2-4.5.patch Description: Binary data xsa222-2-4.6.patch Description: Binary data xsa222-2-4.7.patch Description: Binary data xsa222-2-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 213 (CVE-2017-8903) - x86: 64bit PV guest breakout via pagetable use-after-mode-change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-8903 / XSA-213 version 3 x86: 64bit PV guest breakout via pagetable use-after-mode-change UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = 64-bit PV guests typically use separate (root) page tables for their kernel and user modes. Hypercalls are accessible to guest kernel context only, which certain hypercall handlers make assumptions on. The IRET hypercall (replacing the identically name CPU instruction) is used by guest kernels to transfer control from kernel mode to user mode. If such an IRET hypercall is placed in the middle of a multicall batch, subsequent operations invoked by the same multicall batch may wrongly assume the guest to still be in kernel mode. If one or more of these subsequent operations involve operations on page tables, they may be using the wrong root page table, confusing internal accounting. As a result the guest may gain writable access to some of its page tables. IMPACT == A malicious or buggy 64-bit PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All 64-bit Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION == Running only HVM or 32-bit PV guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa213.patch xen-unstable xsa213-4.8.patch Xen 4.8.x xsa213-4.7.patch Xen 4.7.x xsa213-4.6.patch Xen 4.6.x xsa213-4.5.patch Xen 4.5.x $ sha256sum xsa213* cddea5eac2ad1f5a68b561da4e98afce891189a2fdedf93087a03889e9df6e99 xsa213.patch fce9bbc9fc30769dfbab4d1830d87d22b2742e5e70aac22f3e9d013b7614 xsa213-4.5.patch dce026ed1a02db1cf22de89120e7129839f656d041379c450e7403ae909e7b99 xsa213-4.6.patch d8202db5981e2f13d9942332cd3fefded98a5cbc302caee431c7a15051887e7f xsa213-4.7.patch 20c12810ac73809ba74cfde811d420b1b544a07f759c393380afde1a09eb5274 xsa213-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZFZInAAoJEIP+FMlX6CvZq7YIAL4qV4jk+XHwuTSPp/3DyOgX CSwDduXqwdeUTfc+1qn6yQFiDxOMVUUUq8Qq1j+x6QrcBocJ6qNJNXhHdExbJ9Aa VPMkf1c+WbuoqOy5BHgnVkTLbCjUzDknQmDBJF4JjADsFpWaIzaXXmLG7GLwSaaf XIYIRcqa51XYSA32E0nvn+AC5OQCx7Pt5jQwRnQFfWH4e79abbI/2jNci3Xe7vfa TmUFlmTEZ3qZ5WNL0+vW4qF/fwwLya9E3IqtqBKYf5BmI369dC9tQs4ELleJ1mqi pj+81RnpVMeQlmYkt+31zP1Hzn/zBdF19yDzpBmvRZJYrF/I6rd+8mYXa8k5H5g= =KN3M -END PGP SIGNATURE- xsa213.patch Description: Binary data xsa213-4.5.patch Description: Binary data xsa213-4.6.patch Description: Binary data xsa213-4.7.patch Description: Binary data xsa213-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 214 (CVE-2017-8904) - grant transfer allows PV guest to elevate privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-8904 / XSA-214 version 3 grant transfer allows PV guest to elevate privileges UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = The GNTTABOP_transfer operation allows one guest to transfer a page to another guest. The internal processing of this, however, does not include zapping the previous type of the page being transferred. This makes it possible for a PV guest to transfer a page previously used as part of a segment descriptor table to another guest while retaining the "contains segment descriptors" property. If the destination guest is a PV one of different bitness, it may gain access to segment descriptors it is not normally allowed to have, like 64-bit code segments in a 32-bit PV guest. If the destination guest is a HVM one, that guest may freely alter the page contents and then hand the page back to the same or another PV guest. In either case, if the destination PV guest then inserts that page into one of its own descriptor tables, the page still having the designated type results in validation of its contents being skipped. IMPACT == A malicious pair of guests may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. MITIGATION == Running only one out of the three relevant classes of guest (namely: 32-bit PV; 64-bit PV; HVM) on any given host will avoid the vulnerability. (Note that this must also include any nonprivileged service domains such as stub device model domains.) The vulnerability can also be avoided if all guest kernels are controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa124.patch xen-unstable, Xen 4.8.x, 4.7.x, 4.6.x, 4.5.x $ sha256sum xsa214* 1c038c3927d08e6abdf3ce320bb8b0b68a106e6ac86b4e8194035dc5e4726d64 xsa214.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZFZIpAAoJEIP+FMlX6CvZHfsH+wdMlBxYgNB8pf405BLp6Jxy rv/8/cZjOYvIfHL3L4DnwROJ351AC4G3Yja1PqCl6/XFCuMYLIWlYknFAjE4kPTf lvvjYiogMR9SD60odieh5fqZdEBq2jIAD6h0Wn2klb5B3U3T5DdIgOOGnhz+OqX7 /clQEWJsDD9sVmEO46weZxgIiOkTLyBBbrXE3+y4qdwEbo+yhLkFj7nKpA+v8NxZ heOKALALSW7OtYy2Zr2B4+n1FQyeqsyovl3YPK4MKB5BYDBboDUBuPn2YCYCa4JY UBIL4ZsWsqBUouVqccVvOUIF1PMr8lyB7+xopSOTC23/pTrT3gAetKUVxxB6uqI= =CGId -END PGP SIGNATURE- xsa214.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 215 (CVE-2017-8905) - possible memory corruption via failsafe callback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2017-8905 / XSA-215 version 3 possible memory corruption via failsafe callback UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = Under certain special conditions Xen reports an exception resulting from returning to guest mode not via ordinary exception entry points, but via a so call failsafe callback. This callback, unlike exception handlers, takes 4 extra arguments on the stack (the saved data selectors DS, ES, FS, and GS). Prior to placing exception or failsafe callback frames on the guest kernel stack, Xen checks the linear address range to not overlap with hypervisor space. The range spanned by that check was mistakenly not covering these extra 4 slots. IMPACT == A malicious or buggy 64-bit PV guest may be able to modify part of a physical memory page not belonging to it, potentially allowing for all of privilege escalation, host or other guest crashes, and information leaks. VULNERABLE SYSTEMS == 64-bit Xen versions 4.6 and earlier are vulnerable. Xen versions 4.7 and later are not vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. Only x86 systems with physical memory extending to a configuration dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are actually affected depends on actual physical memory layout. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION == Running only HVM or 32-bit PV guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa215.patch Xen 4.6.x, Xen 4.5.x $ sha256sum xsa215* 5be4ff661dd22890b0120f86beee3ec809e2a29f833db8c48bd70ce98e9691ee xsa215.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZFZIqAAoJEIP+FMlX6CvZQUoIAMBeK3zz4qoOtlR92dLGyYkT PlITMMsz1PbkZapt/pdsuQFVRC0P7UXdJ/u1GjJLJqOBSsUOnlJ9m9uTjDW7KJTm 5Dch1lYO0npQLAcpr32KvDGDFt5dp+Cqn0NiGFV4yFsdMLnhW8Wyugc8DhJgVcv9 2PPZ5IlFFlrdCs4g6jMFy7rdM/r6d6wyPQukE6L0VObHv5MsqVgg+p01/yk/uDaz KHSlHdfAfuxpMbKPZ2cz/rWQYN2xwV6foZ2pn1WHQln9NxXzQWSR8J5KZj3BLXME +i1cg/aRm3jHM+SZDRXwton51SAkTpCYW5/n+QqbGJd7NN6+GMk14t8Y3wKSZVA= =skSs -END PGP SIGNATURE- xsa215.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 214 - grant transfer allows PV guest to elevate privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-214 version 2 grant transfer allows PV guest to elevate privileges UPDATES IN VERSION 2 Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION = The GNTTABOP_transfer operation allows one guest to transfer a page to another guest. The internal processing of this, however, does not include zapping the previous type of the page being transferred. This makes it possible for a PV guest to transfer a page previously used as part of a segment descriptor table to another guest while retaining the "contains segment descriptors" property. If the destination guest is a PV one of different bitness, it may gain access to segment descriptors it is not normally allowed to have, like 64-bit code segments in a 32-bit PV guest. If the destination guest is a HVM one, that guest may freely alter the page contents and then hand the page back to the same or another PV guest. In either case, if the destination PV guest then inserts that page into one of its own descriptor tables, the page still having the designated type results in validation of its contents being skipped. IMPACT == A malicious pair of guests may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. MITIGATION == Running only one out of the three relevant classes of guest (namely: 32-bit PV; 64-bit PV; HVM) on any given host will avoid the vulnerability. (Note that this must also include any nonprivileged service domains such as stub device model domains.) The vulnerability can also be avoided if all guest kernels are controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa124.patch xen-unstable, Xen 4.8.x, 4.7.x, 4.6.x, 4.5.x $ sha256sum xsa214* 1c038c3927d08e6abdf3ce320bb8b0b68a106e6ac86b4e8194035dc5e4726d64 xsa214.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZCGsBAAoJEIP+FMlX6CvZtvQH/i2VsJ5AIku19/0AfiuVA6WN WOu6TBGsaLTAXZHM/CPAOYuPHJ2dQlXRB+avo/Wu8MpuYIVrSarlfED8puDgwO2t vZp8k5KMV4hWY7EYWYuhMvJVgNK2kjRIsM8g4T56Tc8waQdFBVH1ODEFLOdTT2jf gVuEjV9vpdzW994N38QRLYuaaQwLGPf9yAx1pgcMr1K3qzcOOBiNqCtb1amYo84i e/xXSV7Y87/mZxsq23ZhrRgTogiIeZO3LnLnYyYqplTGNKZli6RyvlpLzADQNdae lpvLGHLRuIiLEFBqhINVDshRHu2cp346dOTTS8bjEfFD/d5NBUYjddP2QogqCqo= =g4Jg -END PGP SIGNATURE- xsa214.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 215 - possible memory corruption via failsafe callback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-215 version 2 possible memory corruption via failsafe callback UPDATES IN VERSION 2 Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION = Under certain special conditions Xen reports an exception resulting from returning to guest mode not via ordinary exception entry points, but via a so call failsafe callback. This callback, unlike exception handlers, takes 4 extra arguments on the stack (the saved data selectors DS, ES, FS, and GS). Prior to placing exception or failsafe callback frames on the guest kernel stack, Xen checks the linear address range to not overlap with hypervisor space. The range spanned by that check was mistakenly not covering these extra 4 slots. IMPACT == A malicious or buggy 64-bit PV guest may be able to modify part of a physical memory page not belonging to it, potentially allowing for all of privilege escalation, host or other guest crashes, and information leaks. VULNERABLE SYSTEMS == 64-bit Xen versions 4.6 and earlier are vulnerable. Xen versions 4.7 and later are not vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. Only x86 systems with physical memory extending to a configuration dependent boundary (5Tb or 3.5Tb) may be affected. Whether they are actually affected depends on actual physical memory layout. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION == Running only HVM or 32-bit PV guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa215.patch Xen 4.6.x, Xen 4.5.x $ sha256sum xsa215* 5be4ff661dd22890b0120f86beee3ec809e2a29f833db8c48bd70ce98e9691ee xsa215.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZCGsCAAoJEIP+FMlX6CvZulUH/38S+01LCZXAyAiPQTKGtJ09 QZeqIriU1rFn/jXWvxnlC2eaKmrZvucOtYWK5Uccmj49Y2lgvoxTqSCa0S86POWU xvwBH2nGMsJ0Q4m1qQ4fZQ3lSsRlRoz0FyeTwdjdGlGVqGqPhDqB7Nm68IyOjr5j zhIxl8WCQulaqlWwCIgR+KQEgbyVDdsqmOYq7vIrYvyEEtM98l2sQ4E5kO3QfxUV aRbUBH4XrleGYNXQE3kXCNBJJIxl8LwsIHvk55hWAjEwmdRbu8o4+eBNn+lvDzQb +AEMk1VrDMYCsxB6bUryJm6AzNc69vBNsdgGo4o0UXZtrfhtyBsEXD6daWqu3/c= =zQpX -END PGP SIGNATURE- xsa215.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 213 - x86: 64bit PV guest breakout via pagetable use-after-mode-change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-213 version 2 x86: 64bit PV guest breakout via pagetable use-after-mode-change UPDATES IN VERSION 2 Public release. Added email header syntax to patches, for e.g. git-am. ISSUE DESCRIPTION = 64-bit PV guests typically use separate (root) page tables for their kernel and user modes. Hypercalls are accessible to guest kernel context only, which certain hypercall handlers make assumptions on. The IRET hypercall (replacing the identically name CPU instruction) is used by guest kernels to transfer control from kernel mode to user mode. If such an IRET hypercall is placed in the middle of a multicall batch, subsequent operations invoked by the same multicall batch may wrongly assume the guest to still be in kernel mode. If one or more of these subsequent operations involve operations on page tables, they may be using the wrong root page table, confusing internal accounting. As a result the guest may gain writable access to some of its page tables. IMPACT == A malicious or buggy 64-bit PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All 64-bit Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION == Running only HVM or 32-bit PV guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa213.patch xen-unstable xsa213-4.8.patch Xen 4.8.x xsa213-4.7.patch Xen 4.7.x xsa213-4.6.patch Xen 4.6.x xsa213-4.5.patch Xen 4.5.x $ sha256sum xsa213* cddea5eac2ad1f5a68b561da4e98afce891189a2fdedf93087a03889e9df6e99 xsa213.patch fce9bbc9fc30769dfbab4d1830d87d22b2742e5e70aac22f3e9d013b7614 xsa213-4.5.patch dce026ed1a02db1cf22de89120e7129839f656d041379c450e7403ae909e7b99 xsa213-4.6.patch d8202db5981e2f13d9942332cd3fefded98a5cbc302caee431c7a15051887e7f xsa213-4.7.patch 20c12810ac73809ba74cfde811d420b1b544a07f759c393380afde1a09eb5274 xsa213-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJZCGr/AAoJEIP+FMlX6CvZ+s8IALroAx1MO5vn6Z0LY2noH+B3 LP32EfS6jzA210jXT1txfjEIFta7In03nCv3KQZZmvFWjIiDTBD/N8THg9XQHC0r R+FC0yTFXnLNluBY5FqOXf7C7pd3+N+onAMsRIJkaJiDMIL+xtfnLOTFpr9FrVSy pemRRr1vZuekeph7G446R04lXBCn5pRMj/v1abXjhAFq1leW9hI3vZII/oRpPUCF BCJysglvQEgk7Qh3Iqhi8nuqAj+IHxGD3udhsruwruzQ+u2XCLA5FeYo0GK+e9AF aSf+GL9lZIfVj+2v754Gh6xXSe2K/+Ok/8S5FRJQrGD+vQL+UUGT7GTfJEAPvYg= =meSL -END PGP SIGNATURE- xsa213.patch Description: Binary data xsa213-4.5.patch Description: Binary data xsa213-4.6.patch Description: Binary data xsa213-4.7.patch Description: Binary data xsa213-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 212 (CVE-2017-7228) - x86: broken check in memory_exchange() permits PV guest breakout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-7228 / XSA-212 version 3 x86: broken check in memory_exchange() permits PV guest breakout UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The XSA-29 fix introduced an insufficient check on XENMEM_exchange input, allowing the caller to drive hypervisor memory accesses outside of the guest provided input/output arrays. IMPACT == A malicious or buggy 64-bit PV guest may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 systems are affected. ARM systems are not vulnerable. The vulnerability is only exposed to 64-bit PV guests. HVM guests and 32-bit PV guests can't exploit the vulnerability. MITIGATION == Running only HVM or 32-bit PV guests will avoid the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jann Horn of Google Project Zero. RESOLUTION == Applying the attached patch resolves this issue. xsa212.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa212* be1255bcda06158cdb86eb5297e8a271e05318e88cd21035c58a67f9ada6ccba xsa212.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJY45NxAAoJEIP+FMlX6CvZMRMH/jGfTS4hcPuPAiarYhD4D4YQ pVir0eM/gm/8yJE/CT3m3dieKjjl+GAFW4ehRMoIoxVdSlhiwskx5V+8I5qR/Lo6 6F9BPJw6eaEM62yw7YvMl7EuSexP3WgQeyRSf3BckZ0oxEPSHrIUi0/p0B7FNOFr C1EqK9d08dMKA5AEugpXgDI0t7fbYg3Kkm8SVnW5B8+5OI/iyTOOkFoPx1sbEvWX k+zgzodsDuoh8O25+pKVs+verknzGJm9UdCD7vHW8elLg1+1nS2BlfTSr478cDTE FnbnpuE7r1X/HHd2hPHDAZu3g2IUqfBJCLeYZfhIM9Eioei6bVLXh0f33DvlH/U= =L74k -END PGP SIGNATURE- xsa212.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 211 (CVE-2016-9603) - Cirrus VGA Heap overflow via display refresh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9603 / XSA-211 version 2 Cirrus VGA Heap overflow via display refresh UPDATES IN VERSION 2 Patches for qemu-xen-traditional. Public release. ISSUE DESCRIPTION = When a graphics update command gets passed to the VGA emulator, there are 3 possible modes that can be used to update the display: * blank - Clears the display * text - Treats the display as showing text * graph - Treats the display as showing graphics After the display geometry gets changed (i.e., after the CIRRUS VGA emulation has resized the display), the VGA emulator will resize the console during the next update command. However, when a blank mode is also selected during an update, this resize doesn't happen. The resize will be properly handled during the next time a non-blank mode is selected during an update. However, other console components - such as the VNC emulation - will operate as though this resize had happened. When the display is resized to be larger than before, this can result in a heap overflow as console components will expect the display buffer to be larger than it is currently allocated. IMPACT == A privileged user within the guest VM can cause a heap overflow in the device model process, potentially escalating their privileges to that of the device model process. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Only HVM guests with the Cirrus video card are vulnerable. (The Cirrus video card is the default.) Both qemu-upstream and qemu-traditional are vulnerable. For HVM guests with the device model running in a stub domain, "the privileges of the device model process" are identical to those of the guest kernel. But the ability of a userspace process to trigger this vulnerability via legitimate commands to the kernel driver (thus elevating its privileges to that of the guest kernel) cannot be ruled out. MITIGATION == Running only PV guests, or running HVM guests with the stgvga driver, will avoid this vulnerability. Running HVM guests with stub domains will mitigate the vulnerability to at most a guest kernel privilege escalation. CREDITS === The discoverer of this issue requested to remain anonymous. RESOLUTION == Applying the appropriate attached patch resolves this issue (and any further bitblit vulnerabilities) by disabling the bitblit functionality from the Cirrus VGA device entirely. xsa211-qemuu.patch qemu-upstream master xsa211-qemuu-4.8.patch qemu-upstream 4.8 xsa211-qemuu-4.7.patch qemu-upstream 4.7 xsa211-qemuu-4.6.patch qemu-upstream 4.6 and 4.5 xsa211-qemuu-4.4.patch qemu-upstream 4.4 xsa211-qemut.patch qemu-xen-traditional 4.6 and later xsa211-qemut-4.5.patch qemu-xen-traditional 4.4 and 4.5 $ sha256sum xsa211* 9d0cf413dcc9654ee95f6b04fa9c5714f36775cbc9ab0390a3041ec4a68845ab xsa211-qemut.patch d307d67fbf3707a324da537e593702eaff3df2068b559ef19e857b493881155e xsa211-qemut-4.5.patch 0fe17378cf2bc2742f068adf31331f36e01b0f4ffa9c596160fdba2bed3e870a xsa211-qemuu.patch 1808aa443123d8713241a60021507a4d9c142c3cd07233e2f38e9b9b28025ae2 xsa211-qemuu-4.4.patch 5053c7cb392f34a234287092293bb91f261ed68f4b58fe856fe353b647ed5beb xsa211-qemuu-4.6.patch c5884bd441ae8cecce84385c99bcb72ba0eae480a013846fa59c1255aef4808f xsa211-qemuu-4.7.patch bea7cf4065bd9d0085f4dfc3395e59c3ca9d4de9d786a3018c8dc7fd9f3d8b6e xsa211-qemuu-4.8.patch $ NOTE REGARDING EMBARGO == The embargo period is much shorter than our standard two-week period. This is at the request of the discoverer. DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or the mitigation of running with an HVM stub domain (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. It is NOT permitted during the embargo to switch from Cirrus VGA to Stdvga on public-facing systems with untrusted guest users or administrators. This is because it may give a clue where the issue lies. This mitigation is only permitted AFTER the embargo ends. As always, distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1
[Xen-devel] Xen Security Advisory 210 - arm: memory corruption when freeing p2m pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-210 arm: memory corruption when freeing p2m pages ISSUE DESCRIPTION = When freeing pages used for stage-2 page tables, the freeing routine failed to remove these pages from an internally managed list they were put on during allocation. The same list node elements are also used by the hypervisor's page allocator. Subsequent manipulation of ARM's private P2M list could therefore corrupt the lists maintained by the page allocator. The buggy code is exposed to guests via the XENMEM_decrease_reservation hypercall. IMPACT == A malicious or buggy guest may corrupt hypervisor state, commonly leading to a host crash (Denial of Service). Privilege escalation or information leaks cannot be excluded. VULNERABLE SYSTEMS == Only Xen version 4.8 is affected. Xen versions 4.7 and earlier are not vulnerable. Only ARM systems are vulnerable. X86 based systems are not vulnerable. MITIGATION == There is no known mitigation. NOTE REGARDING LACK OF EMBARGO == The issue was discussed publicly before being recognized as a security issue. RESOLUTION == Applying the attached patch resolves this issue. xsa210.patch xen-unstable, Xen 4.8.x $ sha256sum xsa210* 10e26c017c916dcac261c6a3c92656831f0ad037f792940e6faf6905c6e23861 xsa210.patch $ CREDITS === The initial bug was discovered by Vijay Kilari of Cavium and the security aspect was diagnosed by Julien Grall of ARM. DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYrw2aAAoJEIP+FMlX6CvZuw4H/34z2io/65h2RLDL3bx4w//A nWNcrceKrxyvtZmTss56RHrUeiOOKOeuCXWMx5CSihBcSRXqyZa79IDul9t1b7fB m6NUPerILGueF3uOYTRUvvSiWKWRzVPOCgqSxlCmd7YTrkjHZkq/x2Gb9Acj3hrl yE0fFdD/hTIN9wZtHWY+gTIXMIGHBJ4/xieZeYZvylbnmu9nDC0WIupTExonWqie sG0DICl+eKJMt3ioSzaGd9117Xk1P7JWvcr7MJQvzn/2VDTG2TjC4kZE1iDHHVPz +txQh2G2Luf+jX5VQSqWnlv7I9zuGlqYEpAMQacjrLzGejuqPSC2kbzliOEoCaE= =1k3w -END PGP SIGNATURE- xsa210.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 209 (CVE-2017-2620) - cirrus_bitblt_cputovideo does not check if memory region is safe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-2620 / XSA-209 version 4 cirrus_bitblt_cputovideo does not check if memory region is safe UPDATES IN VERSION 4 Include a prerequisite patch for qemu-upstream, correct statement regarding the availability of a qemu-traditional patch. ISSUE DESCRIPTION = In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine cirrus_bitblt_cputovideo fails to check wethehr the specified memory region is safe. IMPACT == A malicious guest administrator can cause an out of bounds memory write, very likely exploitable as a 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. CREDITS === This issue was discovered by Gerd Hoffmann of Red Hat. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa209-qemuu/*.patch qemu-xen, qemu upstream xsa209-qemut.patch qemu-xen-traditional $ sha256sum xsa209* xsa209*/* 167af9ed7163fa7cf4abb52f865290ced3163c7684151bdc1324eb5e534faf13 xsa209-qemut.patch e698b73d8de24af0fe33968a43561e5e1d094f4caf2443caa447b552677d2683 xsa209-qemuu/0001-display-cirrus-ignore-source-pitch-value-as-needed-i.patch 50c60e45151ef2265cce4f92b204e9fd75f8bc8952f097e77ab4fe1c1446bc98 xsa209-qemuu/0002-cirrus-add-blit_is_unsafe-call-to-cirrus_bitblt_cput.patch DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However, deployment of the "stdvga" mitigation (changing the video card emulation to stdvga) is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because this produces a guest-visible change which will indicate which component contains the vulnerability. Additionally, distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYrwN/AAoJEIP+FMlX6CvZQoQIAK9UiN9VwXv1I0E7X1TL2TjE P9SNXkI5wKiwCq22pbz9pjBO//ia3M5UoxpDMwaMAQzn9bEThHnki8x2njRxIEF7 frxm6B8DpHLCoRHiqgwi018JHLLcSbr+KQrZqBns1j5BfOF0in89A8cgBmQrziyX bj9853Q8dHSUNW1vi8vZkMacIwxMCg4sBLjSRUoqiWmoyfU6XodRwZ3LoglsofTj /jk/G5OiitqXDBPzvclPRddQ53xiN9eN3fV8IdG6QpX6F+C2qQVDyS8kAqqFmmm6 Vn6yl9UxrmP0OmvQ5CgUw8GWQoY3OqObjiPgfNUdbN+CLjdhdGfF3kGuYIniqd4= =I92f -END PGP SIGNATURE- xsa209-qemut.patch Description: Binary data xsa209-qemuu/0001-display-cirrus-ignore-source-pitch-value-as-needed-i.patch Description: Binary data xsa209-qemuu/0002-cirrus-add-blit_is_unsafe-call-to-cirrus_bitblt_cput.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 209 (CVE-2017-2620) - cirrus_bitblt_cputovideo does not check if memory region is safe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-2620 / XSA-209 version 3 cirrus_bitblt_cputovideo does not check if memory region is safe UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = In CIRRUS_BLTMODE_MEMSYSSRC mode the bitblit copy routine cirrus_bitblt_cputovideo fails to check wethehr the specified memory region is safe. IMPACT == A malicious guest administrator can cause an out of bounds memory write, very likely exploitable as a 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. CREDITS === This issue was discovered by Gerd Hoffmann of Red Hat. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa209-qemuu.patch qemu-xen, qemu upstream (no backport yet)qemu-xen-traditional $ sha256sum xsa209* 167af9ed7163fa7cf4abb52f865290ced3163c7684151bdc1324eb5e534faf13 xsa209-qemut.patch 297578aa43c3e6b21333f1b859fd1d3e68e77b3cadbadd20cfeca8426df3 xsa209-qemuu.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However, deployment of the "stdvga" mitigation (changing the video card emulation to stdvga) is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because this produces a guest-visible change which will indicate which component contains the vulnerability. Additionally, distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYrBl3AAoJEIP+FMlX6CvZ6LMIALETwnX9w8SifkvuYY3jotwp nQWY8ztJkMnai9X10RN6SeVf2dCpXLhATPuPGORgRiZJEuBaGHEsHa00i63FQBSL PaOAgzN1GY+u16Ygv2e3vPcN8mO55A6zcFErF2oLsrfdNsG4pJTwn7bMEjZiqSyG R9xIC6KiA1nojsZO+ynmRvHxFP6epySRayO0PZAGS75LdmEKVxClE3dAeMW77WNv dAs3Qi14hB5BmdryK5f1STk8r2b3UsN1pbvao8odiEWFaB9tPo273gj5RdfnEV3t EzTvH37Q3C4YFoTFx8p6fY5ejHNh4AeSyi9yE7lWtKhDZw56UhdfMmYIgDaKpig= =RBpg -END PGP SIGNATURE- xsa209-qemut.patch Description: Binary data xsa209-qemuu.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 207 - memory leak when destroying guest without PT devices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-207 version 2 memory leak when destroying guest without PT devices UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = Certain internal state is set up, during domain construction, in preparation for possible pass-through device assignment. On ARM and AMD V-i hardware this setup includes memory allocation. On guest teardown, cleanup was erroneously only performed when the guest actually had a pass-through device assigned. IMPACT == A malicious guest may, by frequently rebooting over extended periods of time, run the system out of memory, resulting in a Denial of Service (DoS). The leak is no more than 4kbytes per guest boot. VULNERABLE SYSTEMS == Xen versions 3.3 and later are affected. ARM systems, and x86 AMD systems, are affected. Intel systems, and systems without IOMMU/SMMU hardware, are unaffected. All guest kinds can exploit this vulnerability. MITIGATION == Limiting the frequency with which a guest is able to reboot, will limit the memory leak. Rebooting each host (after migrating its guests) periodically will reclaim the leaked space. CREDITS === This issue was discovered by Oleksandr Tyshchenko of EPAM Systems. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa207.patch xen-unstable, Xen 4.8.x, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x xsa207-4.4.patch Xen 4.4.x $ sha256sum xsa207* e9bcf807b3785ac4d78b621fba4a9395cd713d6e57cdaa66559bccf95ded1cd9 xsa207.patch 5f391cc621d619ee33c90398bda24588ebf8320750db4545677bb5222150ae6d xsa207-4.4.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above is permitted during the embargo, as is the mitigation of migrating a VM which has no devices assigned from IOMMU-capable hardware to IOMMU-incapable hardware, even on public-facing systems with untrusted guest users and administrators. HOWEVER, moving a VM from AMD to Intel hardware, in response to this vulnerability, is *not* permitted. This is because such a change is visible to guests, and would not normally be expected. Furthermore: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYpEP+AAoJEIP+FMlX6CvZPrMIAL7ULaO/oOicZzGHzMO0f1r6 MZDBPeLAg5EQ3oGl1oZenlEEQgSflzj2YHdwjdps2kZpJBaRJjNPmqOC3ZxetlyF +cEJWpw6u0IDRzukEWkQlFGQS68ShLjRcKWDi5+ftjo4rFh34uybrgRv7/nKtiuG ZLX7dqKZuqYBSYvSXjA8UejB//psGOu4jqNh15t0bxtQqc5BlgdJebOkKlgrxL2M BqI/kiZoRuKkDVBu2786oo3w8BCjyBktDR0B9dzRY6MEdTXqb+mE8IO7G492KQTk /ZW9rKeijauKLNgsSkZlqtA0TPTp7tujh9XxE/JfB8UcYFez86NWoBBY4g+Q3SQ= =kwFG -END PGP SIGNATURE- xsa207.patch Description: Binary data xsa207-4.4.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 208 (CVE-2017-2615) - oob access in cirrus bitblt copy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2017-2615 / XSA-208 version 2 oob access in cirrus bitblt copy UPDATES IN VERSION 2 Included backport for qemu-xen versions 4.7 (and earlier); fixed qemu-xen-traditional patch. Also included proper (non-obscured) e-mail addresses from upstream patch. Removed "possibly" from Impact. 3 patches updated 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, 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 mainline qemu, qemu-xen master,4.8 xsa208-qemuu-4.7.patch qemu-xen 4.4, 4.5, 4.6, 4.7 xsa208-qemut.patch qemu-xen-traditional $ sha256sum xsa208* afde3e9d4bf5225f92c36dec9ff673b0b1b0bad4452d406f0c12edc85e2fec72 xsa208-qemut.patch e492d528141be5899d46c2ac0bcd0c40ca9d9bfc40906a8e7a565361f17ce38d xsa208-qemuu.patch 09471b66c9d9fc5616e7b96ab67bbb51987e7d9520d1b81cb27cbbb168659ad5 xsa208-qemuu-4.7.patch $ NOTE REGARDING LACK OF EMBARGO == This issue has already been publicly disclosed. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYofdiAAoJEIP+FMlX6CvZ3UEIAMJUV177OqZ0O7436zYpM9S+ fEku8b/G7npRcm0L9PtD8PG39IVtqrtIDHIpzMxHA0qbMx3PqWp1G3iBVwFnj21e ALtKjdNaoDA8nqFEQ3/AbyZ7jn91oYWwmJ7+pKGds+Q+juFof6FVOXCjhNp0XSA6 EDvsz8vOI4fWTtEuVGbg1GnvgEAjKLE9/bE/4zdkWo2WSiWRRCj/yEAr5n0v0R5n 0EEvk21H0XESk2zBk0/UxompNuqbHwOZhBkQ65DxNSkWMIA9hUgqyinR674luHKC mDkAq8bXar6n1TBQCbWq5f/+50FOApEs0EvJuzWAG7MEkFPaeDSilFb6obhxHjo= =294C -END PGP SIGNATURE- xsa208-qemut.patch Description: Binary data xsa208-qemuu.patch Description: Binary data xsa208-qemuu-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 208 (CVE-2017-2615) - oob access in cirrus bitblt copy
-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.patchqemu-xen, mainline qemu xsa208-qemut.patchqemu-xen-traditional $ sha256sum xsa208* 4369cce9b72daf2418a1b9dd7be6529c312b447b814c44d634bab462e80a15f5 xsa208-qemut.patch 1e516e3df1091415b6ba34aaf54fa67eac91e22daceaad569b11baa2316c78ba xsa208-qemuu.patch $ NOTE REGARDING LACK OF EMBARGO == This issue has already been publicly disclosed. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYnbVQAAoJEIP+FMlX6CvZs2sIAKtkU1ptqojrE6GpgdMegdIS hMcCcEVdDoYt47z9BxXcNA87kyjGLbIaliACF3GQclhBy8f6Ytm6MLQMvh79YO/l 8AvZELKSo5U/Z1El/HQ/ezzWTV15FHwdG64HvDf7SdlRquVyS0fxWLuiq8gmWXRd bpGcbAwwdRHvrvguMpajif89ZfTWPSHRq8onS1C96SBJW8aUXxzzyKWoX1EvNWN3 vnKC5eXQ5uhLERmh6meIZo2OwB7PlMTuasgVJan915/CGF8CS+B5wqQmiL0uxfRT fnTBVTfXHC/TzkkREJtnwgHIEv/E+Vygheeg/2P9bEaNkiN3CG5kK/ZOxgWNYU4= =eEKh -END PGP SIGNATURE- xsa208-qemut.patch Description: Binary data xsa208-qemuu.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 202 (CVE-2016-10024) - x86 PV guests may be able to mask interrupts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-10024 / XSA-202 version 3 x86 PV guests may be able to mask interrupts UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Certain PV guest kernel operations (page table writes in particular) need emulation, and use Xen's general x86 instruction emulator. This allows a malicious guest kernel which asynchronously modifies its instruction stream to effect the clearing of EFLAGS.IF from the state used to return to guest context. IMPACT == A malicious guest kernel administrator can cause a host hang or crash, resulting in a Denial of Service. VULNERABLE SYSTEMS == All Xen versions are vulnerable. Only x86 PV guests can exploit the vulnerability. Neither ARM guests nor x86 HVM guests can exploit the vulnerability. MITIGATION == Running only HVM guests will avoid the vulnerability. For PV guests the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa202.patch xen-unstable, Xen 4.8.x, Xen 4.7.x xsa202-4.6.patch Xen 4.6.x, Xen 4.5.x xsa202-4.4.patch Xen 4.4.x $ sha256sum xsa202* 057be742acfef200ba6f094a5dce486dd1c4e15013afe3efc963523ce2ec9cbb xsa202.patch cd53dc8b761dc7eb60998ea2419c98af926aa62b4317dbef15f597f5554f9015 xsa202-4.4.patch e007187639f5392a9256979504d50eff0ae38309a61524ea42c4150fab38b6f4 xsa202-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYWm8TAAoJEIP+FMlX6CvZlekIALNmG5XBvAvY3Hpjwr/h+bh6 AJNof+4jH7WUsyV8NyJxBOtAxDBeGsQ5csoryIt8CoqPfL6lph5Y0eUMAa+aOGYB FyMtWlKhyhoCjXcxhBCSAuHKldXyroZtzb6mx01nZSC8PbOCrnRzIGm/JLlnVS7b WBol9ID3DRWlI42gwpzDh3l/64Rioyyk1I26Kqal56+CT9iPk/b2UwqVb9oGQPI0 iq8Lki5NAKwOQdRxQKEFnWMuwK2bJsuayM3K0Cl/DBckvcOstMkP543btZDZA/Uy AiAOrTcBeDPmOoUVRpjwNEsFiiNeGgXV1R+FOcoZfWLdTKsn2igOtUkEekwVdAs= =SNhC -END PGP SIGNATURE- xsa202.patch Description: Binary data xsa202-4.4.patch Description: Binary data xsa202-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 203 (CVE-2016-10025) - x86: missing NULL pointer check in VMFUNC emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-10025 / XSA-203 version 3 x86: missing NULL pointer check in VMFUNC emulation UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When support for the Intel VMX VMFUNC leaf 0 was added, a new optional function pointer hvmemul_vmfunc was added to the hvm_emulate_ops table. As is intended, that new function pointer is NULL on non-VMX hardware, including AMD SVM hardware. However at a call site, the necessary NULL check was omitted before the indirect function call. IMPACT == Malicious guests may cause a hypervisor crash, resulting in a Denial of Service (DoS). VULNERABLE SYSTEMS == Xen versions 4.6 and newer are vulnerable. Xen versions 4.5 and earlier are not vulnerable. Only HVM guests can exploit the vulnerability. PV guests cannot exploit the vulnerability. Only x86 systems using SVM (AMD virtualisation extensions) rather than VMX (Intel virtualisation extensions) are vulnerable. This applies to HVM guests on AMD x86 CPUs. Therefore AMD x86 hardware is vulnerable; Intel hardware is not vulnerable. ARM systems are not vulnerable. MITIGATION == Running only PV guests will avoid this vulnerability. Running HVM guests on only VMX capable hardware will also avoid this vulnerability. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa203.patch xen-unstable xsa203-4.8.patch Xen 4.8.x xsa203-4.7.patch Xen 4.7.x, Xen 4.6.x $ sha256sum xsa203* 9af7e862705987a60de1def81ed179931c3f683d05b05c2708cf16bb85d203c9 xsa203.patch 7cc04278778fe885e4c3ae3f846d099075a38bccfafe6dff018ba525499b4e46 xsa203-4.7.patch 4218fcfff11ec4788462a3ea9dddecb25b9d9fb1beaad17ca0f723b07b6675e4 xsa203-4.8.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYWm8VAAoJEIP+FMlX6CvZid4H/RlcaSaA1qky6vTKjaW4xUiX /48Fvz3H8Ioau3Mlqy9WGqoq7HnuhJl2MUuq47vpwChOlYvvNXeRe47sVHsLwz1O /yImaOc0cZEYsyECpddsVSOdwFEMnR38WFWirH4xboGx8NjWeQg3Fsmwh1r8iHsm HyR2kRktw/Tu2hpc8BaipsYObglvLGQGy06KwwIB0MPycm20MpR4W41a5vc6iE+1 oKMIag/UD+W1eR7zWkftHnEcG+QNfbpWfU7rKPOrQSX5nuXHCXTcu6JQbzlPD8JS h+A5r+/tfyQPLTWxoBkH4wbMwdqDPNo1AuiDaGD8KWD97m/j2pFaZKl7lGk8X9w= =TUeg -END PGP SIGNATURE- xsa203.patch Description: Binary data xsa203-4.7.patch Description: Binary data xsa203-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 204 (CVE-2016-10013) - x86: Mishandling of SYSCALL singlestep during emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-10013 / XSA-204 version 2 x86: Mishandling of SYSCALL singlestep during emulation UPDATES IN VERSION 2 CVE assigned. ISSUE DESCRIPTION = The typical behaviour of singlestepping exceptions is determined at the start of the instruction, with a #DB trap being raised at the end of the instruction. SYSCALL (and SYSRET, although we don't implement it) behave differently because the typical behaviour allows userspace to escalate its privilege. (This difference in behaviour seems to be undocumented.) Xen wrongly raised the exception based on the flags at the start of the instruction. IMPACT == Guest userspace which can invoke the instruction emulator can use this flaw to escalate its privilege to that of the guest kernel. VULNERABLE SYSTEMS == All Xen versions are affected. The vulnerability is only exposed to 64-bit x86 HVM guests. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7 and later, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). A 64-bit guest kernel which uses an IST for #DB handling will most likely mitigate the issue, but will have a single unexpected #DB exception frame to deal with. This in practice means that Linux is not vulnerable. The vulnerability is not exposed to 32-bit HVM guests. This is because the emulation bug also matches real hardware behaviour, and a 32-bit guest kernel using SYSCALL will already have to be using a Task Gate for handling #DB to avoid being susceptible to an escalation of privilege. The vulnerability is not exposed to PV guests. ARM systems are not vulnerable. MITIGATION == There is no known mitigation. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa204.patch xen-unstable xsa204-4.8.patch Xen 4.8.x xsa204-4.7.patch Xen 4.7.x, Xen 4.6.x xsa204-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa204* 251c33905f86d386cc07240041108ec0664e5e9dddb2b88685d9b4b8ca7fdc24 xsa204.patch e523b65ba122c8e22d32004d2035facaf06295094fdc8b67c151b6f44799ef0b xsa204-4.5.patch d0359f26e9be783672896200e14d85a3111c29d7da580313b593fca04688fef2 xsa204-4.7.patch fa2a69682868104b6263655abbfc6b326f76deebdac3273b4b65da6673f5d977 xsa204-4.8.patch $ NOTE REGARDING EMBARGO == This issue was discussed publicly on qemu-devel before its impact was realised. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYWBMjAAoJEIP+FMlX6CvZe2wH/i/tAxpXbIc0xhhA5L6nlGJ9 fYZY0C6GuujTFIPmF40dMKIZieB+zKxiBseYHw4dHSzs3hbLbYhcP2Qgr2WJ2uJw 3zuS+OAtOlwzl+KRu6WUZPMf5JTAZp+kWJny3qCymUzXqz4OmUzsqHAORYyAjVi/ RN0lqgnkoTrGV8YS7fEUC5mB6PQGaEerJWFRLmaEmxV0th70oTuSGELjZ7rJdJg/ 92BZ/GVQNspuSgZCJyEhwSfzBgF1MvAKjUZafh9+0/2G5Ab0Z71ikRX/l8RWop9E 7B+KC6zeG6DukPME2sJTuL+b0EmZyfOwewDnbdGbzb2nCfOhwsoHvzrAhF9rYwI= =ypHy -END PGP SIGNATURE- xsa204.patch Description: Binary data xsa204-4.5.patch Description: Binary data xsa204-4.7.patch Description: Binary data xsa204-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 204 - x86: Mishandling of SYSCALL singlestep during emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-204 x86: Mishandling of SYSCALL singlestep during emulation ISSUE DESCRIPTION = The typical behaviour of singlestepping exceptions is determined at the start of the instruction, with a #DB trap being raised at the end of the instruction. SYSCALL (and SYSRET, although we don't implement it) behave differently because the typical behaviour allows userspace to escalate its privilege. (This difference in behaviour seems to be undocumented.) Xen wrongly raised the exception based on the flags at the start of the instruction. IMPACT == Guest userspace which can invoke the instruction emulator can use this flaw to escalate its privilege to that of the guest kernel. VULNERABLE SYSTEMS == All Xen versions are affected. The vulnerability is only exposed to 64-bit x86 HVM guests. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7 and later, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). A 64-bit guest kernel which uses an IST for #DB handling will most likely mitigate the issue, but will have a single unexpected #DB exception frame to deal with. This in practice means that Linux is not vulnerable. The vulnerability is not exposed to 32-bit HVM guests. This is because the emulation bug also matches real hardware behaviour, and a 32-bit guest kernel using SYSCALL will already have to be using a Task Gate for handling #DB to avoid being susceptible to an escalation of privilege. The vulnerability is not exposed to PV guests. ARM systems are not vulnerable. MITIGATION == There is no known mitigation. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa204.patch xen-unstable xsa204-4.8.patch Xen 4.8.x xsa204-4.7.patch Xen 4.7.x, Xen 4.6.x xsa204-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa204* 251c33905f86d386cc07240041108ec0664e5e9dddb2b88685d9b4b8ca7fdc24 xsa204.patch e523b65ba122c8e22d32004d2035facaf06295094fdc8b67c151b6f44799ef0b xsa204-4.5.patch d0359f26e9be783672896200e14d85a3111c29d7da580313b593fca04688fef2 xsa204-4.7.patch fa2a69682868104b6263655abbfc6b326f76deebdac3273b4b65da6673f5d977 xsa204-4.8.patch $ NOTE REGARDING EMBARGO == This issue was discussed publicly on qemu-devel before its impact was realised. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYV/5uAAoJEIP+FMlX6CvZnxgIAMXcpEN0qejTe50dAP/gSzzP edi76o/LNGaQBdFRVLvIasRna2TZSXhBNbHPEcAQLPq6pTfQG/HiqdVtftaaaoaG dvNhuDBdZaa1/fmhCV1P+t9vaipp3U3yK2s0eiSJLXp3nGqkgjSSmZloYY0bevDN DJ0uZ7uWkvyN6Tkl6R/h3h9PsgIKPIQBIyBuT2zYPf/JAjBD27ZYX11F9JvVMmt3 JH/AbvJwUsaqNG3teLg+tioQPwHwkZCdxOhG+v2Y3CeqQ1bvNCb5emLtpXFO9h0w kZNh88gT1mwbxDWbF3Ek/OhHbOHosfxi9kn8ib5Yu0P8xRmvYhQHMeQDa/rt9Y0= =OVcU -END PGP SIGNATURE- xsa204.patch Description: Binary data xsa204-4.5.patch Description: Binary data xsa204-4.7.patch Description: Binary data xsa204-4.8.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 200 (CVE-2016-9932) - x86 CMPXCHG8B emulation fails to ignore operand size override
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9932 / XSA-200 version 3 x86 CMPXCHG8B emulation fails to ignore operand size override UPDATES IN VERSION 3 CVE assigned. Public release. ISSUE DESCRIPTION = The x86 instruction CMPXCHG8B is supposed to ignore legacy operand size overrides; it only honors the REX.W override (making it CMPXCHG16B). So, the operand size is always 8 or 16. When support for CMPXCHG16B emulation was added to the instruction emulator, this restriction on the set of possible operand sizes was relied on in some parts of the emulation; but a wrong, fully general, operand size value was used for other parts of the emulation. As a result, if a guest uses a supposedly-ignored operand size prefix, a small amount of hypervisor stack data is leaked to the guests: a 96 bit leak to guests running in 64-bit mode; or, a 32 bit leak to other guests. IMPACT == A malicious unprivileged guest may be able to obtain sensitive information from the host. VULNERABLE SYSTEMS == Xen versions 3.3 through 4.7 are affected. Xen master and Xen 4.8 as well as Xen versions 3.2 and earlier are not affected. Only x86 systems are affected. ARM systems are not affected. On Xen 4.6 and earlier the vulnerability is exposed to all HVM guest user processes, including unprivileged processes. On Xen 4.7, the vulnerability is exposed only to HVM guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa200-4.7.patch Xen 4.7.x xsa200-4.6.patch Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa200* 820e95e87b838de5eb4158a55c81cf205428f0ed17009dc8d45b2392cf9a0885 xsa200-4.6.patch d7113b94f6ef1c2849aedfe33eace85b0713fa83639c8a533fb289aa73e818e8 xsa200-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYT/KgAAoJEIP+FMlX6CvZR6QH/0eEM2+9ixdfFAiyhFzn0TTq mLgbKs4L0ALfPD2JVhkiLlB/thJ7RKXfPAsYVBQhNY+xb58OLykH4Clh0NuOY45W wkWxHeunHAfsNo3FIaISr/uG/5fAnarPsfF+bNYpyWCuWLz4Ml+uuflnfL60PmoP OGSPLEPKZ56r9lyaIALFVfkXgHkaquM/WXi+FdG23aArbT43cVHeGou8dUNbH/Jd FpKdO3AhMT9i+ioPeicSIimxLOEBZnrCaB/7qOAzu7q3nlQ8X/1Q8a8TjjOtYtQA /kOkvpexkQuRA98AI6018ajqU/D5VdFW+I2X0kmbTAxj1SyT12X25f9Wsc0PbdE= =ERcI -END PGP SIGNATURE- xsa200-4.6.patch Description: Binary data xsa200-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 201 (CVE-2016-9815, CVE-2016-9816, CVE-2016-9817, CVE-2016-9818) - ARM guests may induce host asynchronous abort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9815,CVE-2016-9816,CVE-2016-9817,CVE-2016-9818 / XSA-201 version 2 ARM guests may induce host asynchronous abort UPDATES IN VERSION 2 CVEs assigned. ISSUE DESCRIPTION = Depending on how the hardware and firmware have been integrated, guest-triggered asynchronous aborts (SError on ARMv8) may be received by the hypervisor. The current action is to crash the host. A guest might trigger an asynchronous abort when accessing memory mapped hardware in a non-conventional way. Even if device pass-through has not been configured, the hypervisor may give the guest access to memory mapped hardware in order to take advantage of hardware virtualization. The CVEs are as follows: xsa201-1.patch CVE-2016-9815 xsa201-2.patch CVE-2016-9816 xsa201-3-*.patch CVE-2016-9817 xsa201-4.patch CVE-2016-9818 IMPACT == A malicious guest may be able to crash the host. VULNERABLE SYSTEMS == All Xen versions which support ARM are potentially affected. Whether a particular ARM systems is affected depends on technical details of the hardware and/or firmware. x86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not expose MMIO to userspace will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. NOTE REGARDING LACK OF EMBARGO == The issue was discussed publicly (and has been fixed already in KVM in public trees). CREDITS === This issue was discovered by ARM engineering personnel. RESOLUTION == Applying the appropriate set of attached patched resolves this issue. xsa201-[1234].patch Xen-unstable xsa201-[12].patch } xsa201-3-4.7.patch} Xen 4.7.x, Xen 4.6.x xsa201-4.patch} $ sha256sum xsa201* 163aeb9ae3ffce28e0bc95bdfff490d2df6f6f0b85ac1d4f447bea921f0a0dda xsa201-1.patch 0ba570ed7df172475bc745e02b89670608251634895e5279edcf534619d6d81b xsa201-2.patch 4045e046473f069c51e5fd579f63563862aa497d945b183c768481ef11885744 xsa201-3.patch a9cf56564d020675c0f2f1ea15009a712f172be3d53ea8ddf2f48adaac392e76 xsa201-3-4.7.patch 388d548cd4e30883ae100863d33e792869e7dbd86054299a91b64db6d6599919 xsa201-4.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYR+VFAAoJEIP+FMlX6CvZVZkIAKygymoB/4TYWHSQCDaekqe7 oqs0SrOZwAiaXDDtNEq5oUmWzw852p6ewHzeHkuFrpXSTg9NZqE3ve/Ygy4z2lwQ jlrQblTl1wopoJDKFfvVqnGX4sEQvDqsOKAYpX0LbtjiIOAisKNT5f40J9X3L2Oz dzEdMuKDNvCDO6hPbDXprDDP9qETO4+Wopsj14F6rraYICrMl1P1LKabwr12936s XuegVU25S777YJ3CXpJVSCGns6zZzJm345l1VdgQ5M+KmMQkb4P+v5do7rMHMZFU LvYqxT9M+V6EDylByNp1HuYJWFQU7jgH/oK4k0M3EHAuovN5GZKp7SdGywVEEwY= =t4pk -END PGP SIGNATURE- xsa201-1.patch Description: Binary data xsa201-2.patch Description: Binary data xsa201-3.patch Description: Binary data xsa201-3-4.7.patch Description: Binary data xsa201-4.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 199 (CVE-2016-9637) - qemu ioport array overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9637 / XSA-199 version 3 qemu ioport array overflow UPDATES IN VERSION 3 Clarify the IMPACT description, by escalating privilege to that of the qemu process, not necesserily the host. Public release. ISSUE DESCRIPTION = The code in qemu which implements ioport read/write looks up the specified ioport address in a dispatch table. The argument to the dispatch function is a uint32_t, and is used without a range check, even though the table has entries for only 2^16 ioports. When qemu is used as a standalone emulator, ioport accesses are generated only from cpu instructions emulated by qemu, and are therefore necessarily 16-bit, so there is no vulnerability. When qemu is used as a device model within Xen, io requests are generated by the hypervisor and read by qemu from a shared ring. The entries in this ring use a common structure, including a 64-bit address field, for various accesses, including ioport addresses. Xen will write only 16-bit address ioport accesses. However, depending on the Xen and qemu version, the ring may be writeable by the guest. If so, the guest can generate out-of-range ioport accesses, resulting in wild pointer accesses within qemu. IMPACT == A malicious guest administrator can escalate their privilege to that of the qemu process. VULNERABLE SYSTEMS == PV guests cannot exploit the vulnerability. ARM systems are not vulnerable. HVM domains run with QEMU stub domains cannot exploit the vulnerability. (A QEMU stub domain is used if xl's domain configuration file contains "device_model_stubdomain_override=1".) Guests using the modern "qemu-xen" device model, with a qemu version of at least 1.6.0 (for example, as provided by the Xen Project in its Xen 4.4.0 and later releases), cannot exploit the vulnerability. x86 HVM guests, not configured with qemu stub domains, using a version of qemu older than qemu upstream 1.6.0, can exploit the vulnerability. x86 HVM guests using the traditional "qemu-xen-traditional", not configured with qemu stub domains, can therefore exploit the vulnerability. In tabular form: Guest Xen QEMUQEMU "traditional"Status type version stub and/or qemu version ARMany n/a n/a any OK x86 PV any n/a n/a any OK x86 HVMany yes qemu-xen-traditional OK x86 HVMany no qemu-xen* >= 1.6.0 OK x86 HVM>= 4.4no qemu-xen* Xen supplied OK x86 HVMany no qemu-xen* < 1.6.0 Vulnerable x86 HVM<= 4.3no qemu-xen* Xen supplied Vulnerable x86 HVMany no qemu-xen-traditional Vulnerable [*] qemu-xen is the default when qemu stub domains are not in use, since Xen 4.3. MITIGATION == Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. In a usual configuration, a service domain has only the privilege of the guest, so this eliminates the vulnerability. Running HVM guests with the default upstream device model, in Xen 4.4 and later, will also avoid this vulnerability. CREDITS === This issue was discovered by yanghon...@huawei.com of the Huawei Security Test Team. RESOLUTION == Applying the attached patch resolves this issue. xsa199-trad.patch qemu-xen-traditional, all versions $ sha256sum xsa199* 35c6a7d0d51c2347b46a9acf22e034ca328ca62b0ce4ad868a94c190b2e14d36 xsa199-trad.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the mitigations described above is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because in all cases the configuration change may be visible to the guest which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more
[Xen-devel] Xen Security Advisory 201 - ARM guests may induce host asynchronous abort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-201 ARM guests may induce host asynchronous abort ISSUE DESCRIPTION = Depending on how the hardware and firmware have been integrated, guest-triggered asynchronous aborts (SError on ARMv8) may be received by the hypervisor. The current action is to crash the host. A guest might trigger an asynchronous abort when accessing memory mapped hardware in a non-conventional way. Even if device pass-through has not been configured, the hypervisor may give the guest access to memory mapped hardware in order to take advantage of hardware virtualization. IMPACT == A malicious guest may be able to crash the host. VULNERABLE SYSTEMS == All Xen versions which support ARM are potentially affected. Whether a particular ARM systems is affected depends on technical details of the hardware and/or firmware. x86 systems are not affected. MITIGATION == On systems where the guest kernel is controlled by the host rather than guest administrator, running only kernels which do not expose MMIO to userspace will prevent untrusted guest users from exploiting this issue. However untrusted guest administrators can still trigger it unless further steps are taken to prevent them from loading code into the kernel (e.g by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. NOTE REGARDING LACK OF EMBARGO == The issue was discussed publicly (and has been fixed already in KVM in public trees). CREDITS === This issue was discovered by ARM engineering personnel. RESOLUTION == Applying the appropriate set of attached patched resolves this issue. xsa201-[1234].patch Xen-unstable xsa201-[12].patch } xsa201-3-4.7.patch} Xen 4.7.x, Xen 4.6.x xsa201-4.patch} $ sha256sum xsa201* ffdefdaa67748df7fccbc82011202724c622ca432cd121853ecab45ff4657406 xsa201-1.patch 0665eb575b056f98d5330ef23f497b2b3de1a15319e2012005890a17df32a7ed xsa201-2.patch 4486d5efb59c1f1fff04a3cb697f948d5bf680e2a1c0d76cd44382ad8fa9095e xsa201-3.patch ca82c82acd51bf3cb8114d1843519c28e3df26243bd45eb712ff10ba11061b93 xsa201-3-4.7.patch 1de6ddb4b5b46ae390ec4587e588c00a706f4a68365d379db7ad54234f770d48 xsa201-4.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYPZSoAAoJEIP+FMlX6CvZ2zoH/ivzE70xsLHYJUxveoBiFuiU KHFzF0X63G681FjLyU4SY2GkH5K9YutJ1uaakp+peD96fQqCXBHxWUMPAfblnd7t YueMYuFqcz3mE2ypJjBh/fdI8a4UrKHHg3z6Hw6X91p+SRmPsnt9v7OzytoYOiE4 fDeaATwl1LxB+Z/yJETlo/JMgwrtuYZ9EZM9gIzxdOVw+QbQyEYHmuIyni8BNRvZ +biRRQo37K5+jLY3f/RoXKcpqnHqjKOOmfjkxJJAsxqpdTSw5fRJqSZE4G5oUVs2 AAvSKhLObFahMlPqtoNXSC6lG5Gbd3e/h+6N2N/96TXs6Wr+d0VuC+lkYUjwcJk= =KEYF -END PGP SIGNATURE- xsa201-1.patch Description: Binary data xsa201-2.patch Description: Binary data xsa201-3.patch Description: Binary data xsa201-3-4.7.patch Description: Binary data xsa201-4.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 196 (CVE-2016-9377, CVE-2016-9378) - x86 software interrupt injection mis-handled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9377,CVE-2016-9378 / XSA-196 version 3 x86 software interrupt injection mis-handled UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = There are two closely-related bugs. When Xen emulates instructions which generate software interrupts it needs to perform a privilege check involving an IDT lookup. This check is sometimes erroneously conducted as if the IDT had the format for a 32-bit guest, when in fact it is in the 64-bit format. Xen will then read the wrong part of the IDT and interpret it in an unintended manner. (CVE-2016-9377) When Xen emulates instructions which generate software interrupts, and chooses to deliver the software interrupt, it may try to use the method intended for injecting exceptions. This is incorrect, and results in a guest crash. (CVE-2016-9378) These instructions are not ususally handled by the emulator. Exploiting the bug requires ability to force use of the emulator. IMPACT == An unprivileged guest user program may be able to crash the guest. VULNERABLE SYSTEMS == Xen versions 4.5 and newer are vulnerable. Older versions are not vulnerable. The vulnerability is only exposed on AMD hardware lacking the NRip feature. AMD hardware with the NRip feature, and all Intel hardware, is not vulnerable. Xen prints information about CPU features on boot. If you see this: (XEN) SVM: Supported advanced features: ... (XEN) - Next-RIP Saved on #VMEXIT then you are not vulnerable because you have an AMD CPU with NRip. If you see this: (XEN) VMX: Supported advanced features: then you are not vulnerable because you have an Intel CPU. The vulnerability is only exposed on HVM guests. ARM systems are NOT vulnerable. MITIGATION == Running only PV guests will avoid this issue. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the attached patches resolves this issue. xsa196-000*.patch xen-unstable, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x $ sha256sum xsa196* c4122280f3786416231ae5f0660123446d29e9ac5cd3ffb92784ed36edeec8b7 xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject.patch 25671c44c746d4d0e8f7e2b109926c013b440e0bf225156282052ec38536e347 xsa196-0002-x86-svm-Fix-injection-of-software-interrupts.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDMVAAoJEIP+FMlX6CvZZ7MH/36KnwbAxmRHtUDIpQF/Syoh Lc8s6gNV1oOzcCpFgz+gSyIOMzp7KWieKQiVX1HbI0lnLYK/sRa77VNV/Y9bUt+Y y9b9QOZRDHoO92dZ4Ym/hzdtaNkdOQX/JAfy+E5pCGuqPtH/Jy5NuwVL8W7V8PNM QTHmvbgB4/Y2U6QqWpIP+S7oC0A9iuIf9eekd6ZTpqTadPFylTe2WX22mns1TEtN 3Z0NX737AjQLyUVnUoJ32sITCBk6tGutvvEmOc2Y+4eMrUvKSoafVy+5IZcTGwLp 3ke5sDNN1tOpzmqbXgWXBsVkpjWf2i0NW0dl5jh8/tN5FtrTuByd193dJGSKzEE= =IE45 -END PGP SIGNATURE- xsa196-0001-x86-emul-Correct-the-IDT-entry-calculation-in-inject.patch Description: Binary data xsa196-0002-x86-svm-Fix-injection-of-software-interrupts.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 195 (CVE-2016-9383) - x86 64-bit bit test instruction emulation broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9383 / XSA-195 version 3 x86 64-bit bit test instruction emulation broken UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The x86 instructions BT, BTC, BTR, and BTS, when used with a destination memory operand and a source register rather than an immediate operand, access a memory location offset from that specified by the memory operand as specified by the high bits of the register source. When Xen needs to emulate such an instruction, to efficiently handle the emulation, the memory address and register operand are recalculated internally to Xen. In this process, the high bits of an intermediate expression were discarded, leading to both the memory location and the register operand being wrong. The wrong memory location would have only a guest local effect (either access to an unintended location, or a fault delivered to the guest), whereas the wrong register value could lead to either a host crash or an unintended host memory access. IMPACT == A malicious guest can modify arbitrary memory, allowing for arbitrary code execution (and therefore privilege escalation affecting the whole host), a crash of the host (leading to a DoS), or information leaks. The vulnerability is sometimes exploitable by unprivileged guest user processes. VULNERABLE SYSTEMS == All Xen versions are affected. The vulnerability is only exposed to x86 guests running in 64-bit mode. On Xen 4.6 and earlier the vulnerability is exposed to all guest user processes, including unprivileged processes, in such guests. On Xen 4.7 and later, the vulnerability is exposed only to guest user processes granted a degree of privilege (such as direct hardware access) by the guest administrator; or, to all user processes when the when the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). The vulnerability is not exposed to 32-bit PV guests. ARM systems are not vulnerable. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by George Dunlap of Citrix, using American Fuzzy Lop v2.35b. RESOLUTION == Applying the attached patch resolves this issue. xsa195.patch xen-unstable, Xen 4.7.x, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa195* 6ab5f13b81e3bbf6096020f4c3beeffaff67a075cab67e033ba27d199b41cec1 xsa195.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDL4AAoJEIP+FMlX6CvZnzYH/RtmqS8kpqLKShvrQx5Ueh+M LaHBWJiU0z1m9FaF9RvEgfvWpUCcD/qyC4rLHmkwhkyS6aIToh2XVXzQyebIqw/7 CCDXaY8TkYlLPYRdNseX5X5blpu1EnqW5yQMJz6QkgDK+Qu4F1jDimSd5JffrFkJ WkpWwsoppNHwYyaENq59lg7R1WxNq0uSLxMPTnk/RpMmizKyU8gK7RrQWHJNoy6n l3vSTKx9sCDo+AgMQgbDMdpvv1l1It+QcRXXBrBp7qAdz+0H7VRkUFOnBUFMQQo3 OjmjStKxnE9E7Uh6+373xj2Z6Nts+wkD72vRHHg/1KTZ5FN5XnS2CvPDNuGZD50= =AtOu -END PGP SIGNATURE- xsa195.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 198 (CVE-2016-9379, CVE-2016-9380) - delimiter injection vulnerabilities in pygrub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9379,CVE-2016-9380 / XSA-198 version 3 delimiter injection vulnerabilities in pygrub UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = pygrub, the boot loader emulator, fails to quote (or sanity check) its results when reporting them to its caller. pygrub supports a number of output formats. When the S-expression output format is requested, putting string quotes and S-expressions in the bootloader configuration file can produce incorrect output. (CVE-2016-9379) When the nul-delimited output format is requested, nul bytes in the bootloader configuration file can produce an ambiguous or confusing output file, which is interpreted by libxl in a vulnerable way. (CVE-2016-9380) The existing bootloader config interpreters all read input in a line-based way from their bootloaders, and none of them support any kind of escaping. So the newline-delimited output format is safe. The attacker can use this to cause the toolstack to treat any file accessible to the toolstack as if it were the guest's initial ramdisk file. The file contents are provided to the guest kernel; also, normally, these files are deleted by the toolstack as the guest starts to boot; alternatively they may be deleted later. IMPACT == A malicious guest administrator can obtain the contents of sensitive host files (an information leak). Additionally, a malicious guest administrator can cause files on the host to be removed, causing a denial of service. In some unusual host configurations, ability to remove certain files may be useable for privilege escalation. VULNERABLE SYSTEMS == Xen versions 2.0 and later are vulnerable. The vulnerability is only exposed to guests configured by the host administrator to boot using pygrub. In the xl and xm domain configuration file, this is typically achieved with bootloader="pygrub" On x86 this would typically apply only to PV domains. All systems using xl, libxl, or libvirt are vulnerable to pygrub-using guests. Systems using other (third-party) toolstacks may or may not be vulnerable, depending on whether pygrub is configured, and what pygrub output format they use. Please consult your toolstack provider. MITIGATION == Configuring guests not to use pygrub will avoid the vulnerability. For x86 PV guests currently using pygrub, booting the guest as HVM is often a practical option to avoid pygrub. CREDITS === This issue was discovered by Daniel Richman and Gábor Szarka of the Cambridge University Student-Run Computing Facility. RESOLUTION == Applying the attached patch resolves this issue. xsa198.patch All Xen versions (at least Xen 4.4 and later) $ sha256sum xsa198* 0e4533ad2157c03ab309bd12a54f5ff325f03edbe97f23c60a16a3f378c75eae xsa198.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. Deployment of the mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because switching away from the use of pygrub would reveal where the vulnerability lies. Deployment of mitigations is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDN4AAoJEIP+FMlX6CvZX8AH/1FL3pw4RbbuFd/b23Qmo25U F7qELx001C4C+uXtlxaIg6MT467pRphihSkLcLQ2vgIp57iVTXhufc4TVqhdADgp bL3h1zd7Ot4f+iA5RYlGIJ4is3I2A6lNvLwydi2PIGgmalSad5B3Ed0vrvRwfLKY qpsVm0LrM24aFX2IaygmmziQIQVeXSYpmKmVebOEAFL0uj9g8D3VhgWIMtZxW+9K A6c2NTrt01ZbsVRx2wTcRdRhEJLeFbBZOPS9RrbjJzbuFcAzsGR8m/pS4hJBhik/ 9MG4b7FBMYZTaBd4wcbbHM81py1KkcoreC2jL1qb1JMG7BQVP1USdz21rJ05DY8= =P2XT -END PGP SIGNATURE- xsa198.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 197 (CVE-2016-9381) - qemu incautious about shared ring processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9381 / XSA-197 version 3 qemu incautious about shared ring processing UPDATES IN VERSION 3 Added email header syntax to patches, for e.g. git-am. Public release. ISSUE DESCRIPTION = The compiler can emit optimizations in qemu which can lead to double fetch vulnerabilities. Specifically data on the rings shared between qemu and the hypervisor (which the guest under control can obtain mappings of) can be fetched twice (during which time the guest can alter the contents) possibly leading to arbitrary code execution in qemu. IMPACT == Malicious administrators can exploit this vulnerability to take over the qemu process, elevating its privilege to that of the qemu process. In a system not using a device model stub domain (or other techniques for deprivileging qemu), malicious guest administrators can thus elevate their privilege to that of the host. VULNERABLE SYSTEMS == All Xen versions with all flavors of qemu are affected. Only x86 HVM guests expose the vulnerability. x86 PV guests do not expose the vulnerability. ARM systems are not vulnerable. MITIGATION == Running only PV guests will avoid the vulnerability. Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. In a usual configuration, a service domain has only the privilege of the guest, so this eliminates the vulnerability. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by yanghongke of Huawei Security Test Team. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa197-qemuu.patch qemu-upstreamxen-unstable, Xen 4.7.x xsa197-qemut.patch qemu-traditional xen-unstable, Xen 4.7.x, Xen 4.6.x xsa197-4.6-qemuu.patch qemu-upstreamXen 4.6.x xsa197-4.5-qemuu.patch qemu-upstreamXen 4.5.x xsa197-4.5-qemut.patch qemu-traditional Xen 4.5.x, Xen 4.4.x xsa197-4.4-qemuu.patch qemu-upstreamXen 4.4.x $ sha256sum xsa197* a7d63958e3d3afc21c0585ec4690886a3191f01127583b4a29766c45fe4dd611 xsa197-4.4-qemuu.patch 56d037b3eaa0c3f5a7c474ad5087d8a41c2769d0d8b39c8f64699215a33e17a6 xsa197-4.5-qemut.patch 902836f0e5c6c46193c06f7c133a3bdd59f902ee490b962857640a6cd73e4be7 xsa197-4.5-qemuu.patch 20a418606f5536ac4fb009f21548a28b1b32dfb08fc97a259c40240d37a2abe8 xsa197-4.6-qemuu.patch 266996b2b5ac65ded76af63b3d57d4972ab95522b517e7bc9c5ff554d8c2d5e0 xsa197-qemut.patch cd08b149c97b3f94dcda14b1f280dbb92911d93ffcd5dbcf5ee5ab2bebdc7878 xsa197-qemuu.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patch described above (or others which are substantially similar) and the PV guest mitigation are permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER deployment of the stubdomain mitigation described above is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because in that case the configuration change may be visible to the guest which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDNLAAoJEIP+FMlX6CvZTvUIALi45XVEJv4ZqNsB1kX3mXIF 5ocmSFCrSDDIcKEg2xQ49PKwqE/ZwMLhKuX0dFi/inidqx7FynYknziaR3svIeir ALTDP6Emsk/OB7T4epjGnuFW05RTfkQmwzEyY/XCAJVrJlkzKGh3WYVtwk+/PELT 3ab9dMEcziaUM+Ax3phJ4PHi315If2rLS4gNfqGO5jv/gnMyXk4DHQ8QZUHIGs4F 8tA/ATPaZxNK8OIwGEIz32PlLxwWHsQQz6JEAtvNwGDTNMDwlx3RzHSvjJSLOIKB Aap6qw4c9olK172LQbvBqvP09Eupi3YSevx3AD0gmqKVwj8ql/lNUSNBf9CSfPc= =SBVo -END PGP SIGNATURE- xsa197-4.4-qemuu.patch Description: Binary data
[Xen-devel] Xen Security Advisory 193 (CVE-2016-9385) - x86 segment base write emulation lacking canonical address checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9385 / XSA-193 version 3 x86 segment base write emulation lacking canonical address checks UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Both writes to the FS and GS register base MSRs as well as the WRFSBASE and WRGSBASE instructions require their input values to be canonical, or a #GP fault will be raised. When the use of those instructions by the hypervisor was enabled, the previous guard against #GP faults (having recovery code attached) was accidentally removed. IMPACT == A malicious guest administrator can crash the host, leading to a DoS. VULNERABLE SYSTEMS == Xen versions 4.4 and onwards are affected. Xen versions 4.3 and earlier are not affected. The vulnerability is only exposed to x86 PV guests. The vulnerability is NOT exposed to x86 HVM guests. ARM systems are NOT vulnerable. MITIGATION == Running only HVM guests will avoid this vulnerability. For PV guests the vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa193.patch xen-unstable xsa193-4.7.patch Xen 4.7.x, Xen 4.6.x xsa193-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa193* 401df29b462a3430403a4f5bb36fd7824e692c9b5bac650e1a9d70bd440a55a1 xsa193.patch b3494b1fe5fefc0d032bd603340e364c880ec0d3ae3fb8aa3a773038e956f955 xsa193-4.5.patch f1b0092c585ebffe83d6ed7df94885ec5dfcb4227bdb33f421bad9febb8135a1 xsa193-4.7.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDK2AAoJEIP+FMlX6CvZswsIAI17sWqaGeP8GvtddxR08G2J 3Nb7Lnb/4cq8Hdc5XmUnX/zuDqobT5AGJEgKAuhRc9zs2TOv8FwcABc+/odKG6ak tcMAaLThMcKbB0b0ZYEkcrU+jaCDDVE3rYVGjKv0hHKZNRY/SmWOdl180xcHksXG pj5OQn6/+db6nqMlhyOcOyjM3w1/1AUe/O0EDsdUSNrY1mZi4/MjUXlDaJTZbDCc KW9XUeRSq66iZELawBaosViTenOm/R+8DJGiR8fmJlXx+gzpEywtsEUCrxeKlTDo tT68gwy0aHdlqKbIthkKr5qaT5FtKPyX0UpIXu7qtldbdEZG61iIlNOEG8tyPhU= =fjbt -END PGP SIGNATURE- xsa193.patch Description: Binary data xsa193-4.5.patch Description: Binary data xsa193-4.7.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 194 (CVE-2016-9384) - guest 32-bit ELF symbol table load leaking host data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9384 / XSA-194 version 3 guest 32-bit ELF symbol table load leaking host data UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Along with their main kernel binary, unprivileged guests may arrange to have their Xen environment load (kernel) symbol tables for their use. The ELF image metadata created for this purpose has a few unused bytes when the symbol table binary is in 32-bit ELF format. These unused bytes were not properly cleared during symbol table loading. IMPACT == A malicious unprivileged guest may be able to obtain sensitive information from the host. The information leak is small and not under the control of the guest, so effectively exploiting this vulnerability is probably difficult. VULNERABLE SYSTEMS == Only Xen version 4.7 is affected. Xen versions 4.6 and earlier are not affected. The vulnerability is not exposed to x86 HVM guests, unless the host toolstack has configured to load the guest with a non-default loader, rather than hvmloader. MITIGATION == There is no known mitigation. CREDITS === This issue was discovered by Roger Pau Monné of Citrix. RESOLUTION == Applying the attached patch resolves this issue. xsa194.patch xen-unstable, Xen 4.7.x $ sha256sum xsa194* 4dad65417d9ff3c86e763d3c88cf8de79b58a9981d531f641ae0dd0dcedce911 xsa194.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDLYAAoJEIP+FMlX6CvZqAoH/39GSWwDpYnflz3TcFyQUViM j36XzzStWya71ewaXiguUbTHHg6mK47pK4EA/3zFwerczz/5yQzhlToitPkP/8WE 5Qbg9Wyg4STylzeKaiTvLzqUK6XSiJ4oKZwLsnU7tFPLcb6FBMm9t3bzg9NECaft /6zYj1SVCvoLJB/gtgbwrz2MCjVZQZ9Q2+mpirvu0ePQRD73M0cwfj1ncqjUkFd9 ZNdk14gmxOk1/wWAm/oD1QKUWmjpzByT5dbGcMV3OxGs1V2Px+o4c1u1t/agldr0 wC2LvCK9IED9JcBaH/M85TTAGR7GqfU8l9x3ep97GkrUpquX4OGFt7na28M1YUQ= =Gc8O -END PGP SIGNATURE- xsa194.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 191 (CVE-2016-9386) - x86 null segments not always treated as unusable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9386 / XSA-191 version 3 x86 null segments not always treated as unusable UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The Xen x86 emulator erroneously failed to consider the unusability of segments when performing memory accesses. The intended behaviour is as follows: The user data segment (%ds, %es, %fs and %gs) selectors may be NULL in 32-bit to prevent access. In 64-bit, NULL has a special meaning for user segments, and there is no way of preventing access. However, in both 32-bit and 64-bit, a NULL LDT system segment is intended to prevent access. On Intel hardware, loading a NULL selector zeros the base as well as most attributes, but sets the limit field to its largest possible value. On AMD hardware, loading a NULL selector zeros the attributes, leaving the stale base and limit intact. Xen may erroneously permit the access using unexpected base/limit values. Ability to exploit this vulnerability on Intel is easy, but on AMD depends in a complicated way on how the guest kernel manages LDTs. IMPACT == An unprivileged guest user program may be able to elevate its privilege to that of the guest operating system. VULNERABLE SYSTEMS == The vulnerability is only exposed to HVM guests. ARM systems are NOT vulnerable. All versions of Xen are affected. However, we believe that the vulnerability cannot be exploited on Xen 4.7 by completely unprivileged guest processes, unless the VM has been explicitly configured with a non-default cpu vendor string (in xm/xl, this would be done with a `cpuid=' domain config option). MITIGATION == Running only PV guests will avoid this issue. CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa191.patch xen-unstable, Xen 4.7.x xsa191-4.6.patch Xen 4.6.x, Xen 4.5.x, Xen 4.4.x $ sha256sum xsa191* dca534cf4d3711ea8797846a18238ca16cc9e7a24a887300db22c3ba3d95c199 xsa191.patch d95a1f0dd5c45497ca56e2e1390fc688bf0a4a7a7fd10c65ae25b4bbb3353b69 xsa191-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDIWAAoJEIP+FMlX6CvZ4qQH/jlfd6BV63CSggCQVd0sB3a4 j7MgRZ8h0aFrCLl+0tj3QwsiW0TRDsKiTNy2xY1kxkLsQdIAeYjBddyYiJ2nbCr9 kCR2WLcWB3csf4So/85q8OMfsob7H+8PR/OsT3iY6Fo/5PzNy5wvWtU/+TRaoZIy t9OvybZ0HYhtvQ/YHv5njKZ3nyHo6MRwGpPOrzSn8UN7p+sr3DDGiuw9LNjtnepb dijO0c9artbWCjVkRlbe1w5514FH1vPleopGmXjTz/Wy5zNHWZL1RaVzh4N36ahP V1joPxt+C75iRArp6y0ncloyKjgx8pMfOzCcLp9VS6dwF3zwZ5rxxtFynlRjg94= =pUW4 -END PGP SIGNATURE- xsa191.patch Description: Binary data xsa191-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 192 (CVE-2016-9382) - x86 task switch to VM86 mode mis-handled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-9382 / XSA-192 version 3 x86 task switch to VM86 mode mis-handled UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = LDTR, just like TR, is purely a protected mode facility. Hence even when switching to a VM86 mode task, LDTR loading needs to follow protected mode semantics. This was violated by the code. IMPACT == On SVM (AMD hardware): a malicious unprivileged guest process can escalate its privilege to that of the guest operating system. On both SVM and VMX (Intel hardware): a malicious unprivileged guest process can crash the guest. VULNERABLE SYSTEMS == Only 32-bit x86 HVM guests are vulnerable. Furthermore, only guest operating systems which actually make use of hardware task switching, and allow a new task to start in VM86 mode, are vulnerable. We are not aware of any such operating systems. The vulnerability is NOT exposed on any PV guests. The vulnerability is NOT exposed on any 64-bit guests, ARM systems are NOT vulnerable. Xen versions from 4.0 onwards are affected. Xen versions 3.4 and earlier are not affected. MITIGATION == For guests which are affected, the vulnerability could possibly be mitigated by disabling access to VM86 mode by unprivileged guest programs. Details would depend on the (so far hypothetical) vulnerable guest kernel. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa192.patch xen-unstable, Xen 4.7.x, Xen 4.6.x xsa192-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa192* 687b0216eefd5ecef8a3135cc6f542cb3d9ff35e8e9696a157703e84656c35e8 xsa192.patch bb0c6622c6f5c5eb9a680020d865802069446830b4a170bcb82336f6c3b77f55 xsa192-4.5.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJYNDJ9AAoJEIP+FMlX6CvZy5gIALU7weBZNJeQzBUMoQn6fAG/ KNP3Br3BDYHC/MMbyIAkkEyHTfsR1xFNAHHb2Tb/Wl7v081owV7JwO3bkf0FJ88w K8RXFeUbt1z5rAdt1B088CbZA4/KkGRBd32vicUIE7+9EnkgSOlLc8abjind+yQ9 2CtOHwDL0LVbjjGF6VdME9pooDZf2ZT1fHfClUbwPFsfTMKjUeJcfoVFqenifmYR wTYPtw6z+cCrjBlPyleglh/2uAc6ncTIQAC8Ee2dJyKv4wMqP60u97ANylnN3DpZ DTl+VUYdNsy78R9/xbqF7dT5gCeDV9y1rDoqHQwwtSGL/lvjU0ujbEtG7XS2/7M= =chON -END PGP SIGNATURE- xsa192.patch Description: Binary data xsa192-4.5.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 190 (CVE-2016-7777) - CR0.TS and CR0.EM not always honored for x86 HVM guests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016- / XSA-190 version 5 CR0.TS and CR0.EM not always honored for x86 HVM guests UPDATES IN VERSION 5 Public release. ISSUE DESCRIPTION = Instructions touching FPU, MMX, or XMM registers are required to raise a Device Not Available Exception (#NM) when either CR0.EM or CR0.TS are set. (Their AVX or AVX-512 extensions would consider only CR0.TS.) While during normal operation this is ensured by the hardware, if a guest modifies instructions while the hypervisor is preparing to emulate them, the #NM delivery could be missed. Guest code in one task may thus (unintentionally or maliciously) read or modify register state belonging to another task in the same VM. IMPACT == A malicious unprivileged guest user may be able to obtain or corrupt sensitive information (including cryptographic material) in other programs in the same guest. VULNERABLE SYSTEMS == All versions of Xen expose the vulnerabilty to their x86 HVM guests. In order to exploit the vulnerability, the attacker needs to be able to trigger the Xen instruction emulator. On Xen 4.7 the emulator can only be triggered: by user mode tasks which have been given access to memory-mapped IO; in guests which have been migrated between systems with CPUs from different vendors; or in guests which have been configured with a CPU vendor different from the host's. On Xen 4.6 and earlier, all HVM guests can trigger the emulator by attempting to execute an invalid opcode, exposing the vulnerability. The vulnerability is only exposed to x86 HVM guests. The vulnerability is not exposed to x86 PV or ARM guests. MITIGATION == On Xen 4.7, not migrating across CPU vendors will avoid this vulnerability. (Unless the guest grants mmio access to unprivileged tasks, or has been configured with a specific CPU vendor, eg using the xl "cpuid" configuraton option.) CREDITS === This issue was discovered by Jan Beulich from SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa190.patch xen-unstable, Xen 4.7.x xsa190-4.6.patch Xen 4.6.x xsa190-4.5.patch Xen 4.5.x, Xen 4.4.x $ sha256sum xsa190* 21e7b1d08874527ab2e4cd23d467e9945afcd753dd3390ab2aaf9d24d231916c xsa190.patch 477d56c41cc2101432459ab79e4d5663aade779c36285f5c1d6d6ed4e34e1009 xsa190-4.5.patch dbfc4b36132c841959847dfbb85a188ee6489ad3b8d7ecec43c55a303a43df21 xsa190-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJX86WyAAoJEIP+FMlX6CvZZOQH/0rLFSZeiGeWDlKzQJoB3VLy zDvpDKjfhuwPyWT9+oyfwUHxARWuJkYSy85bpVuNWmxtb1tGy+QTjbSZgyVrsRXY 4t09MzhTF9CuNhqTghEGbFeGdh20ht3EoDjiwkjlbfb4TQ439e189qo9Oe0J/LvD 4XjL/oHza0YMI/wFviANUZvvTzAcjTAw1Zwk6dpnM17cwK4HduPYBncUyfDrSa3G 97nOraBXh/CiwWlm6goRSOI73ORUkYYBwJLGcq3a50HJPJ7pCbBaRJpDCalMPZ2B Lf+HO38HROEGBbTfkOjyZKkbTjQ2njTu0kHaBl+IVK8LI3PLv35n5MQ6qStYL/U= =7/xB -END PGP SIGNATURE- xsa190.patch Description: Binary data xsa190-4.5.patch Description: Binary data xsa190-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 187 (CVE-2016-7094) - x86 HVM: Overflow of sh_ctxt->seg_reg[]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-7094 / XSA-187
version 3
x86 HVM: Overflow of sh_ctxt->seg_reg[]
UPDATES IN VERSION 3
Fix the backports xsa187-4.6-0002-*.patch and xsa187-4.4-0002-*.patch.
In v1 and v2 these did not compile in debug builds. (Debug builds
should not be used in production.)
Public release.
ISSUE DESCRIPTION
=
x86 HVM guests running with shadow paging use a subset of the x86 emulator to
handle the guest writing to its own pagetables. There are situations a guest
can provoke which result in exceeding the space allocated for internal state.
IMPACT
==
A malicious HVM guest administrator can cause Xen to fail a bug check,
causing a denial of service to the host.
VULNERABLE SYSTEMS
==
All versions of Xen are vulnerable.
The vulnerability is only exposed to HVM guests on x86 hardware, which are
configured to run with shadow paging.
The vulnerability is not exposed to x86 PV guests, x86 HVM guests running with
hardware assisted paging, or ARM guests.
x86 HVM guests run in HAP mode by default on modern CPUs.
To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q'). This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:
(XEN) General information for domain 2:
(XEN) refcnt=1 dying=2 pause_count=2
(XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=262400
(XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
(XEN) paging assistance: hap refcounts translate external
^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain. For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.
MITIGATION
==
Running only PV guests will avoid this vulnerability.
On hardware which supports Hardware Assisted Paging, configuring the
guests to not run with shadow paging will avoid this vulnerability.
CREDITS
===
This issue was discovered by Andrew Cooper of Citrix.
RESOLUTION
==
Applying the first patch will resolve this issue.
The second patch provides additional assurance that the vulnerability
is truly eliminated and that there are no related problems.
If hotpatching, applying only the first patch is recommended since the
second patch is awkward for hotpatching. If deploying new builds,
applying both patches is recommended.
Xen version First patch Second patch
xen-unstable: xsa187-0001-*.patch xsa187-0002-*.patch
Xen 4.7.x: xsa187-4.7-0001-*.patch xsa187-4.7-0002-*.patch
Xen 4.6.x: xsa187-4.7-0001-*.patch xsa187-4.6-0002-*.patch
Xen 4.5.x: xsa187-4.7-0001-*.patch xsa187-4.6-0002-*.patch
Xen 4.4.x: xsa187-4.7-0001-*.patch xsa187-4.4-0002-*.patch
$ sha256sum xsa187*
65205ee195699d65884af04083ffb86c6ddbc96cbca3141c87f6b2d671de45a3
xsa187-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg_reg.patch
f90e6d13385fb9219e1e26e3a148d1670aefc7130e0639415d08bbb6a1d9efee
xsa187-0002-x86-segment-Bounds-check-accesses-to-emulation-ctxt-.patch
727b18ae83001f7ea04613aa7199ada3e6a84939aa44516f7c426e609d383b2a
xsa187-4.4-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch
b96731379ea77d4931d969f4742dde985ef7a86af9422dcac8327c2a1916
xsa187-4.6-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch
be9fe85d36c2c1fbca246c1f4d834c3ef11b6ab3d5467da0ac8c079aa5a68de9
xsa187-4.7-0001-x86-shadow-Avoid-overflowing-sh_ctxt-seg.patch
36b22d6a168be39f31a1c1304f708269a2a10fe5105f7da4a06877d6059f1cd6
xsa187-4.7-0002-x86-segment-Bounds-check-accesses-to-emulation-ctx.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the "reconfigure to use HAP" MITIGATION is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List). Specifically, deployment on
public cloud systems is NOT permitted.
This is because the mitigation result in guest-visible changes.
Deployment of this mitigation is permitted only AFTER the embargo
ends.
Deployment of the PATCHES described above (or others which are
substantially similar) is permitted during the embargo, even on
public-facing systems with untrusted guest users and administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project
[Xen-devel] Xen Security Advisory 188 (CVE-2016-7154) - use after free in FIFO event channel code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-7154 / XSA-188 version 3 use after free in FIFO event channel code UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When the EVTCHNOP_init_control operation is called with a bad guest frame number, it takes an error path which frees a control structure without also clearing the corresponding pointer. Certain subsequent operations (EVTCHNOP_expand_array or another EVTCHNOP_init_control), upon finding the non-NULL pointer, continue operation assuming it points to allocated memory. IMPACT == A malicious guest administrator can crash the host, leading to a DoS. Arbitrary code execution (and therefore privilege escalation), and information leaks, cannot be excluded. VULNERABLE SYSTEMS == Only Xen 4.4 is vulnerable. Xen versions 4.5 and later as well as Xen versions 4.3 and earlier are not vulnerable. MITIGATION == There is no mitigation available. CREDITS === This issue was discovered by Mikhail Gorobets of Advanced Threat Research, Intel Security. RESOLUTION == Applying the attached patch resolves this issue. xsa188.patch Xen 4.4.x $ sha256sum xsa188* 9f374c2e1437ad71369f41275e7b333e7b7691a783ba693ee567c899bd78c722 xsa188.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJX0VLuAAoJEIP+FMlX6CvZNjYH/RVxqYegZpfj0aiT5pai/a0i PgPSoMccGoSSVTXzivXUTZS3fTIqfTpd4SQHu2Q2dUqbb6zcPqd3NzF7Jl9IMwLk JHZwPYXOsZ0D6thFAMYFpjHOWXv7+1Mw7Np82PaA2yAUad+kxUORiJeL1RAE6zG/ xsAR7PTl2mK1Ae9lqDtKLijn0cnicAYoKiSlta8M0T5Sp79CT3xsfHiBbaWUBCcI gmOW76RUbfOwn2kmhFJ4X5bwSzEhM93pQu7hJCmuwAADc8ezEEFv2lsUm5W8hkmW a8V2nuqM+prbxY8JI3XbKJm5YrmHQpnX4FiBn13DZeUsaukT4Q1EltP1z/XvJto= =jzF5 -END PGP SIGNATURE- xsa188.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 185 (CVE-2016-7092) - x86: Disallow L3 recursive pagetable for 32-bit PV guests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-7092 / XSA-185 version 3 x86: Disallow L3 recursive pagetable for 32-bit PV guests UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = On real hardware, a 32-bit PAE guest must leave the USER and RW bit clear in L3 pagetable entries, but the pagetable walk behaves as if they were set. (The L3 entries are cached in processor registers, and don't actually form part of the pagewalk.) When running a 32-bit PV guest on a 64-bit Xen, Xen must always OR in the USER and RW bits for L3 updates for the guest to observe architectural behaviour. This is unsafe in combination with recursive pagetables. As there is no way to construct an L3 recursive pagetable in native 32-bit PAE mode, disallow this option in 32-bit PV guests. IMPACT == A malicious 32-bit PV guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. Only 64-bit builds of the hypervisor are vulnerable. For Xen 4.3 and earlier, 32-bit builds of the hypervisor are not vulnerable. The vulnerability is only exposed to 32-bit PV guests on x86 hardware. The vulnerability is not exposed to 64-bit PV guests, x86 HVM guests, or ARM guests. MITIGATION == Running only 64-bit PV or HVM guests will avoid this vulnerability. CREDITS === This issue was found in parallel by multiple discoverers, who each disclosed it to the Xen Project Security Team. The first report to us was made by Jérémie Boutoille of Quarkslab. The second report, one working day later, by Shangcong Luan of Alibaba Cloud. RESOLUTION == Applying the attached patch resolves this issue. xsa185.patch xen-unstable - Xen 4.4 $ sha256sum xsa185* 3328a1953ecdf4de35462ea8396b0927171d718e95f73a87a7f651427bd8f8b4 xsa185.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJX0VLpAAoJEIP+FMlX6CvZ/koH/0hN8oXOpBPVgsr5d+ylYFBU We948VVN/0uthy9IgI1DBnjM2tjoGgy0w7c7dKWUD3ACTvdIq4hWZywA+6uMIwb5 aneB7hgZZ1i/ie1kAwMl96hdWgPGaXjL1r19WxslgOnr2TkH/9zlAaBvhFkbL+/c cw2lI+AOmhB/VOtNfXYd81qxdSUBUPz2DfiOEjgVx8e8E+q/S5dJO1L41kqRt1bM ENG8NtaxBrXAtZzilxOPVPmQmvSSegTjZMshGhx29wIgUy4R/HnsoYW7OklZQDhU 6DV7WUSlrUU5vlIhwQVIZidXpyhzLBLnR5GS0R4CKcYSb6pRQ8FO3TG81TmO/6Q= =NDX0 -END PGP SIGNATURE- xsa185.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 186 (CVE-2016-7093) - x86: Mishandling of instruction pointer truncation during emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-7093 / XSA-186 version 4 x86: Mishandling of instruction pointer truncation during emulation UPDATES IN VERSION 4 Public release. ISSUE DESCRIPTION = When emulating HVM instructions, Xen uses a small i-cache for fetches from guest memory. The code that handles cache misses does not check if the address from which it fetched lies within the cache before blindly writing to it. As such it is possible for the guest to overwrite hypervisor memory. It is currently believed that the only way to trigger this bug is to use the way that Xen currently incorrectly wraps CS:IP in 16 bit modes. The included patch prevents such wrapping. IMPACT == A malicious HVM guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS == Xen versions 4.7.0 and later are vulnerable. Xen releases 4.6.3 and 4.5.3 are vulnerable. Xen releases 4.6.0 to 4.6.2 inclusive are NOT vulnerable. Xen releases 4.5.2 and earlier are NOT vulnerable. The vulnerability is only exposed to HVM guests on x86 hardware. The vulnerability is not exposed to x86 PV guests, or ARM guests. MITIGATION == Running only PV guests will avoid this vulnerability. CREDITS === This issue was discovered by Brian Marcotte. RESOLUTION == Applying the first patch will resolve the issue. Users wishing to independently verify the correctness of the fix may find the second patch helpful. The second patch makes it easier to use the "fep" (Force Emulation Prefix) feature to reproduce the erroneous condition in a test environment. The "fep" feature requires explicit enablement on the hypervisor command line, and is unsuitable for production systems. Accordingly, applying the second patch does not affect production systems and does not improve security. Xen version First patch Second patch xen-unstable: xsa186-0001-*.patch xsa186-0002-*.patch Xen 4.7.x: xsa186-0001-*.patch xsa186-4.7-0002-*.patch Xen 4.6.3: xsa186-0001-*.patch xsa186-4.6-0002-*.patch Xen 4.5.3: xsa186-0001-*.patch xsa186-4.6-0002-*.patch $ sha256sum xsa186* f2082a36d968a47e477bb5082d0e0aaa58e6cb3dc20b26389f043a9b7b595fa6 xsa186-0001-x86-emulate-Correct-boundary-interactions-of-emulate.patch 412fa58edcbd1c7fdbfec7e28898cf98585593e6a24ccfb088dc0b84715286a5 xsa186-0002-hvm-fep-Allow-testing-of-instructions-crossing-the-1.patch 7482a823c3443e26deec4904162845eaa9f826aa7bf8348007406d91bddd xsa186-4.6-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch 5a826a32763d82ac83c924f8c89d12aae5f069a4cbc7d5193aa8413a02b6dc05 xsa186-4.7-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJX0VLsAAoJEIP+FMlX6CvZoUoIAMvgdMZRYdK5MaaRUAA1hDG3 UFSxZCH8zja6wZG6WPNj7VqvEkQ2350oqb05BGB8jTFCmqtNDDIyHK68WaMpwDMv EEeetosujnlHTtVV7N8e0HO7F497PzZtzfniTyZc/h2Lna552ohMy/UcADtA7xxP IK6qwvxpkx1aLzsDFpHIdrVcttDD/oZcVbBFwcCAqK33eGNC3S6BJvIibCAKfO8h YKiAtvWUNsX/o4L9Zs4M50/pK3TzWsaDjfK3IX5LJPtsrcrKklrALVnDUOpTz1WA 07UIk0BcrzicEuTvuATWSQ3nVxUXAH95io23PCniHHntBtYJHjGA5rIqX+tiN6w= =HT+K -END PGP SIGNATURE- xsa186-0001-x86-emulate-Correct-boundary-interactions-of-emulate.patch Description: Binary data xsa186-0002-hvm-fep-Allow-testing-of-instructions-crossing-the-1.patch Description: Binary data xsa186-4.6-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch Description: Binary data xsa186-4.7-0002-hvm-fep-Allow-testing-of-instructions-crossing-the.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 184 (CVE-2016-5403) - virtio: unbounded memory allocation issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-5403 / XSA-184 version 2 virtio: unbounded memory allocation issue UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = A guest can submit virtio requests without bothering to wait for completion and is therefore not bound by virtqueue size. (This requires reusing vring descriptors in more than one request, which is incorrect but possible.) Processing a request allocates a VirtQueueElement and therefore causes unbounded memory allocation controlled by the guest. IMPACT == A malicious guest administrator can cause unbounded memory allocation in QEMU, which can cause an Out-of-Memory condition in the domain running qemu. Thus, a malicious guest administrator can cause a denial of service affecting the whole host. VULNERABLE SYSTEMS == ARM systems are not vulnerable. PV domains are not vulnerable. Only HVM domains where virtio-net devices are provided to the guest are vulnerable. Note that NO such devices are provided by default, so the default configuration is not vulnerable. HVM domains run with QEMU stub domains are not vulnerable. (Note that all virtio subsystems are affected; but only virtio-net is a supported configuration. See docs/misc/qemu-xen-security.) MITIGATION == Running PV only will avoid the issue. Running HVM domains with Xen PV drivers instead of virtio-net will avoid the issue. Running HVM domains with with stubdomains will mitigate the issue. CREDITS === This issue was discovered by Zhenhao Hong of the 360 Marvel Team. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa184-qemuu-master.patch qemu-upstream, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 4.4.x xsa184-qemut-master.patch qemu-traditional, Xen unstable, 4.7.x, 4.6.x, 4.5.x, 4.4.x $ sha256sum xsa184* ea41a25dac82cc5c0ef8e599feb6ed400e99414110d4dba8017d6bd048bc3de4 xsa184-qemut-master.patch 2d675e5e08d9443cf2e5f3aa37521241d6ed898a602b5111d6969023e67b9b6b xsa184-qemuu-master.patch $ NOTES ON THE EMBARGO PERIOD === Note that the embargo period is shorter than normal as the Xen Security team were only notified of the issue on 25 July. DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJXmNwVAAoJEIP+FMlX6CvZUUQIAMMpYEr4wyoPEWe1w/4TrtQt eTaDbBFFblfuHOTQcXZephlWBtSZ1bHbdEiTsQnflBYWLLiZZP1tud0f3MvN03uN M9kTv1LsAb29NC19Oy1w02AOVXm0XklA3JbFG5OoidWVYra0UQSFKeZvi8Tlqr5C ry2+jdErRGHsQFkjecBU0zSqXmz0+rcTlpzHtfJw3We3J9J4A1WPfAjXN3dL81yx Tdl3P2heokhR2jsZgi7ZgIBo/s4rD4wbRD5gL4pf6eokyJIib7NFhctMi8hLDkTL RbJh7sb+U9G5B2arMhRE7e00v7PgSfh+ossBQljszWhbHHCctggmGGIqWF0AvuQ= =+1d1 -END PGP SIGNATURE- xsa184-qemut-master.patch Description: Binary data xsa184-qemuu-master.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 183 (CVE-2016-6259) - x86: Missing SMAP whitelisting in 32-bit exception / event delivery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-6259 / XSA-183 version 5 x86: Missing SMAP whitelisting in 32-bit exception / event delivery UPDATES IN VERSION 5 Public release. ISSUE DESCRIPTION = Supervisor Mode Access Prevention is a hardware feature designed to make an Operating System more robust, by raising a pagefault rather than accidentally following a pointer into userspace. However, legitimate accesses into userspace require whitelisting, and the exception delivery mechanism for 32bit PV guests wasn't whitelisted. IMPACT == A malicious 32-bit PV guest kernel can trigger a safety check, crashing the hypervisor and causing a denial of service to other VMs on the host. VULNERABLE SYSTEMS == Xen version 4.5 and newer are vulnerable. Versions 4.4 and older are not, due to not having software support for SMAP. The vulnerability is only exposed on x86 hardware supporting the SMAP feature (Intel Broadwell and later CPUs). The vulnerability is not exposed on ARM hardware, or x86 hardware which do not support SMAP. The vulnerability is only exposed to x86 32bit PV guests. The vulnerability is not exposed to 64bit PV guests or HVM guests. MITIGATION == Running only HVM guests or 64-bit PV guests, avoids the vulnerability. Disabling SMAP in the hypervisor by booting Xen with "smap=0" on the command line will avoid this vulnerability. (Depending on the circumstances this workaround may pose a small risk of increasing the impact of other, possibly unknown, vulnerabilities.) CREDITS === This issue was discovered by Andrew Cooper of Citrix. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa183.patch xen-unstable, 4.7.x xsa183-4.6.patch Xen 4.6.x, 4.5.x $ sha256sum xsa183* ea0ea4b294332814330f222e6d78eea3b19c394eac8ae22feb4a5bd21e90331f xsa183-unstable.patch 0fee41f21a3eb4af1487590098047f4625688bcef7419572a8f418f9fb728468 xsa183-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Deployment of the "smap=0" mitigation is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because this produces a guest-visible change which could lead to rediscovery of the vulnerability. And: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJXl0M9AAoJEIP+FMlX6CvZYB4IAIkCjnrkDBqYcPJrnAAjNDGL v/qJiE6NAKlvqyi/pRkDodAk+5CLvvjDHmTBtqvT+7SU3ixt4C80MLiVMCuJVsUw kMcp95KsJne1TSoivAqSXED+J3gkIWXG8PYvpUOwwOqr0aJViuN9Uv52g0+MVUsW OnkHzYzyyMkIRi0bIzXmhvGeHTUxVhcz8RjMWsjD9FPb+i6lu/kfNUvpiecVa0mx 0J7ByS5l4iEefCH+beT35NFg1BfQINU3cMmDM/i8pklRuJI+HKCYFzPGJyl2+Ccr 0Zd7Lgub2jGsJjgXjBBPCHw/CCdlmX7RiiAvnIQU5adBtCIk6p0T0ugcGXwTIAw= =ydwH -END PGP SIGNATURE- xsa183-unstable.patch Description: Binary data xsa183-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 182 (CVE-2016-6258) - x86: Privilege escalation in PV guests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-6258 / XSA-182 version 3 x86: Privilege escalation in PV guests UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The PV pagetable code has fast-paths for making updates to pre-existing pagetable entries, to skip expensive re-validation in safe cases (e.g. clearing only Access/Dirty bits). The bits considered safe were too broad, and not actually safe. IMPACT == A malicous PV guest administrator can escalate their privilege to that of the host. VULNERABLE SYSTEMS == All versions of Xen are vulnerable. The vulnerability is only exposed to PV guests on x86 hardware. The vulnerability is not exposed to x86 HVM guests, or ARM guests. MITIGATION == Running only HVM guests will avoid this vulnerability. CREDITS === This issue was discovered by Jérémie Boutoille of Quarkslab. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa182.patch xen-unstable, Xen 4.7.x xsa182-4.6.patch Xen 4.6.x xsa182-4.5.patch Xen 4.5.x, 4.4.x, 4.3.x $ sha256sum xsa182* 303400b9a832a3c1d423cc2cc97c2f00482793722f9ef7dd246783a049ac2792 xsa182-unstable.patch 2383695b1dc114e4e31e42dd05d4c86239ce9606478b5e1a71dbd95b63a2 xsa182-4.5.patch f10665acaf17dedd15c40bfeb832b188db1ab3e789d95cc3787575529a280813 xsa182-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJXl0M8AAoJEIP+FMlX6CvZvsUIAKeTcuCNrXAkCMsa1jcTOJEB zo1sZB6DeUZjAjYm+vVTv3bcr8E9e+B02Cyg6Y97TByrpwsarvOyYZzds/wf3TO+ 3hm6cKPRBhUdQBgXLi6DqgsBIb+BvMEqT6jXpmNmLWqlJtuJPrCn74e2K0hXFgt2 RDELGjg6qsTW7hJtwNfkEI6/nj2/lBsNVHkp1F7olxT17euC4nJoLEzeDRc8UN/+ pf9UT1yoEVOddPA+iIjC7PeSYyWhJFyNR0m4BN7MshKEoy+tiIQJDZzyLJLh46uf c28vUByyu6fCersz63ZkpF9MHWR0+8cChOvmY3Tuyy/yitUMbcJoygu/35QV2tc= =u+6O -END PGP SIGNATURE- xsa182-unstable.patch Description: Binary data xsa182-4.5.patch Description: Binary data xsa182-4.6.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 178 (CVE-2016-4963) - Unsanitised driver domain input in libxl device handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-4963 / XSA-178 version 4 Unsanitised driver domain input in libxl device handling UPDATES IN VERSION 4 Clarify that issue goes back as far as driver domain suppoprt. Mention backports. ISSUE DESCRIPTION = libxl's device-handling code freely uses and trusts information from the backend directories in xenstore. The backend domain (driver domain) can store bogus data in the backend, causing libxl's enquiry functions to fail, confusing management tools. A driver domain can also remove its backend directory from xenstore entirely, preventing the device from showing up in device listings and preventing it from being removed and replaced. A driver domain can cause libxl to generate disk eject events for disks for which the driver domain is not responsible. IMPACT == A malicious driver domain can deny service to management tools. VULNERABLE SYSTEMS == This vulnerability is only applicable to systems which are using driver domains, and then only where the driver domain is not intended to be fully trusted with respect to the host. Such Xen systems using libxl based toolstacks (for example xl or libvirt with the libxl driver) are vulnerable. Note that even with this vulnerability a driver domain based system is better from a security point of view, than a system where devices are provided directly by dom0. Users and vendors of systems using driver domains should not change their configuration. All versions of libxl which support the relevant driver domains are vulnerable. MITIGATION == No mitigation is available. CREDITS === This issue was discovered by Wei Liu from Citrix. RESOLUTION == Applying the appropriate attached patch set from XSA-175, plus the appropriate attached patch set below, resolves this issue. xsa178-unstable/*.patch xen-unstable For earlier Xen releases, patches have been prepared and applied to the staging-4.X branches, back to Xen 4.3. The Xen Project CI system, osstest, is currently doing basic functional testing of these backports. However, driver domains are not tested by osstest, nor have they been tested by the Xen Project Security Team. The patches can be found in xen.git: xen.git commits 2805844bf20e..562ecb389444Xen 4.6 xen.git commits 6265a6fc7f58..d8ac67eff778Xen 4.5 xen.git commits 551948806424..a0b99aba04d9Xen 4.4 xen.git commits 5811d6bdf5bb..08ea21f2361dXen 4.3 See: http://xenbits.xen.org/gitweb/?p=xen.git;a=summary git://xenbits.xen.org/xen.git http://xenbits.xen.org/git-http/xen.git $ sha256sum xsa178-*/* fd6a1f858d44f618a4e792553598005871f63d12e718bc9b5477d14bf0113386 xsa178-unstable/0001-libxl-Make-copy-of-every-xs-backend-in-libxl-in-_gen.patch ee6cf66ad385203c49d9b030959715fb885a250aa36b85080e6985a603bb1ddb xsa178-unstable/0002-libxl-Do-not-trust-backend-in-libxl__device_exists.patch ea29cf28609c2d467fb7a620601af7bf434b098a7554dada956f11ed50c1b895 xsa178-unstable/0003-libxl-Do-not-trust-backend-for-vtpm-in-getinfo-excep.patch a2abc4308d9a18f49a02e6ca8ba913d4d9890867b7816dcc19b548836b65af6c xsa178-unstable/0004-libxl-Do-not-trust-backend-for-vtpm-in-getinfo-uuid.patch 2884e6566c59ae95792d4282e174c6b3d201c1e006b9e0ab57fbaad2b62ecfb9 xsa178-unstable/0005-libxl-cdrom-eject-and-insert-write-to-libxl.patch d6ac82211d056a386d18b8296a6a1f2e8a65e8156594595b9c34a3a377f1cf98 xsa178-unstable/0006-libxl-Do-not-trust-backend-for-disk-eject-vdev.patch 4c8bb7bee3b624b02796afdfa0157ea1dc49a7f54f34912f992bae201b6bfe40 xsa178-unstable/0007-libxl-Do-not-trust-backend-for-disk-fix-driver-domai.patch 556b14e8783ddd7ad0cb9a561ca43a40b37ccb27cd56337e7714ac0f796ce21b xsa178-unstable/0008-libxl-Do-not-trust-backend-for-disk-in-getinfo.patch b51aaa8cca1f367ae51ffb65240831617d4cab4a3fa6d0a2d42728e99ee8cee8 xsa178-unstable/0009-libxl-Do-not-trust-backend-for-cdrom-insert.patch 3ef493e6bda2d2b96a89cf18b55d43fbdb84a2cd5c10c88f04299434c629ba2b xsa178-unstable/0010-libxl-Do-not-trust-backend-for-channel-in-getinfo.patch da4db890c9e73fca006bc381f2208f9bff0fc35990c4dd51d5db27072d33 xsa178-unstable/0011-libxl-Rename-libxl__device_-nic-channel-_from_xs_be-.patch ae8b043a83cc35beee2205ab621b6f5bc6543f6d4dcdc06c97e07b1a17ca94bf xsa178-unstable/0012-libxl-Rename-READ_BACKEND-to-READ_LIBXLDEV.patch 936c44de9a344b0634b7bff4f5b3cf9c034a0080e87d267e7a84683a967d1bff xsa178-unstable/0013-libxl-Have-READ_LIBXLDEV-use-libxl_path-rather-than-.patch 3b65a3140387651cf2ed1bcf8668efecd58fbd274a62a03d785c269b55bea8fe xsa178-unstable/0014-libxl-Do-not-trust-backend-in-nic-getinfo.patch 6d009153b98fd58f316efa4f39c821cf609b54184726e15f887947321610ed14 xsa178-unstable/0015-libxl-Do-not-trust-backend-for-nic-in-devid_to_devic.patch 3105c062bb2017681f47499e2dd2f6cd2996539068f216a5af7d6143bc726eda
[Xen-devel] Xen Security Advisory 181 (CVE-2016-5242) - arm: Host crash caused by VMID exhaustion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-5242 / XSA-181 version 2 arm: Host crash caused by VMID exhaustion UPDATES IN VERSION 2 CVE assigned. ISSUE DESCRIPTION = VMIDs are a finite hardware resource, and allocated as part of domain creation. If no free VMIDs are available when trying to create a new domain, a bug in the error path causes a NULL pointer to be used, resulting in a Data Abort and host crash. IMPACT == Attempting to create too many concurrent domains causes a host crash rather than a graceful error. A malicious device driver domain can hold references to domains, preventing its VMID being released. VULNERABLE SYSTEMS == Xen versions 4.4 and later are affected. Older Xen versions are unaffected. x86 systems are not affected. Only arm systems with less-privileged device driver domains can expose this vulnerability. MITIGATION == There is no mitigation. Not using driver domains reclassifies the problem, but does not fix it. NOTE REGARDING LACK OF EMBARGO == The crash was discussed publicly on xen-devel, before it was appreciated that there was a security problem. CREDITS === This issue was discovered by Aaron Cornelius of DornerWorks. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa181.patch xen-unstable, Xen 4.6.x, 4.5.x xsa181-4.4.patch Xen 4.4.x $ sha256sum xsa181* 6756fcf6675e5277f6d6c0e8a0aaa51a7909ad9a55af89a09367fded8733 xsa181.patch 97a90c7cb42466647622cb2ed98de531b7ba2e174a1bc639a32a6f1b626d503f xsa181-4.4.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEbBAEBAgAGBQJXUYxcAAoJEIP+FMlX6CvZgAAH+OiNDLSkAHUl3isXjFzK+Mf9 NGuIyXc2j5K8uTwz5KvZkhiWLVCeOY7Jo1Wix3Fa1wFtJ2rMlgQf7/hOt0tk0NjU w97Re+xSi69iruPEdwb4k31ohnlfLSqriqL4JWh6EDrhftdnvEk/yXmriyu1RhKy MLk1P24Ora/gvSj31px3vBkbu8KLImhIOkOcRmJ7FQb8gWsmMDluuVu7lhUAL7im KCe6u99sDQo18wxubYID4XxFqJExBUd6L3cnpdN4UITgylSaIqJq/RBwd8jRrxW8 MxT9/IcNf0rmB1Sh1IARBFF7P7hj76ho3sIpMeE0cMPWBe2NWMItX9ula61vQA== =kBFB -END PGP SIGNATURE- xsa181.patch Description: Binary data xsa181-4.4.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 181 - arm: Host crash caused by VMID exhaustion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-181 arm: Host crash caused by VMID exhaustion ISSUE DESCRIPTION = VMIDs are a finite hardware resource, and allocated as part of domain creation. If no free VMIDs are available when trying to create a new domain, a bug in the error path causes a NULL pointer to be used, resulting in a Data Abort and host crash. IMPACT == Attempting to create too many concurrent domains causes a host crash rather than a graceful error. A malicious device driver domain can hold references to domains, preventing its VMID being released. VULNERABLE SYSTEMS == Xen versions 4.4 and later are affected. Older Xen versions are unaffected. x86 systems are not affected. Only arm systems with less-privileged device driver domains can expose this vulnerability. MITIGATION == There is no mitigation. Not using driver domains reclassifies the problem, but does not fix it. NOTE REGARDING LACK OF EMBARGO == The crash was discussed publicly on xen-devel, before it was appreciated that there was a security problem. CREDITS === This issue was discovered by Aaron Cornelius of DornerWorks. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa181.patch xen-unstable, Xen 4.6.x, 4.5.x xsa181-4.4.patch Xen 4.4.x $ sha256sum xsa181* 6756fcf6675e5277f6d6c0e8a0aaa51a7909ad9a55af89a09367fded8733 xsa181.patch 97a90c7cb42466647622cb2ed98de531b7ba2e174a1bc639a32a6f1b626d503f xsa181-4.4.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJXUVIbAAoJEIP+FMlX6CvZAe8IAIwe1A/05KM9PfJTCwb23WEs pfSiEZy7KzmavYwzV4TLwzWuCNzkRAuEejvQ9dTFnk8ZBkCZIbAaMoCPJljK/8gg oBcn0cXE9Kz9kWBk+JCWHynboVh010p+7DGlcvrxmAwxJCUjGy4YcajDZ4uGJoHA pgJxIk/w4CIzF+AQYm7bRW8dHF3yym4V6dmR4pGqXeYS41XbMqpEenGBggoBeH+C TJLUzaNZfATcPK5NUCqBD7IiQtHyYJT8xEtIKDH4hfjEzffydHbErDb/lKk3fxK0 ECzrhdWMExnkUX4VkC393QaqGf78P6sa+psfZt4I7DDFDI2uEvXYmgVXjOuvSpg= =hUSO -END PGP SIGNATURE- xsa181.patch Description: Binary data xsa181-4.4.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 178 (CVE-2016-4963) - Unsanitised driver domain input in libxl device handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-4963 / XSA-178 version 3 Unsanitised driver domain input in libxl device handling UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = libxl's device-handling code freely uses and trusts information from the backend directories in xenstore. The backend domain (driver domain) can store bogus data in the backend, causing libxl's enquiry functions to fail, confusing management tools. A driver domain can also remove its backend directory from xenstore entirely, preventing the device from showing up in device listings and preventing it from being removed and replaced. A driver domain can cause libxl to generate disk eject events for disks for which the driver domain is not responsible. IMPACT == A malicious driver domain can deny service to management tools. VULNERABLE SYSTEMS == This vulnerability is only applicable to systems which are using driver domains, and then only where the driver domain is not intended to be fully trusted with respect to the host. Such Xen systems using libxl based toolstacks (for example xl or libvirt with the libxl driver) are vulnerable. Note that even with this vulnerability a driver domain based system is better from a security point of view, than a system where devices are provided directly by dom0. Users and vendors of systems using driver domains should not change their configuration. MITIGATION == No mitigation is available. CREDITS === This issue was discovered by Wei Liu from Citrix. RESOLUTION == Applying the appropriate attached patch set from XSA-175, plus the appropriate attached patch set below, resolves this issue. xsa178-unstable/*.patch xen-unstable $ sha256sum xsa178-*/* fd6a1f858d44f618a4e792553598005871f63d12e718bc9b5477d14bf0113386 xsa178-unstable/0001-libxl-Make-copy-of-every-xs-backend-in-libxl-in-_gen.patch ee6cf66ad385203c49d9b030959715fb885a250aa36b85080e6985a603bb1ddb xsa178-unstable/0002-libxl-Do-not-trust-backend-in-libxl__device_exists.patch ea29cf28609c2d467fb7a620601af7bf434b098a7554dada956f11ed50c1b895 xsa178-unstable/0003-libxl-Do-not-trust-backend-for-vtpm-in-getinfo-excep.patch a2abc4308d9a18f49a02e6ca8ba913d4d9890867b7816dcc19b548836b65af6c xsa178-unstable/0004-libxl-Do-not-trust-backend-for-vtpm-in-getinfo-uuid.patch 2884e6566c59ae95792d4282e174c6b3d201c1e006b9e0ab57fbaad2b62ecfb9 xsa178-unstable/0005-libxl-cdrom-eject-and-insert-write-to-libxl.patch d6ac82211d056a386d18b8296a6a1f2e8a65e8156594595b9c34a3a377f1cf98 xsa178-unstable/0006-libxl-Do-not-trust-backend-for-disk-eject-vdev.patch 4c8bb7bee3b624b02796afdfa0157ea1dc49a7f54f34912f992bae201b6bfe40 xsa178-unstable/0007-libxl-Do-not-trust-backend-for-disk-fix-driver-domai.patch 556b14e8783ddd7ad0cb9a561ca43a40b37ccb27cd56337e7714ac0f796ce21b xsa178-unstable/0008-libxl-Do-not-trust-backend-for-disk-in-getinfo.patch b51aaa8cca1f367ae51ffb65240831617d4cab4a3fa6d0a2d42728e99ee8cee8 xsa178-unstable/0009-libxl-Do-not-trust-backend-for-cdrom-insert.patch 3ef493e6bda2d2b96a89cf18b55d43fbdb84a2cd5c10c88f04299434c629ba2b xsa178-unstable/0010-libxl-Do-not-trust-backend-for-channel-in-getinfo.patch da4db890c9e73fca006bc381f2208f9bff0fc35990c4dd51d5db27072d33 xsa178-unstable/0011-libxl-Rename-libxl__device_-nic-channel-_from_xs_be-.patch ae8b043a83cc35beee2205ab621b6f5bc6543f6d4dcdc06c97e07b1a17ca94bf xsa178-unstable/0012-libxl-Rename-READ_BACKEND-to-READ_LIBXLDEV.patch 936c44de9a344b0634b7bff4f5b3cf9c034a0080e87d267e7a84683a967d1bff xsa178-unstable/0013-libxl-Have-READ_LIBXLDEV-use-libxl_path-rather-than-.patch 3b65a3140387651cf2ed1bcf8668efecd58fbd274a62a03d785c269b55bea8fe xsa178-unstable/0014-libxl-Do-not-trust-backend-in-nic-getinfo.patch 6d009153b98fd58f316efa4f39c821cf609b54184726e15f887947321610ed14 xsa178-unstable/0015-libxl-Do-not-trust-backend-for-nic-in-devid_to_devic.patch 3105c062bb2017681f47499e2dd2f6cd2996539068f216a5af7d6143bc726eda xsa178-unstable/0016-libxl-Do-not-trust-backend-for-nic-in-list.patch 97961ce38d8d77e9d91ee85052fd33e04d19f45e5ddfec61f82dc9c8a78158ea xsa178-unstable/0017-libxl-Do-not-trust-backend-in-channel-list.patch 6ebb611501b66dca66259d3a790e30ae6d892eb27c6d06577d8f399d619c286b xsa178-unstable/0018-libxl-Do-not-trust-backend-for-vusb.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. HOWEVER note that deployment of the patches for XSA-175 (which are a prerequisite for the patches for XSA-178) is restricted. See XSA-175's `Deployment During Embargo' section for details. But: Distribution of updated software is prohibited (except to other members of the predisclosure
[Xen-devel] Xen Security Advisory 180 (CVE-2014-3672) - Unrestricted qemu logging
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2014-3672 / XSA-180 Unrestricted qemu logging ISSUE DESCRIPTION = When the libxl toolstack launches qemu for HVM guests, it pipes the output of stderr to a file in /var/log/xen. This output is not rate-limited in any way. The guest can easily cause qemu to print messages to stderr, causing this file to become arbitrarily large. IMPACT == The disk containing the logfile can be exausted, possibly causing a denial-of-service (DoS). VULNERABLE SYSTEMS == All versions of Xen are affected. Only x86 systems are affected; ARM systems are not affected. Only systems running HVM guests are affected; systems running only PV guests are not affected. Both qemu-upstream and qemu-traditional are affected. MITIGATION == Running only PV guests will avoid this vulnerability. CREDITS === This issue was discovered by Andrew Sorensen of leviathansecurity.com. RESOLUTION == Applying the appropriate attached patch resolves this issue. The patches adopt a simple and rather crude approach which is effective at resolving the security issue in the context of a Xen device model. They may not be appropriate for adoption upstream or in other contexts. xsa180-qemut.patch qemu-xen-traditional (all supported versions) xsa180-qemuu.patch qemu-xen (upstream) Xen unstable $ sha256sum xsa180* 7733fd57868c4313c7c47ccde3aba21e9ed5002ee8a937b20997fb3d2282a5d7 xsa180-qemut.patch 7a92bbd3b6368f91e694400c8e850567972e14852e4f61fbb61cc3b7b98f14ef xsa180-qemuu.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJXQzkrAAoJEIP+FMlX6CvZjkYIAMJRhIzcKP7P8Q075WKw29e2 PpLFy+eOM/946SOnKxrN/1Pq+yYl5Jn1rN/TMRre4n6pYdGlGY/+MFa4N2tfKhBv 8dYcE2BMD9tbLi4SpbvoIMUtmLM1y0lVSmtHbMaw/zQDpT0uM1Kh+P0VjTeBADo/ PgRgePGfV7r+4nVjxjdSiNah8XAR5P/hoHNGOaM2kuIT19FwyDK7uQONE+HL2SdI ccA+JAMZFlHs1/hcjeCLny7Soedy4GPfGfqUpu/zRkaaDmCkG1E+gfcox5S2myYc Kogj7oiVWjRTcYh5cUOIfSmC4TDM8pqWnMmFftGShOvWqRJH3tUWt3TkaU669X8= =SczG -END PGP SIGNATURE- xsa180-qemut.patch Description: Binary data xsa180-qemuu.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 176 (CVE-2016-4480) - x86 software guest page walk PS bit handling flaw
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-4480 / XSA-176 version 3 x86 software guest page walk PS bit handling flaw UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = The Page Size (PS) page table entry bit exists at all page table levels other than L1. Its meaning is reserved in L4, and conditionally reserved in L3 and L2 (depending on hardware capabilities). The software page table walker in the hypervisor, however, so far ignored that bit in L4 and (on respective hardware) L3 entries, resulting in pages to be treated as page tables which the guest OS may not have designated as such. If the page in question is writable by an unprivileged user, then that user will be able to map arbitrary guest memory. IMPACT == On vulnerable OSes, guest user mode code may be able to establish mappings of arbitrary memory inside the guest, allowing it to elevate its privileges inside the guest. VULNERABLE SYSTEMS == All Xen versions expose the vulnerability. ARM systems are not vulnerable. x86 PV guests are not vulnerable. To be vulnerable, a system must have both a vulnerable hypervisor, and a vulnerable guest operating system, i.e. ones which make non-standard use of the PS bit. We are not aware of any vulnerable guest operating systems, but we cannot rule it out. We have checked with maintainers of the following operating systems, all of whom have said that to the best of their knowledge their operating system is not vulnerable: Linux, FreeBSD, NetBSD, OpenBSD, and Solaris. Nor has it been observed in common proprietary operating systems. MITIGATION == Running only PV guests will avoid this issue. CREDITS === This issue was discovered by Jan Beulich from SUSE. RESOLUTION == Applying the attached patch resolves this issue. Note, however, that on hosts supporting 1Gb page mappings, for guests which get this capability hidden via CPUID override in their config file, fully correct behavior cannot be provided when using HAP paging. This is a result of hardware behavior, which software cannot mitigate. If that is a concern, such guests would need to be run in shadow paging mode. xsa176.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x $ sha256sum xsa176* e61c52477a8d8aa79111d686b103202ff8a558d8b3356635288c1290789b7eb3 xsa176.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJXOvhuAAoJEIP+FMlX6CvZ8JgH/A7YU+62hV5ayIx77AEwHeIJ 6nqf6B1k+Y0aEtiSbupHDIMwSw13FoR+LluaZjTXpBd251Ut1cwXkDvC6yiPHxq0 rWlb1/ka0rnOT3/rx0SgUjx02HbBzOFyyhZgR6W/gXV/S5fQhE26KbhEWvVaYCXO QeryIsi9WBV/AWbx4fis4ecREhyEWPYkJ/bQq867P6YJLXQ1btc/CyZ7ahBjna68 VB9WE8czSs2x5QjJfKad5ksRAixdvaLFtVNOhnqJuJBickO3dd/IZPRxcSmazjdl sIiSMfKU9nPb56MIgZxTWCLpvYLe8yarnvjiVOivaHl2cBT01UOjVJv/dSQEyrw= =uQdJ -END PGP SIGNATURE- xsa176.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 179 (CVE-2016-3710, CVE-2016-3712) - QEMU: Banked access to VGA memory (VBE) uses inconsistent bounds checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-3710,CVE-2016-3712 / XSA-179 version 5 QEMU: Banked access to VGA memory (VBE) uses inconsistent bounds checks UPDATES IN VERSION 5 Fixed credits section. Zuozhi Fzz was mistakenly credited with CVE-2016-3710, but should have been credited with CVE-2016-3712. ISSUE DESCRIPTION = Qemu VGA module allows banked access to video memory using the window at 0xa0 and it supports different access modes with different address calculations. But an attacker can easily change access modes after setting the bank register. This is CVE-2016-3710. Qemu VGA module allows guest to edit certain registers in 'vbe' and 'vga' modes. ie. guest could set certain 'VGA' registers while in 'VBE' mode. This is CVE-2016-3712. IMPACT == A privileged guest user could use CVE-2016-3710 to exceed the bank address window and write beyond the said memory area, potentially leading to arbitrary code execution with privileges of the Qemu process. If the system is not using stubdomains, this will be in domain 0. A privileged guest user could use CVE-2016-3712 to cause potential integer overflow or OOB read access issues in Qemu, resulting in a DoS of the guest itself. More dangerous effect, such as data leakage or code execution, are not known but cannot be ruled out. 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 "stdvga" emulated video card can exploit the vulnerability. The default "cirrus" 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 cirrus (stdvga=0, vga="cirrus", in the xl domain configuraton) will avoid the vulnerability. CREDITS === CVE-2016-3710 was discovered and reported by "Wei Xiao and Qinghao Tang of 360 Marvel Team" of 360.cn Inc. CVE-2016-3712 was discovered and reported by Zuozhi Fzz of Alibaba Inc. RESOLUTION == Applying the appropriate attached patch resolves this issue for systems using upstream-based versions of qemu. Patch 0001 addresses CVE-2016-3710, and patches 0002-0005 address CVE-2016-3712. qemu-upstream, xen-unstable: xsa179-qemuu-unstable-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-unstable-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-unstable-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-unstable-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-unstable-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.6: xsa179-qemuu-4.6-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.6-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.6-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.6-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.6-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.5: xsa179-qemuu-4.5-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.5-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.5-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.5-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.5-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.4: xsa179-qemuu-4.4-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.4-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.4-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.4-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.4-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.3: xsa179-qemuu-4.3-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.3-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.3-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.3-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.3-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-xen-traditional, unstable:
[Xen-devel] Xen Security Advisory 179 (CVE-2016-3710, CVE-2016-3712) - QEMU: Banked access to VGA memory (VBE) uses inconsistent bounds checks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-3710,CVE-2016-3712 / XSA-179 version 4 QEMU: Banked access to VGA memory (VBE) uses inconsistent bounds checks UPDATES IN VERSION 4 Public release. Also include CVE and description of both issues. (All advisories sent have included patches for both issues, but only the description and CVE for the first issue.) ISSUE DESCRIPTION = Qemu VGA module allows banked access to video memory using the window at 0xa0 and it supports different access modes with different address calculations. But an attacker can easily change access modes after setting the bank register. This is CVE-2016-3710. Qemu VGA module allows guest to edit certain registers in 'vbe' and 'vga' modes. ie. guest could set certain 'VGA' registers while in 'VBE' mode. This is CVE-2016-3712. IMPACT == A privileged guest user could use CVE-2016-3710 to exceed the bank address window and write beyond the said memory area, potentially leading to arbitrary code execution with privileges of the Qemu process. If the system is not using stubdomains, this will be in domain 0. A privileged guest user could use CVE-2016-3712 to cause potential integer overflow or OOB read access issues in Qemu, resulting in a DoS of the guest itself. More dangerous effect, such as data leakage or code execution, are not known but cannot be ruled out. 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 "stdvga" emulated video card can exploit the vulnerability. The default "cirrus" 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 cirrus (stdvga=0, vga="cirrus", in the xl domain configuraton) will avoid the vulnerability. CREDITS === CVE-2016-3710 was discovered and reported by "Wei Xiao and Qinghao Tang of 360 Marvel Team" of 360.cn Inc. CVE-2016-3710 was discovered and reported by Zuozhi Fzz of Alibaba Inc. RESOLUTION == Applying the appropriate attached patch resolves this issue for systems using upstream-based versions of qemu. Patch 0001 addresses CVE-2016-3710, and patches 0002-0005 address CVE-2016-3712. qemu-upstream, xen-unstable: xsa179-qemuu-unstable-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-unstable-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-unstable-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-unstable-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-unstable-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.6: xsa179-qemuu-4.6-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.6-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.6-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.6-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.6-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.5: xsa179-qemuu-4.5-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.5-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.5-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.5-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.5-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.4: xsa179-qemuu-4.4-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.4-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.4-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.4-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.4-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-upstream, xen 4.3: xsa179-qemuu-4.3-0001-vga-fix-banked-access-bounds-checking-CVE-2016-3710.patch xsa179-qemuu-4.3-0002-vga-add-vbe_enabled-helper.patch xsa179-qemuu-4.3-0003-vga-factor-out-vga-register-setup.patch xsa179-qemuu-4.3-0004-vga-update-vga-register-setup-on-vbe-changes.patch xsa179-qemuu-4.3-0005-vga-make-sure-vga-register-setup-for-vbe-stays-intac.patch qemu-xen-traditional, unstable:
[Xen-devel] Xen Security Advisory 173 (CVE-2016-3960) - x86 shadow pagetables: address width overflow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-3960 / XSA-173
version 3
x86 shadow pagetables: address width overflow
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
In the x86 shadow pagetable code, the guest frame number of a
superpage mapping is stored in a 32-bit field. If a shadowed guest
can cause a superpage mapping of a guest-physical address at or above
2^44 to be shadowed, the top bits of the address will be lost, causing
an assertion failure or NULL dereference later on, in code that
removes the shadow.
IMPACT
==
A HVM guest using shadow pagetables can cause the host to crash.
A PV guest using shadow pagetables (i.e. being migrated) with PV
superpages enabled (which is not the default) can crash the host, or
corrupt hypervisor memory, and so a privilege escalation cannot be
ruled out.
VULNERABLE SYSTEMS
==
Xen versions from 3.4 onwards are affected.
Only x86 variants of Xen are susceptible. ARM variants are not
affected.
HVM guests using shadow mode paging can expose this vulnerability. HVM
guests using Hardware Assisted Paging (HAP) are unaffected.
Systems running PV guests with PV superpages enabled are vulnerable if
those guests undergo live migration. PV superpages are disabled by
default, so systems are not vulnerable in this way unless
"allowsuperpage" is on the Xen command line.
To discover whether your HVM guests are using HAP, or shadow page
tables: request debug key `q' (from the Xen console, or with
`xl debug-keys q'). This will print (to the console, and visible in
`xl dmesg'), debug information for every domain, containing something
like this:
(XEN) General information for domain 2:
(XEN) refcnt=1 dying=2 pause_count=2
(XEN) nr_pages=2 xenheap_pages=0 shared_pages=0 paged_pages=0
dirty_cpus={} max_pages=262400
(XEN) handle=ef58ef1a-784d-4e59-8079-42bdee87f219 vm_assist=
(XEN) paging assistance: hap refcounts translate external
^^^
The presence of `hap' here indicates that the host is not
vulnerable to this domain. For an HVM domain the presence of `shadow'
indicates that the domain can exploit the vulnerability.
MITIGATION
==
Running only PV guests will avoid this vulnerability, unless PV
superpage support is enabled (see above).
Running HVM guests with Hardware Assisted Paging (HAP) enabled will
also avoid this vulnerability. This is the default mode on hardware
supporting HAP, but can be overridden by hypervisor command line
option and guest configuration setting. Such overrides ("hap=0" in
either case, with variants like "no-hap" being possible in the
hypervisor command line case) would need to be removed to avoid this
vulnerability.
CREDITS
===
This issue was discovered by Ling Liu and Yihan Lian of the Cloud
Security Team, Qihoo 360.
RESOLUTION
==
Applying the appropriate attached patch resolves this issue.
xsa173-unstable.patch xen-unstable
xsa173-4.6.patch Xen 4.6.x
xsa173-4.5.patch Xen 4.5.x
xsa173-4.4.patch Xen 4.4.x
xsa173-4.3.patch Xen 4.3.x
$ sha256sum xsa173*
bd4619334351afc9f71bb529e8ac102c63415bb4d13197e3bd24a58de03726cb
xsa173-unstable.patch
089c07f0c8237da674796f155ee7e3c0305efd11a59df30ef2c3d5f6b423bfea
xsa173-4.3.patch
35e02b8d4c2841ad951dd967b4f11aa7911fe5d52be2cb605b174e8c2e9214ca
xsa173-4.4.patch
8cd255416975b5589b85911142b385cc1ed78b8ea5e16ebe9d6c60e2679b23aa
xsa173-4.5.patch
6dbc34e3e2d4415967c4406e0f8392a9395bff74da115ae20f26bd112b19017c
xsa173-4.6.patch
$
DEPLOYMENT DURING EMBARGO
=
Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.
But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).
Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.
(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable. This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)
For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJXFOGhAAoJEIP+FMlX6CvZXUYH/A1ekMpU71/JUK1c53qHmaTY
ZCsJj5hArL9poTYss/AfyumZRATalPrbX/Wt6JaVMutMefgPjphP8OKTzywr/aDJ
vRIim4piOABS15cWtYlfTans6X4yyk1NxmMt182osRW1JSW+OrjXORs6719zoEL7
3hzuf7g6pYiaVqtUmLEx9/U3T246ZaQ98V93YVxGGUyUYRBmFJxEAtA2yf4SlqNX
[Xen-devel] Xen Security Advisory 174 (CVE-2016-3961) - hugetlbfs use may crash PV Linux guests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-3961 / XSA-174 version 3 hugetlbfs use may crash PV Linux guests UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = Huge (2Mb) pages are generally unavailable to PV guests. Since x86 Linux pvops-based kernels are generally multi purpose, they would normally be built with hugetlbfs support enabled. Use of that functionality by an application in a PV guest would cause an infinite page fault loop, and an OOPS to occur upon an attempt to terminate the hung application. IMPACT == Depending on the guest kernel configuration, the OOPS could result in a kernel crash (guest DoS). VULNERABLE SYSTEMS == All upstream x86 Linux versions operating as PV Xen guests are vulnerable. ARM systems are not vulnerable. x86 HVM guests are not vulnerable. x86 Linux versions derived from linux-2.6.18-xen.hg (XenoLinux) are not vulnerable. Oracle Unbreakable Enterprise Kernels are not vulnerable. We believe that non-Linux guests are not vulnerable, as we are not aware of any with an analogous bug. MITIGATION == Running only HVM guests will avoid this issue. Not enabling hugetlbfs use, by not altering the boot time default value of zero in /proc/sys/vm/nr_hugepages (which can only be written by the root user) will avoid this issue. It is possible that disabling (or not enabling) the "panic on OOPS" behavior (via use of the "oops=panic" command line option or the "panic_on_oops" sysctl) will also avoid this issue, by limiting the effect to an application crash. We are not currently sure whether this is an effective mitigation, as we are not sure whether any locks or mutexes are held at the point of the crash. CREDITS === This issue was discovered by Vitaly Kuznetsov from Red Hat. RESOLUTION == Applying the attached patch resolves this issue. xsa174.patch Linux 4.5.x ... 3.10.x $ sha256sum xsa174* cbec70e183f76b4081ebba05c0a8105bd4952d164a2e5c40528c05bf8861ddef xsa174.patch $ DEPLOYMENT DURING EMBARGO = Deployment of patches or mitigations is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because such host configuration changes would be user mode visible, which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJXD5UqAAoJEIP+FMlX6CvZtAEIAKUf33cM1Gs+Y8Yt+s3FLvqR RW9Ktbz0dqMfL+4govcvfbI5CdtB75ZWp6T4rrjGrtIvljEJWAERasKA0anIW00I 5duFtbFN+nPlmdZUfGIW3G6kpveSstOICVxqKPn0chN7VuTZJvzogc9t9PTtvwpX +UkzvUvMacu0u8H0mJFjcuS/xFeS5LaosOCrJwAWKP1je6fwc217MrYm8LH6vwGr K7yJVnEih0XGv5hy9ufwcF5SI0d4CSilcxfFAqKJkRwQ2SSbsF2BXN1j11Eqmua3 ARif+g3qBH6uH+RT6bclUOUO3vCKcReBWjRCF+bbsdDMCmSLwdkQK8xtu7N/Tys= =u89I -END PGP SIGNATURE- xsa174.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 172 (CVE-2016-3158, CVE-2016-3159) - broken AMD FPU FIP/FDP/FOP leak workaround
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172 version 3 broken AMD FPU FIP/FDP/FOP leak workaround UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = There is a workaround in Xen to deal with the fact that AMD CPUs don't load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS), and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending unmasked exception. (See XSA-52.) However, this workaround does not cover all possible input cases. This is because writes to the hardware FSW.ES bit, which the current workaround is based on, are ignored; instead, the CPU calculates FSW.ES from the pending exception and exception mask bits. Xen therefore needs to do the same. Note that part of said workaround was the subject of XSA-52. This can leak register contents from one guest to another. The registers in question are the FPU instruction and data pointers and opcode. IMPACT == A malicious domain is able to obtain address space usage and timing information, about another domain, at a fairly low rate. The leaked address information might be used to help defeat address space randomisation in order to enable another attack. The leaked address and timing information forms a low-bandwidth covert channel which might be used to gain information about the operation of a target guest. The affected FPU facility would not normally be used by cryptographic operations, as it does not provide cryptographically-relevant SIMD functions. It appears to us very unlikely that the leak might directly compromise sensitive information such as cryptographic keys, although (without knowledge of the guest software) this cannot be ruled out. (This is notwithstanding the contrary statement in `Impact' in XSA-52.) VULNERABLE SYSTEMS == Xen versions 4.0 and onwards are vulnerable. Any kind of guest can exploit the vulnerability. The vulnerability is exposed only on AMD x86 systems. Intel and ARM systems do not expose this vulnerability. Both PV and HVM guests are affected. MITIGATION == The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. On Xen versions 4.3 and earlier, turning off XSAVE support via the "no-xsave" hypervisor command line option will avoid the vulnerability. On Xen versions 4.4 and onwards there is no other known mitigation. CREDITS === This issue was discovered by Jan Beulich from SUSE. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa172.patch xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x xsa172-4.3.patch Xen 4.3.x $ sha256sum xsa172* f18282fcb794b8772bc3af51d56860050071bd62a5a909b8f2fc2018e2958154 xsa172.patch 6aac179620afcdbdab041163239019bc35b0e243f3bd16673caaec7d5a4d97ec xsa172-4.3.patch $ NOTE REGARDING CVE == CVE-2016-3158 is for the code change which is required for all versions (but which is sufficient only on Xen 4.3.x, and insufficient on later versions). Ie for the second hunk in xsa172.patch (the only hunk in xsa172-4.3.patch), which patches the function xrstor. CVE-2016-3159 is for the code change which is applicable for later versions only, but which must always be combined with the code change for CVE-2016-3158. Ie for the first hunk in xsa172.patch, which patches the function fpu_fxrstor. DEPLOYMENT DURING EMBARGO = Deployment of the PATCH or the TRUSTED KERNEL MITIGATION (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the "no-xsave" MITIGATION is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because such a host configuration change would be guest-visible which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible
[Xen-devel] Xen Security Advisory 171 (CVE-2016-3157) - I/O port access privilege escalation in x86-64 Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-3157 / XSA-171 version 4 I/O port access privilege escalation in x86-64 Linux UPDATES IN VERSION 4 Clarify Vulnerable Systems section. Public release. ISSUE DESCRIPTION = IRET and POPF do not modify EFLAGS.IOPL when executed by code at a privilege level other than zero. Since PV Xen guests run at privilege level 3 (for 64-bit ones; 32-bit ones run at privilege level 1), to compensate for this the context switching of EFLAGS.IOPL requires the guest to make use of a dedicated hypercall (PHYSDEVOP_set_iopl). The invocation of this hypercall, while present in the 32-bit context switch path, is missing from its 64-bit counterpart. IMPACT == User mode processes not supposed to be able to access I/O ports may be granted such permission, potentially resulting in one or more of in-guest privilege escalation, guest crashes (Denial of Service), or in-guest information leaks. VULNERABLE SYSTEMS == All upstream x86-64 Linux versions operating as PV Xen guests are vulnerable. ARM systems are not vulnerable. x86 HVM guests are not vulnerable. 32-bit Linux guests are not vulnerable. x86-64 Linux versions derived from linux-2.6.18-xen.hg (XenoLinux) are not vulnerable. We believe that non-Linux guests are not vulnerable, as we are not aware of any with an analogous bug. MITIGATION == Running only HVM or 32-bit PV guests will avoid this issue. CREDITS === This issue was discovered by Andy Lutomirski. RESOLUTION == Applying the attached patch resolves this issue for the indicated Linux versions. xsa171.patch Linux 4.5-rc7, Linux 4.4.x $ sha256sum xsa171* 5d47ead1212c735b444ac8f82e7f311cda3473fe3847e576c3772ce020265dfd xsa171.patch $ DEPLOYMENT DURING EMBARGO = The patch is a change to the domU, ie, to the guest, not to hosts. Where the guest kernel is provided by the host administrator - Deployment of the patch by the host administrator is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because a the cloud guest administrator is almost certainly in a position to see the changes that are made by to the kernel even if the kernel is provided by the host administrator. Deployment is permitted only AFTER the embargo ends. Where the guest kernel is provided by the guest administrator - - Deployment of the patch (or another which is substantially similar) by the guest administrator is permitted during the embargo ONLY if (i) the host administrator organisation is also a member of the Xen Project Security Issues Predisclosure List. (ii) all the guest's users are also members of predisclosure list. (guest users includes administrators of Linux containers running within the guest). Restriction (i) is because the host administrator can see changes that made to the kernel by a guest administrator. Restriction (ii) is because it is difficult to fully conceal the Linux kernel from unprivileged guest user processes. If the host is not operated by a member of the predisclosure list, or the guest has users outside the predisclousre list, deployment is permitted only AFTER the embargo ends. In any case - --- Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, or whose situation is not clearly covered above, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJW6a4ZAAoJEIP+FMlX6CvZEs4H/12hKU3NzqfHZb/wOW9PeT4Z yhGQ2mkVE6FATW15b+/+Lr4N2nIUHa40BtWjPyEOQR4UXJrZr3R5HL/wINRO7c6M 5XNjDyHqmfhOAsHWsrTB0a3CP2wWNNQ6LiBN5AuiUwoqiJiZPLhKCeEi99F+rFFK IINyOgd4XSeGRkb96GfZcPbizbO3wqiREfBIAjECYchBARv7JVGr3my6R3YBYdTn VtBratEPdkEmAEn0LtdiQlnjPib5O3paiaIDk41IPbPu1WPiozt3RJSqJUSwu+al A3qe9cBGz0NyghdYkXQjvaPP+1Q3BjyJC4hgGLo+yqyODPdaFAJZ0mjR/e0uajs= =F9Nz -END PGP SIGNATURE- xsa171.patch Description: Binary data ___ Xen-devel
[Xen-devel] Xen Security Advisory 154 (CVE-2016-2270) - x86: inconsistent cachability flags on guest mappings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2016-2270 / XSA-154 version 3 x86: inconsistent cachability flags on guest mappings UPDATES IN VERSION 3 Clarify cumbersome Resolution wording. The patch now adds a command line option to overcome the possible performance regression. Add patch backports. Clarify origin of assertion (at start of patch description) that inconsistent cacheability is a problem only for mmio pages. Public release. ISSUE DESCRIPTION = Multiple mappings of the same physical page with different cachability setting can cause problems. While one category (risk of using stale data) affects only guests themselves (and hence avoiding this can be left for them to control), the other category being Machine Check exceptions can be fatal to entire hosts. According to the information we were able to gather, only mappings of MMIO pages may surface this second category, but even for them there were cases where the hypervisor did not properly enforce consistent cachability. IMPACT == A malicious guest administrator might be able to cause a reboot, denying service to the entire host. VULNERABLE SYSTEMS == All Xen versions are affected. Only x86 guests given control over some physical device can trigger this vulnerability. x86 systems are vulnerable. ARM systems are not vulnerable. The vulnerability depends on the system response to mapping the same memory with different cacheability. On some systems this is harmless; on others, depending on CPU and chipset, it may be fatal. MITIGATION == Not handing physical devices to guests will also avoid this issue. CREDITS === This issue was discovered by Jan Beulich of SUSE. RESOLUTION == We believe that the attached patch fixes the issue. However, no formal description of CPU behaviour in particular use cases has been provided by Intel. There has been no response from AMD. We are aware of a potential performance regression with this patch on some systems - even if no hardware passthrough is configured. This is due to the behaviour of some drivers and peripherals that is beyond the scope of this security fix. The patch adds a command line option "mmio-relax" to overcome this possible regression for Domain 0 or all para-virtual guests. Note however that enabling this workaround will reinstate the security issue these patches aim to address. xsa154.patchxen-unstable xsa154-4.6.patchXen 4.6.x xsa154-4.5.patchXen 4.5.x xsa154-4.4.patchXen 4.4.x xsa154-4.3.patchXen 4.3.x $ sha256sum xsa154* bbe7fba38ee30c00ef850fa6419c769e88b5669164d447f50b1ebbe333573152 xsa154.patch 011a4e33c0e476c52fe44253d50e01a1185948fd1b2a8e645274b25da6030d71 xsa154-4.3.patch 92d475bbc344127faa4f0183a9ccca9e975c7d24eb5772bf0a0a0a2e019144c6 xsa154-4.4.patch b13737e71f22185b94ab25c07afd521add1a7e3886326c719d5df4d42f3f87f4 xsa154-4.5.patch eec88c2a57466f83a81844cb7025f70c2b671d07a75d85487d4ed73cdabbb020 xsa154-4.6.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patch described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. However deployment of the mitigations described above is NOT permitted (except where all the affected systems and VMs are administered and used only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. This is because the configuration change would be visible to the guest, which could lead to the rediscovery of the vulnerability. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWxGayAAoJEIP+FMlX6CvZ9KwH/3z+9b7OjgpuIsOf0giZ5y99 yKoORWxQjcosYLQRQXvH62xtz0xRng+E3p+MeUm2qPUUuHFiqxSpZOAvW61C6DQL l5KNNHlIjWB3N0YVmvgRbf3WMbeX1DCsEJEIFxZUQQs3fgGAiOfIEOwRL2FIhJ5Y wP/z59fCuWs5lHoV0iAY3gkZHDd09JspCRQq8UGAc+X5jHF6fIOhUjZCS9KRQMJ5 p69ysdMj96fY5eKqwka/EXzvKMJUsQ42u5RQoYR5FhLx1UBi2otdcdbloKNseksA 7Wbf6j8Mz9NWVhvdZtnR/CNH8m5V7d78HsnGv7zNQCiMW+wg/k53yzHcw550P4w= =5V3D -END PGP SIGNATURE- xsa154.patch
